Project Management – The snowball effect

Project Requirements

image depicting idea quote with light bulb with gears.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, businessman looking tired and frustrated in office. 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

image of a snowball rolling and increasing in sizeThe 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.

Budgets overrun.

This isn’t what we wanted!

image of a frustrated business man hold his head in his hands.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.

Warning Signs

There are a number of warning signs that a project manager should be aware of that indicate a potential snowball.

    • avalanche sign on ski stationCustomers, 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”
      • “etc.”
      • “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

image of project schedule analysis with pen, calculator and notebookIn 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.


I love it when a Plan comes together!


The majority of work carried out by Mainplus Technology Ltd. over the last 5 years has been Project Management. Mostly managing IT projects for large organisations but with the odd web and business project thrown in for good luck.

Carrying out Project Management in the corporate environment brings with it a number of challenges.  There is a myriad of people that want reports that show progress against plan but want it on a single page in a very simple format that an audience with no project planning expertise can understand.  Given that the plans in question tend to be complex, and often part of a portfolio of projects which also need reporting in a similar manner, the challenge of producing such documents is not inconsiderable.  Add to this that projects are monitored on a weekly basis, producing reporting packs is a significant overhead.

A few years ago a good friend decided enough was enough and developed a PowerPoint add-in that analysed one or more Microsoft Project plans and created a single slide view based on simple configuration items and judicious use of specific columns in the plans. Even in its original basic form the tool was incredibly useful and soon became used by project managers, planners and project management staff across the organisation in question, including myself.

Since those early days he has continued to develop the tool and use it in other organisations to enhance his value as a jobbing contract planner/project manager.

Last year, at a meeting of project manager and planner friends, he came to the conclusion that development of the tool had reached the point where it was feature rich enough to warrant it being offered on a commercial basis.  A partnership was formed with another good friend with corporate connections and PagePlan development became commercially oriented from that point onwards.

Although I was part of that fateful meeting and a user of PagePlan over the years, my involvement in it’s growth as a commercial product ended at that point, other than the normal calls between friends etc.

I felt real excitement then, when asked a few weeks ago to help launch PagePlan into the marketplace. My own experience includes marketing support for a software distributor so I think I can bring something valuable to the party.

As a contractor I know how much PagePlan has helped my standing on projects in the past and I’m really looking forward to being part of making it available to other planners and managers so that they can add value to their efforts too.

We know there is still a way to go before we will get the product launched, especially as we all have very time consuming projects we are working on, but I hope to blog about the journey from an in-house tool to commercial product as we roll it out.