Projects being what they are, the trade-off decisions across the project life cycle seem to vary considerably. This is especially true with the parameters of the triple constraint – scope, schedule and cost. It does seem as though IT projects are particularly prone to scope reduction before things are complete! I think this is due to several things, including optimistic attitudes regarding what the team can actually do in a certain amount of time early in the life cycle.
One of the most typical progressions that I see begins with planning our projects within a set budget and a fixed schedule. Once the project is defined and planned, those requirements and the plan itself are under formal change control so we can’t mess with them without more formal consideration and approval. This is the main drawback to the triple constraint – it was never intended to have three fixed values! It was meant to have two prioritized fixed values and flexibility for the third value in order to meet the other two. For instance, we could have a fixed scope and budget, but it would be expected that we could flex the schedule and finish a little later in order to be on budget and on scope at the end. In many organizations, that nuance gets lost along the way.
One of the weakest areas in many IT projects is the requirements development work where we define what we are doing. Given that, I always expect to see the scope of the final product changes due to what we missed, what we defined incorrectly or the customer changing their mind. And usually that takes place. Even though meeting the full scope is always said to be most important, in the end it is always the schedule date that wins. So the project scope is reduced and often it takes more money spent to deliver the reduced scope. Ouch!