{"id":81,"date":"2017-02-07T09:17:30","date_gmt":"2017-02-07T09:17:30","guid":{"rendered":"https:\/\/www.threesl.com:2958\/blog\/?p=81"},"modified":"2018-07-19T08:52:07","modified_gmt":"2018-07-19T07:52:07","slug":"from-now-to-goal","status":"publish","type":"post","link":"https:\/\/www.threesl.com\/blog\/from-now-to-goal\/","title":{"rendered":"From Now to Goal – Requirements Management"},"content":{"rendered":"

Goal<\/h2>\n

If you don’t know where you are currently, or how you arrived or what your ultimate goal is, how do you know in which direction to head? Requirements Management is a skill made easier by the full traceability of tools such as Cradle.<\/p>\n

\"non
From – Now – Goal<\/figcaption><\/figure>\n

Build Me a Home<\/h3>\n

Starting a project without having a base understanding of the situation is a like building a house on unstable foundations. When the walls start to wander you’ll have no idea whether it was because the foundations were not level or were inappropriate or whether the direction of the wall is simply wrong.<\/p>\n

Not knowing the ultimate goal could lead to a double height wall being built for a bungalow.<\/p>\n

If you have no measure of how high the wall currently stands, you’ll have no chance of estimating how long it will take to finish.<\/p>\n

Baseline, Elicit\u00a0 and Measure<\/h3>\n

It may sound obvious when applied to the ‘simple’ task of\u00a0 building a home. It appears ridiculous to start building without knowing whether our goal is a bungalow, house or flat. Yet many projects start with a very loose understanding\u00a0 between stakeholders and producers and can head off in the wrong direction.<\/p>\n

Baseline<\/h4>\n

Do we know the current situation? Do the foundations exist, is this a single storey\u00a0 build that needs extending with an upper floor or are we to start from scratch. Are there any assumptions we need to record, this project assumes that there bedrock will be found within a metre.<\/p>\n

Elicit Requirements<\/h4>\n

Have we investigated what the customer \/ stakeholder actually wants? We could achieve the same m2<\/sup> with two storeys or one larger floor. No point building a house and then finding mobility restrictions mean a bungalow was needed. Do they actually need a house. The baseline may show they actually have somewhere to live and all they need is some more storage. We could provide them with a shed and achieve their goal. This honesty in not selling them a new house may mean we have a smaller turnover, but a far better reputation. This should lead to repeat and new business as knowledgeable supplier.<\/p>\n

Measure<\/h4>\n

This needs to be done at each stage. Internally we need to know that we are meeting the design. When do we stop building the walls? Externally we need to know that the customer is going to be happy. Milestones and intermediate reviews will prevent big surprises at the end. Whilst we want to avoid requirements creep, we have no intention to build a mansion for the price of a flat, customer requirements change and to remain agile, we need to build in steps to accommodate change.<\/p>\n

Summary<\/h3>\n

If you can see the sense in this simplistic example you have every justification you need to correctly control and manage your project. If you can’t see the point, you’re likely to return to your back of envelope calculations and assumptions of what your customer needs. Good luck to you, but we’d prefer you to take steps to de-risk your plans. Put yourself on the receiving end, a 20 storey building each with a floor of 1m*1m and a ladder pinned to the outside. It fulfils the requirements, but you try sleeping in your new bedsit.<\/p>\n