Time Wasted Managing Contract Changes
Technology projects are dynamic. Change is inevitable. Change comes as a result of many factors: shifting priorities, changing opinions, new learnings, volatile markets, shrewd competitors, emerging technologies – just to name a few. So how are changes dealt with on Fixed-Fee, Fixed Scope (FFFS) contracts? Enter the super-charged change-control process. The project organization orchestrates a multi-stage, multi-route, multi-approver, sign-off riddled process to evaluate requested changes to identify the impact on the contract. This requires analysts to fully document requested changes; developers and testers estimating the effort to implement and test the changes; architects to determine an approach to apply changes; project managers to assess the impact on budget and schedule; a myriad of meetings assessing the priority and appropriateness of changes; and of course, the negotiation on how these changes affect the contract. Finally, there’s getting the amendment to the contract signed by both parties. All of these things happening before touching a single line of code. In fact – all this is taking place while the team above is supposed to be working on already agreed-upon scope. Is all this ongoing change-control effort ever planned for? Unlikely!
Adding Scope and Budget? No Problem. Removing Scope? Forget About It
As one might expect, both parties must agree to changes to a signed FFFS contract. Much effort goes into documenting and approving prospective changes to previously agreed-to scope. However, it’s one thing to add scope. A vendor is likely to welcome increased scope because it means more revenue and margin. Furthermore, once a project is underway the vendor has a much better understanding of the project itself, further reducing (but not eliminating) the vendor-side risk. But have you ever tried reducing scope? No Way! Imagine you contracted a firm to deliver features A, B, C, D and E. Half way through the 12 month project, you realize that feature D offers no value to your or your customer. If your contract was based on Time and Materials (aka. hourly) you would simply stop further work on feature D; incur the cost already spent on the feature and possibly spend some effort removing any related code from the product. You save the time and money you were otherwise going to spend on it. On an FFFS contract – you’re locked in! You are going to get that feature whether you like it or not. The only hope of having your vendor agree to remove feature D is to replace it with features F, G and H — all intended to increase the revenue and margin on the contract.
Pages: 1 2
