Question:

 You are working on a project, and during the prototype review the client has come up with some new requirements. The project is constrained by both its budget and its schedule. How do you handle this change in scope? 

*Note to protect the innocent I have paraphrased the question.

Response:

It is very common when developing an application that the user base will have changes. The fact of the matter is, rarely does a client actually know, in complete detail, what they need.  That kind of forethought is just not the kind of thing you can expect from your clients. There are a few approaches to handle these changes and it really depends on the client and the methodology you are using to develop the project. To keep things simple I’ll describe methods to handle this kind of issue in both an Iterative (Agile-esk) and Watershed (RUP-esk) methodologies.

Iterative:  This is the bread and butter of an Iterative process. When dealing with change in an iterative process your first goal is to capture the new request. The Requirement or Story is recorded and added to the development queue. The client then prioritizes the new feature and places it in one of the pre scheduled iterations. If other requirements are not reached before the schedule or budget ends then so be it.  One of my peers is on a SCRUM project at a major PC Manufacturer, and the management actually funds each SCRUM sprint (iteration) at a time.  If the business users see a need for the next sprint then they fund it. If not, the project ends.

Watershed:  While the process will sound similar to Iterative; the decision making and the process that follows is much more structured.  First an analysis of the new request is done, requirements are defined, and impact is scoped.  Once the request is fully understood you have a few chooses. Option one is you can push the new request out until a new phase. Or you can feed in the request into your change management process. This may include your client making some tough decisions about what features they are going to push out or cancel to make room for the new feature.

The fact of the matter is, if a project is truly constrained (with no wiggle room) then you can think of your project constraints like a budget and requirements like bills you need to pay.  When you run out of your budget you can’t pay anymore bills, it’s as simple as that.

Now for a touch of reality, when I am engaged with a client I always make sure they understand that no one truly captures all of their needs in the first pass. As such they should always plan for either financing a second phase OR adding a decent amount of wiggle room to cover these kinds of events. This is really common during the deployment and stabilization phase (when users actually start using the app) and I just refer to this as the “shakeout” period. In fact the bigger the project, the longer the shakeout.. During the ERP app our shakeout was almost a quarter long as different departments went thru actual monthly and quarterly closes..