Software implementation projects can be difficult to complete on budget and on schedule and there are a number of ways projects can go off track. One potential issue to watch for is sometimes referred to as "scope creep," that is, the addition of functionality, interfaces, or other tasks to the project that weren't included in the original project plan. As the project progresses through the implementation cycle, it is almost a certainty that, at some point, the customer and software vendor will realize there are additional tasks needed that weren't clearly defined at the inception of the project.
There is no way to eliminate scope creep issues entirely from a project, but, as with many of the issues faced during the life of the project, scope creep is best addressed early to help minimize the chances of it occurring and its ultimate impact to the project timeline and cost. Here are a few ways I've found that should be considered prior to project initiation, during the RFP process and through contract negotiation.
/1/ Begin by Getting the Get the RFP Right
Without getting into detail on the procurement process, oftentimes, when a customer looks to acquire a large software system, the first step is development and distribution of a Request for Proposal. That RFP provides a detailed description of the customer's needs related to the new software: what problems the customer is hoping to solve, what functions the software must provide, needed interfaces, etc.
A more detailed and accurate RFP can be invaluable. If the customer spends extra time on the development of the RFP, that more detailed system description can be used to not only ensure a better understanding by the vendor, but can also be used to define the project scope to make it clear what the vendor is obligated to perform for the agreed cost. To achieve that, the RFP itself must be incorporated into the signed agreement; either in its entirety or the specific requirements set forth in the RFP can be included in the Statement of Work drafted by the parties and attached to the agreement.
/2/ Perform Additional Due Diligence Up Front
As a complement to the RFP, a clearer understanding of the entire project scope at the start will result in a more accurate project plan. Between the vendor and the customer, the party that best knows the licensed software's capabilities and limitations is the vendor itself. So, while the customer may have provided a well-written RFP, without applying the vendor's special knowledge to the equation, we've only seen half the solution.
It's in the both parties' best interest to make sure adequate due diligence has been performed by the vendor prior to contract signing to allow the vendor to probe more deeply into the customer requirements, needed interfaces, source and target systems, and similar considerations that may affect the project scope. The result of this due diligence work must then be included in the contract requirements document and also reflected in the project timeline and milestones.
In some cases, a vendor may be hesitant to expend additional effort prior to contract signing since the vendor is typically doing this work at its expense. In that case, the parties should consider splitting the project into an initial "Scope Definition" phase, in which the vendor performs additional work to define the project scope and the vendor and customer share some of the costs related to that work. Although the customer must commit not only monetary but also employee resources during to the scope definition phase, the potential reduction in risk to the greater project may be worth it. Following its completion, the customer then has a clearer view of the overall project and can make a more informed "go/no go" decision.
/3/ Put Some Teeth in the Project Estimates
If the implementation phase of the project is presented on an estimated cost basis -- rather than fixed price -- the risk of cost overruns due to scope creep must be looked at closely. In many cases, the estimates are used to "draw a box" around the scope of the project and any additional work over what is estimated falls into the project change control process. The change control process described in the agreement will often contemplate that the cost of overruns is to be apportioned to whichever party is the cause of the delay or additional work. But what often happens is that the parties argue about whether a given function should be considered either "in scope" or "out of scope" based on the project requirements (which may include the RFP, the vendor's response, the system documentation and more). More often than not, it will not be easy to agree on which party is at fault.
Instead, it's in the customer's best interest to make the vendor's project estimates have real meaning. That may mean converting them into true, fixed-price estimates or providing a strong incentive for the vendor to meet the estimates. The latter may be achieved by providing clear contract language stating that, unless the delay or additional work is the result of the customer failing to meet obligations described in the agreement, then the cost for additional work is either borne entirely by the vendor or done at a greatly reduced rate.
There are surely many other ways to address scope creep in a project. From the perspective of a customer or an attorney representing the customer in a negotiation, the tips above are worth keeping in mind throughout the development of the agreement.