Start by seeing whether you can pinpoint the cause of the deviation. For example, in the case of a project' s budget being reduced, what was the underlying element that caused the budget reduction? Perhaps the company recently announced poorer performance figures for a quarter, and as a result, executives took steps to reduce costs where feasible. Your project just happened to be in the feasible camp.
Or, if the schedule needs to deviate, perhaps the deviation is being driven by some corporate customers who want your product sooner rather than later. Or perhaps there was a legislative change that mandates your deliverables be available sooner than first planned.
The most difficult to spot might be design deviations. Here is where you get into the area of nice-to-haves that we' ve been talking about—those things that would be great to have in the project, but were not required at design time—versus need-to-haves (those changes that are mandated). A customer approaches you with a design deviation that' s going to require a modification to the scope document (and subsequent re-signing). It' s up to you to determine, with the help of your project team, if this deviation is something that you really need to make in order to fulfill the requirements of the project and hence create the desired deliverables. It' s possible to get into some arguments with the customer on this, so you must go carefully.
Also, some design deviations arise because the project has a problem that needs to be rectified. In other words, the requirements that you formulated aren't working out exactly as desired, and there needs to be a change to the project. You might be the one to initiate such a deviation, or a customer may come to you to point out the problem and ask for a deviation.
Was this article helpful?