I did a newsletter article last year on the consequences of getting business requirements late in a project. I’ve recently received a few questions on this subject so I thought I would publish it again as a blog post.
Here’s the main issue we have with project requirements – SMEs don’t realize the consequences in providing requirements later in the project.
The IT team usually has an understanding that each phase after analysis costs more and more to go back and add requirements, but SMEs don’t have that knowledge.
The business doesn’t understand what it costs in time, money, and effort to go back, have discussions on the new requirements, update the documentation, update the design, write the new code, update the testing documentation, and add it to the testing schedule. And then test it and possibly have re-work time as well.
The best way to handle this is to include a little education at the kick-off of your requirements session.
- Explain the importance of being involved from the beginning and doing our best to identify all requirements during the analysis phase. You can say that it’s understandable that from time to time there will be missed requirements that come up later in projects, but our goal is to minimize that as much as we possibly can.
Now we’re going to do a little math for second. Math is not my thing, but sometimes we have to do it. 🙂
We have to be able to measure this in some way so we’re going to say a unit cost of 1 is assigned to the effort to fix a requirements error – meaning adding a new requirement, changing a requirement, or removing a requirement at the various phases of a project.
- During requirements phase is costs .1 to .2 of a unit to fix a requirement issue
- During design it costs .5 (or ½ of a unit to fix a requirement issue.
- During coding it costs 1 unit to fix a requirement issue (now keep in mind that these numbers are for ONE requirement issue, it goes up another unit for each requirement issue).
- During unit test it costs 2 units to fix the issue.
- During Acceptance test it costs 5 units to fix the issue
- During maintenance (after deployment to production) it costs 20 units to fix the issue
What this tells us is that it is as much as a 200 to 1 cost savings in finding requirements errors in the requirements phase versus finding them in the maintenance stage.
These are true numbers that came from studies done by companies like IBM and HP.
- Another thing to note is that they found in this study that only 4% of projects fail from unrealistic timelines while 13% of projects fail due lack of user input and 12% fail due to incomplete requirements and another 12% fail from changing requirements and specifications.
If you don’t want to go over the unit cost example with your business, at least give them those percentages.
Then tell them “we don’t want this project to fail because of lack of input or missed requirements, do we? So let’s all stay engaged throughout these requirements sessions and ensure we have the requirements nailed down. My job as the BA is to document what you want from the software. I can’t make up requirements and you wouldn’t want me to. This is your chance to tell us exactly what you need to be effective, efficient, and have the tools available to you in order to get your job done. Don’t let this opportunity slip by you – be involved in these discussions so that when you get this product you’ll say “that looks and acts exactly the way I expected it to”.
Education is the key to success. Educate your business partners and you’ll see immediate results.