Another aspect of scope creep, a potentially much more subtle aspect, is that of a change in philosophy regarding the project. You started the project out with solid design principles. You established a good set of requirements, nailed up your project documents, obtained sign-off, assembled your team, and started the project.
Now, with the project well underway, you' re getting a sense that the flavor of the project has changed a bit. Where the project' s goals were at one time A and B, they' re now A, B, and C, with more emphasis on C than you think there should be at this stage of the project. It ' s almost as if you' ve done too good of a job managing the project, and because the customers can see the deliverables and how they' l l function once they' re in production, they begin to see new uses for the deliverables—uses that will require a second project. Nevertheless, the change requests keep coming in, asking for changes that match elements of C, but not A or B. And you were reticent to consider changes to A and B—you weren 't even considering C.
Again, communication techniques are your best friends in situations like this. It' s going to be much more difficult to illustrate to stakeholders and customers what' s occurring here, but you can accomplish it by using statistics that show the change requests you' ve had that do not match the project' s deliverables, and coupling those statistics with the variances to prove that the work you' re doing is costing time and money. You then point out that the need for C has indeed been suitably identified, but that finishing off C needs to happen in a revision of the deliverable—another project at another time.
Considering all that we 've learned in this chapter, let' s peek in on the Prestige Hotels project and see how you ' re doing.
Was this article helpful?