Best practice: The project requirements document produced by the discovery process should include verbiage indicating that the contents are the totality of binding requirements for the contract, and include a VP signature from each major department in the consuming or client department.
Worst practice: Let it slide, accepting new requirements at any stage of the project without a change order.
Coping Tactic #4: Stipulating a not-to-exceed for each major functional area
The tactics so far have focused on coping mechanisms during the project, when it’s already too late. Instead, this tactic focuses on the verbiage of the SOW, in an attempt to meld just one agile principle into a waterfall framework. In the SOW’s deliverables section, each major section (typically between 5 and 10) needs to have the following words at the end:
Notwithstanding the foregoing, the total effort involved in implementing and deploying this functional area shall not exceed X hours. When the effort for this area reaches 25 percent, 50 percent, and 75 percent of that limit, consultant may notify client that a task review meeting is required. During that meeting, the consultant will brief the client about project variances or discoveries that endanger deliverables, and a recommended path forward. After that meeting, client will issue a change order request indicating the desired modification to requirements, schedule, or budget.
Best practice: Take the small stuff in stride, but request a task review meeting for any task that goes into red status or is blocked for more than a few weeks. Failure to put tasks in red status is a firable offense for the project lead.
Worst practice: Omit this verbiage from the SOW, and during the project avoid the whole issue until UAT.
While all of the above tactics work, to a degree, they are trying to bridge a contradiction. Of course I advocate real agile projects, but many a client organization or its management just can’t deal with flexibility and insists upon checklists of fixed deliverables. If so, you need to know that before you sign the contract. You may be better off just sticking with pure waterfall and managing things that way. Of course, you’ll need to jack up the bid and lengthen the schedule, but at least you will be managing risk in a coherent way.
The root cause
In most custom software projects, the requirements are not specified in advance with enough detail to truly support waterfall bids and tight project management. For CRM projects of any complexity, I’m going to go as far as to say it’s an impossibility. Why? What are the odds that:
- The users will state their requirements with such thoroughness and precision that you won't misunderstand them?
- The users won't change their minds about details and priorities during the course of the project?
- The client’s channels, competitive environment, and internal business rules won't change during the life of the CRM project?
- The client understands their data, business processes, and cross-system integrations so well that there won't be any surprises during the project?
- The client is able to foresee all the government regulations, customer contractual stipulations, pending litigation, and internal standards you'll need to comply with?
Consequently, some level of discovery will be happening throughout the project…which means your bid will have to have some padding to deal with the “dark matter” that is scattered throughout the deliverables list.
Sign up for CIO Asia eNewsletters.