Do vague program requirements cause projects to fail?
That’s the question ESI International wanted to know.
They surveyed project team members, including project managers and contracting officers, and found that 80 percent said their agencies lacked a formalized process for defining and managing program requirements.
Bill Damare is the Vice President for Government Markets at ESI International. He started off telling Chris Dorobek on the DorobekINSIDER program what exactly program requirements are.
• 80% lacked a formalized process
• 95% do not formally recognize a role accountable for RMD
• 95% lacked tools to carry out RMD activities effectively
• Their level of confidence with understanding vendor requirements was only 35%
ESI Graphic – click to enlarge
So why do programs fail?“Think of it like a game of telephone, if the requirements are not strongly defined up front and if you don’t manage stakeholder’s expectation’s than the message is going to get all mangled up,” said Damare.
ESI Graphic — Click to enlarge
You can download the ESI report: STRENGTHENING GOVERNMENT’S WEAKEST LINK: 5 STEPS TO BETTER REQUIREMENTS MANAGEMENT.
Requirements for software are as essential as requirements for building a house. Ask yourself this question: If a contractor showed up to build your house with a truck load full of concrete, wood and nails, but no engineering drawing, would you let him build your home?
The answer is probably or should I say most definitely NO I would not let him build my home, yet senior managers would prefer not to have engineering drawings (or requirements documented and decomposed if you will) when developing software. I have been asking this question of my leadership and have found that most in the IT Leadership roles do not understand the engineering disciplines nor do they know how to plan for injecting said disciplines into the project. Their favorite term is don’t tell me what I need I already know what I need, but in fact I have discovered that 99.9% (is this a lean measure?) of IT senior managers making the project decisions do not know what engineering activities they need to plan for during the project.
Typical IT Project; a senior manager (Joe) discovers that a customer (Bob) has an unfulfilled IT requirement. The manager quickly and aggressively pursues the funding source 1. High Level Briefing with the customer (Bob, have I got the fix for your IT System needs). 2. It will only take my IT Team 9 months to deliver your solution. 3. We have estimated your project will cost 2.6 M. 4. Please have your financial manager send over the funding document….
Typical IT Project Outcome; Bob I am sorry to have to tell you this but after working with your staff to determine your requirements we have updated our estimates and have determined that the project will take 18 months to deliver and roughly 4.6 M more to complete, but we are on top of your project and have made your project our top priority.
Bob says Joe what are you talking about an additional 9 months to deliver and 4.6 M more. Joe says to Bob, we believed we had a good understanding of your requirements, but when my engineers documented your requirements we found that there were a lot more requirements than we originally anticipated, but if you like you can remove some of the lower priority requirements from the release and we can work those requirements in another release (this is where they get you tied in to a funding stream for many years to come).
Now getting back to the home builder, don’t worry about the engineering drawings will have your house built in 4 months and within budget…Have you really got to ask yourself this question; I should have known when I did not see any engineering drawings on the house, before I hired the contractor, now the contractor wants 60K to finish my home and another 7 months – do I really have the Money to complete the house?
Now ask yourself this question; can I afford software without Requirements being documented and managed? I say; you cannot afford not to perform Requirements Management processes and the lack of a defined requirements management process kills programs…
One thing I’ve noticed: some projects become so focused on the timeline that quality controls (which include requirements definition) get thrown out of the window. It’s the classic “pay me now, or pay me later” scenario. Later tends to be more painful.
as we move to buying IT as a service, requirements become more and more important. Now, however, the government buyer needs to understand a broader variety of options than during the client server era. I find is fascinating that the ESI model has no market research or analysis of build versus buy options prior to locking down requirements. We have known for 25 years that the requirements definition process needs to reflect feasibility and cost trade-offs. There are many studies that show 75-90% of life cycle cost get locked-in when requirements are set. With shared services and cloud options, it seems that agencies need to know their options as part of setting requirements.