We've all been there. The whole industry has been there since the '60s ("The Mythical Man Month" and horror stories from ControlData OS releases come to mind), and only the most zealous Agile team will resist the temptation to cut corners.
But the industry doesn't seem to be getting any better at this, particularly when it comes to projects with lots of dependencies, or with complexities that could have been avoided. I'm particularly irked about the kind of magical thinking that just begs for train wrecks: "well, while we're at it, let's add THIS risky artificial complexity to THAT out-of-control project..."
The answer is in the question
How to avoid this kind of project schedule crisis? Make the project less tightly coupled. We did it with software (asynchronous web services), why aren't doing it with the project itself?
Try these ideas on for size:
- Make bonuses and other incentives contingent on achieving IT goals, but make sure they are not tied to specific go-live dates.
- To the extent possible, base all integrations on a real messaging system that logs all messages (and keeps the logs for at least a couple of weeks) to improve debugging, testability, reconciliation and recovery efforts.
- Just assume that every integration will have more dirty data and muddled semantics than you can imagine. So no matter how realistic the schedule is for migration, normalization and cleansing...add 25 percent to it. Really.
- Do the continuous integration thing: All code has unit tests, complete system builds nightly with test suites that grow along with the code, bring external integrations and some real data into the system as early as possible in the project.
- Do the user-centered design thing: get users working with the UI and evaluating the correctness of any results before you've reached 25 percent of the project spend...and keep them involved until the end.
- Do the staging/sandbox thing early: spring for a "full sandbox" or staging copy from every vendor that will sell you one. Use them from the mid-point of the project, at the latest. Really. Connect the sandboxes to each other so you have as realistic a development and testing environment as early as possible.
- Do the reality-therapy thing: your executive sponsors (you do have executive sponsors, don't you?) should be giving demos of their part of the system to their teams at the end of each sprint. This is good for user adoption but it's even better to make sure expectations about schedule and features don't get out of hand.
- Do the prioritization thing: the way to avoid the end-of-project crash is to reduce deliverables along the way. This is really difficult, but it is the rare project indeed that has more budget and schedule than it needs. So lighten the load at every turn -- enforce a feature diet.
- Do the game-theory thing: otherwise known as "have a backup plan," this involves a serious discussion at least 6 weeks prior to go-live about how the business would handle a "no-go" decision.
- Un-do the kill-the-messenger thing: at every significant milestone review, give explicit permission to team members to reveal negative information. Through your words, actions and facial impressions, encourage people to be realistic about schedules and risks. Never punish the delivery boy for bad news, and don't "yes men" and used-car-salesmen behavior.
- And the grand-daddy of them all -- un-do the big-bang thing: use phased deployments, with each functional increment building upon a stable base from the previous cycle. Bring in historical data incrementally (start with last year's data, then add data from two years ago, etc.) and be willing to have low-priority data available only offline for a while.
Some of the above ideas may sound nuts. But why are we still making project decisions with management ideas from 50 years ago? It's time to try something new.
Sign up for CIO Asia eNewsletters.