Whether it’s a consulting engagement or an internal software project, IT departments like the flexibility and productivity of an agile project. But in selling the project to upper management and the finance organization, waterfall concepts will nearly always be introduced as requirements. If you think hard about it, agile and waterfall are nearly contradictory philosophies. So how do you get them to work together? In too many software projects, particularly those involving consultants, it’s a pretty uncomfortable marriage. Unlike the song, opposites do not attract.
Coping Tactic #1: Vigorous account management
Since waterfall involves a fixed specification as well as a fixed budget and schedule, the flexible (or only vaguely-defined) outputs for sprints will mean a fair amount of tap-dancing. However, this can work when waterfall’s “specification” is ill-defined (because the customer does not know what they really need) or malleable (because an executive decides to preempt things). But beware: this tactic only works when vigilantly and aggressively applied, forcing conversations about de-prioritizing deliverables and avoiding scope-creep throughout the project.
Best Practice: Explicitly manage expectations in writing at the start and end of every sprint. Further, have a customer signoff for each feature delivered during the sprint.
Worst Practice: Head-in-the-sand behavior, hoping that the issue will just take care of itself.
Coping Tactic #2: Change-order extravaganza
In waterfall projects, clients are used to the idea of change orders (and of course your contract stipulates them, right?). So, use that mechanism early and often. In one $700,000 project we were involved with, over 50 change orders were issued (even though there was only a tiny overrun). The change orders need to be included as formal addenda to the statements of work (SOWs) and include a customer signature so they have contractual impact.
Best practice: Promptly issue a change order for every vaguely-specified item when the vagueness gets ironed out. Change orders should include both schedule and cost impacts, as well as feature details.
Worst practice: Delay or even skip the issuance of change orders, leaving it to “a verbal understanding” that will quickly be forgotten.
Coping Tactic #3: Explicit closure of discovery
In typical software projects, an initial fixed-cost phase (comprising 10% to 25% of the total project effort) is devoted to the requirements discovery process. The output of that process is the statement of project functional requirements. Even though it is common to discover many details after that first phase, these new items are not the project implementer’s problem: they are the consuming or client organization’s problem. They should not be accepted as binding requirements without a change order. Unfortunately, I’ve seen projects that were still in discovery after deployment.
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.