Requirements defect or scope creep?

 

If you have managed a number of projects the following scenario is likely one which you have encountered.  A requirement which was not previously identified emerges after project baselines have been approved, and when you try to follow good project change management practices, your customer informs you that this was not a new requirement but rather one which was missed during the requirements gathering process?

Depending on the approach taken for your project, this may or may not be a big deal.

If you are managing a project using an agile methodology, so long as the requirement does not generate a significant change to architecture, design or delivered value, it is usually just a matter of adding this item to the backlog and then asking the customer to reprioritize the backlog at the end of the current sprint or iteration.

But let’s say that your project was following a waterfall approach or that this recently identified requirement does severely impact foundational work completed on an agile project.  What then?

Referring the customer back to the original requirements baseline is unlikely to provide much comfort.  Even if you are able to prove that there is no way that this requirement could have been feasibly identified earlier in the project’s life, you might be contractually right but are unlikely to get a great customer satisfaction rating.  If this requirement recently emerged due to changes in the environment in which the project operates, even if the customer agrees to leaving things as they are, you could end up achieving the originally approved baselines but not delivering much business value.

On the other hand, if you simply accept the additional requirements, you could end up creating cost, schedule and quality variances as well as losing credibility with your project team and other internal delivery stakeholders.

In such cases, you might be tempted to jump into a time machine (Does Uber supply TARDIS’es?), go back to the early days of the project, and add some clauses to the change management plan which would explicitly spell out what does and doesn’t constitute project change.

Resist this urge (besides, it’s currently impossible!) and avoid conflict through collaboration.

Have your team take the time to do a quick analysis on the impact of the requirement and meet with the customer to review these impacts with them.  Acknowledge the importance of the new requirement to their business, employ active listening to understand whether there are other factors at play which might affect their attitude, and work towards a mutually agreeable solution.  Don’t ignore any options – explore scope trade-offs, alternate resourcing and work sharing.  Make sure the customer fully understands and owns the risk of the change.  In some cases, for the sake of the customer relationship, you might need to dip into your contingency reserves to fund this additional work, whereas in other cases, you may be able to have the customer fund the new work.

Project management is about making the whole more than just the sum of the parts – collaborate to help realize business value while still enabling your delivery team to meet expectations.

(This article was originally published without requirements defects to kbondale.wordpress.com in November 2014)