In the beginning there are requirements.
Initially, requirements may be in the
form of a very loose idea or proposal. Even so,
the simplest high level proposition will contain a level of requirement definition.
I want a report that will show my sales by region.
The very word “want” flags a requirement.
As the life cycle of a project proceeds, requirements become more detailed. Users, business departments, clients, sponsors (lets just call them “customers”) refining their needs. For example.
I want a report that shows my sales by region, broken down by product and sales manager. I want the report to also show the level of profit of each sales grouping. I want a graph that tells me which is the best performing sames manager in each region based on sales profitability. The worst performing manager should be highlighted as red. The report needs to be produced on the first of each month and be available by 9 a.m. UTC.
By the design phase of a project, requirements should be fully defined. They should be at a level of detail that removes ambiguities, allowing the analyst or developer to produce a design ready for build.
In practice, we are human.
Producing an unambiguous set of requirements is virtually impossible for any reasonably complex deliverable. This is addressed by discussing and resolving any ambiguities with the customer as we progress through the design.
The inability to produce a perfect requirement, should however, never be an excuse for a poor requirement. That’s when the snowball effect begins.
The growth of the overrun snowball
The snowball starts with ambiguities and omissions in the requirements. This results in additional (generally unplanned) time and cost to address the shortcomings of the requirements.
Moving into build, missing requirements or invalid assumptions made in lieu of clarity, results in the design having to be updated. This in turn potentially leads to changes in the build.
The snowball begins to grow.
As we move into system testing, test cases are likely to highlight further omissions, lack of clarity and discrepancies in requirements. As a result the design, build and potentially test cases need to be updated, delaying the test phase.
The snowball continues to grow.
As the project enters user testing, a lack of time and effort spent on defining requirements is likely to result in a situation that the deliverable is not what the client, customer, sponsor, user etc. expected and probably not what they need. So it’s back to altering design and build, then retesting.
The cost/time snowball gets bigger and bigger.
Deadlines are missed.
This isn’t what we wanted!
In order to mitigate and constrain delays and budget, a number of compromises will commonly be made. Scope and functionality will be reduced. The design will be locked down to prevent any further requirement changes being made.
When the system finally goes live, there is likely to be a level of dissatisfaction and numerous manual work-arounds to address missing functionality.
Dissatisfaction will probably be tempered by the promise of a future version that will address all the shortcomings of the delivery. In most cases the proposition for this type of “follow-up” delivery fails to get budget approval.
The system we have is working. What you are proposing is going to cost money we want to use for other things that are of greater priority.
So users, left with the system they never really wanted, have to make do. They are disillusioned, feel let down by the project and complain that the project didn’t have the customer’s needs at heart.
The irony is of course, that it was probably the same users that provided the poor requirements in the first place. It’s not all their fault though. Business users are not skilled at providing requirements and need to be assisted in doing so by project professionals.
Project managers need to work with their analysts to identify poor requirements, highlight them and address shortcomings early in the project life-cycle.
There are a number of warning signs that a project manager should be aware of that indicate a potential snowball.
- Customers, users, business areas, clients etc. that complain that they cannot spare skilled resources to work on requirements.
- People working on/contributing to requirements constantly change.
- Requirements have the following words or phrases, or similar, in them
- “anything else that may be required”
- “to be determined”
- “further investigation required”
- “subject to future decision/legislation/project/announcement”
- There is pressure to complete design/build before requirements have been agreed and signed off.
Project Management Reality
In reality, a project manager can’t always avoid a snowball effect. We often don’t have the final say in how the project proceeds. In such a situation plans need to be adjusted to reflect the level of requirement uncertainty. My suggestion would be to determine how much extra time to allocate to testing. Double that amount for build and again or design. Determine your resource run rate for those elements of the plan and add the appropriate amount to the budget.
There are many things that can cause project to overrun budget and delivery dates, but poor requirements is one of the biggest impacts.