The importance of requirements

May I help you?

I step forward and meet the politely smiling order taker at one of our favourite Friday evening take-away restaurants. We confirm the order and I ask how the long the wait will be. “Oh, about 10 minutes, Sir…not long”, the order taker says sounding mildly confident and she gives me that smile again.
We settle in at the neat row of chairs and the wait starts. From past experience this has been anything ranging from 15-25 minutes. But we accept it….the end result is a weekly family treat with very few dishes to clean up afterwards and we ease into the weekend’s activities on satisfied tummies.
Ah yes, if only real-world projects could be half as successful in meeting requirements as placing an order and waiting a little longer than expected.
My mind wanders off to past conversations…“We state outcomes and they must just deliver”
“We don’t need Business Analysts- they just create lots of documents we have to read and sign off. We don’t understand why they just can’t do what we want.”
And my favourite: “We do Agile and don’t do requirements documentation, business understands” I know, I know, I can hear shrieks of disgust and condemnation from Scrum Masters and other distinguished Agile followers, Somehow the sizzle and the steak swapped places in the story with some very unintended consequences.
So, why then are we surprised when projects; be they IT, Business change or a combination of the two don’t meet expectations? Is it because we are inherently lazy? Is it because we believe the outcome is so obvious that we don’t have to think about them, write them down and understand the consequences of implementing them? Or is it some sinister plot to make us wait longer than we need to before we can get what we want, just because there is a “process”.
Sadly I have seen more projects struggle than what is good for anyone to see in a year, often because everyone involved in the project don’t communicate requirements. And there is no excuse good enough to not share what you are after exactly, making sure you are clearly understood and checking the end product to see if it has met with your expectations. If you as the dutiful hunter in the family arrive home with either the wrong order, missing order or very late then you have to own and face the consequences. Whether you choose to fix it by complaining, buying the missing meals or apologising for the next three weeks for being late with cold food, it will cost you time, money in most cases, and you have to fix very real quality issues. I don’t have to spell those out to you I am sure…Oh but I have to – say this article is about requirements and how well we communicate them.

The key learnings I can impart around requirements are:
• Say exactly what you want the project to do and not do.
• Be very specific about what the processes are, will be and how you will get there.
• Detail what the applications need to do (functional requirements)
• Detail what the provider/maintainer of the delivered solution needs to do (non-functional requirements)
• Understand your data and how it will be governed. Your business or organisation depend on it for success.
• Create easy to understand documents that can be easily changed by your organisation’s staff.
• Make sure everyone knows how to verify what the project aimed to deliver as outcome – what is the acceptance criteria?
• Measure the benefits!

Requirements need to be communicated and it does mean people skilled in business analysis, requirements engineering and the like are needed. They must spend time with the people who own the requirements to help them to think about it, document it, and understand the consequences of implementing it. Does this mean I have to create and read lots of documents with models and samples of screen designs and lists? Yes, if what you are looking for is complex, of high value, high risk and needs careful analysis. Maybe only at a high level if you are building something new that has never been done before and you choose to design-as-you-go. Will it cost a lot? I don’t know what “a lot” means to you- that is for you to decide. Will it give the desired outcome if I choose either one of the approaches or is there some magical sweet spot where the perfect project will see the light of day? After a few years, slightly jaded and worse for wear from working in the project world, I have to say no. There is no shortcut without a cost. You have to choose what you are willing to pay for and risk. To do it right the first time or to pay until it is right….

Email for more information on how we can help to assure your success.