Requirements Defect or Scope Creep?

Requirements Defect or Scope Creep?
By Kiron D. Bondale

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 re-prioritize 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.

Kiron D. Bondale, PMP, PMI-RMP has managed multiple mid-to-large-sized technology and change management projects, and has worked in both internal and professional services project management capacities. He has setup and managed Project Management Offices (PMO) and has provided project portfolio management and project management consulting services to clients across multiple industries.

Kiron is an active member of the Project Management Institute (PMI) and served as a volunteer director on the Board of the PMI Lakeshore Chapter for six years.

Kiron has published articles on Project and Project Portfolio Management in both project management-specific journals (PM Network, PMI-ISSIG journal, Projects & Profits) as well as industry-specific journals (ILTA Peer-to-peer). He has delivered almost a hundred webinar presentations on a variety of PPM and PM topics and has presented at multiple industry conferences including HIMSS, MISA and ProjectWorld. In addition to this blog, Kiron contributes articles on a monthly basis to ProjectTimes.com.

Kiron is a firm believer that a pragmatic approach to organization change that addresses process & technology, but most important, people will maximize your chances for success. You can reach Kiron at kiron_bondale@yahoo.ca