Ok, what’s this all about? You probably know by now that I am nagging you about the need to understand why it’s super important to make it right (or as right as possible) from the start. My unacademic sketch below want to illustrate just this idea.
The basic concept regardless if we talk about traditional water fall, scrum or other agile development models. Someone is trying to identify a need from an identified customer or market, interpret and expresses this in some way (textual requirements or through models) so that we can validate the information with the Customer and pass this information from a smaller group of engineers to a larger. Now a system solution is created that will capture those expressed needs so that we can start to design and build. If everything goes well, we just have to test all the requirements against their test cases and the hand over to the customer, on time and within budget. We have of cause within the project had reviews, user group meetings and functioning change- and risk processes so that everything is under control.
Voilà! That was fun. Everyone happy?!
What!! The Customer is not happy and the solution doesn’t work as it was supposed to. Now the process starts to try to fix things. The project tries to convince the customer that these complaints can be fixed with new releases of the SW and some HW changes. With increased frustration times passes and eventually the Customer says; No, now it’s enough! I want money back or I will be forced to cancel the project and take legal actions.
Of cause, I must simplify things but we have all worked in those “doomed” projects, right?!
I had the pleasure to listen to yet another study on failed projects. It was presented by Dr. Gina Guillaume-Joseph who studied over 200 failed projects with a total value of 15 billion dollars in sunken cost. I was not surprised by the result. The main reason for project failure was ranked like this:
|Project failure factor||Odds of project failure|
|Project Schedule Delays||78,6%|
|Changing or Unclear Requirements||29,9%|
|Project Failure in Test Phase||11,4%|
(Source: Improving Software Project Outcomes Through Predictive Analytics, ENGINEERING MANAGEMENT REVIEW, 2015)
What can we see from this? Well first that I´m right! Customers loses faith and cancels the projects after some time and we also see problems with changing requirements and failed tests.
So, what can be done then? WHY NOT WRITE BETTER REQUIREMENTS! It’s not magic and we just have to make sure that the requirements are correctly formulated and that the sets of requirements are complete and consistent.
I want to promote the organization of INCOSE who has developed a set of rules for writing high quality requirements (http://www.incose.org/ProductsPublications/techpublications/GuideRequirements). Their guide includes about 50 different quality metrics and it’s a little more complex than the old SMART rule you might be aware of? Unfortunately, these are only available to members of INCOSE. But Imagine if you could get help in formulating good requirements which is so specific, measurable, accepted, realistic and true as its practically possible.
Since we people who are supposed to read and understand the information, we need to write information which is understandable for everyone, right? At least to the supposed reader? So even if the reader isn´t a toddler, we need to think of them as fairly “stupid”, or we will miss those obvious things, at least to us as technical experts…
I will next week start to look at the different quality metrics I mentioned above, one at a time. I will look at them and give examples and some practical tips to everyone interested. We all need to understand that this is both important, difficult, but 100% neccesary!
If you want to know more or look at some cool tools that will help you to write super good requirements, you can always look at my webpage: www.requalify.se or send me an e-mail to firstname.lastname@example.org
See you out there!