The 4-D Lifecycle

As I look back over my development career, it occurs to me that — no matter what methodology was in use at the time — all projects seemed to go through three essential phases. Being in an alliterative frame of mind, I will call these Discover, Drive to Decisions, and Deliver.

In the first phase, a project team is discovering all they can about the problem space, and about potential elements of a solution. Questions are mostly open-ended, and you are working to get the general lay of the land.

At some point, though, the team gets a pretty good sense of what is expected of them, and their interests narrow to focus on some pretty specific concerns. Typically, these involve ambiguities in the problem space, competing perspectives held by different stakeholders, or difficult design trade-offs. Resolving these generally requires some tough decisions to be made.

Finally, when they get those open issues nailed down, the team knows with some precision what they need to do, and they marshal their troops to go off and deliver on the promises made to their customers.

There are a few interesting points to be made about this three-phase perspective.

First, the key mindsets necessary to succeed are very different in these three phases. The Discover phase primarily requires boundless curiosity — much the same thing my Golden Retriever exhibits when he is let off his leash in a new space. You need to run around in all directions at once, discovering and testing boundaries, sniffing anything that might be interesting.

In the Drive to Decisions phase, though, you need to be more focused and persistent, doing whatever it takes to resolve your significant remaining issues. In this phase you are more like a bloodhound, relentlessly following the scent of its quarry.

In the Deliver phase, you need to be efficient and steady in making progress towards the finish line. You have lots of stuff to do, you know what it is, and you need to go about doing it. At this point, what you need is a sheepdog, rounding up the flock and bringing them home at day’s end, making sure that no straggler gets lost.

These three phases are also interesting in that I would contend that most project failures can be traced back to not recognizing the importance of one or more of these. I’ve seen projects fail because they were stuck in perpetual discovery mode. I’ve seen projects fail because they skipped the Drive phase, and tried to go straight from Discover to Deliver. And I’ve seen projects that failed because they tried to go straight to Deliver in a misguided effort to complete faster.

In general, though, the Drive phase is the easiest to miss: you can easily complete all of the deliverables in any methodology and still ignore all the tough decisions that will come back to bite you before you’re done. As Spolsky says, in Joel On Sofware:

In too many programming organizations, every time there’s a design debate, nobody ever manages to make a decision, usually for political reasons. So the programmers only work on uncontroversial stuff. As time goes on, all the hard decisions are pushed to the end. These projects are the most likely to fail.

Finally (to bring us back to the documentation theme I’ve been pursuing with recent posts), the other interesting aspect of this 4-D approach is that it explains why I’ve always used a key document that has helped me more than anything else I’ve ever done, but that I’ve never seen described anywhere. I don’t even have a name for it. Basically, it’s a simple text document, with two numbered lists. The first list consists of open issues/questions; the second list consists of answers/decisions. I generally start populating the first list towards the end of what I’m calling the Discover phase. During the Drive to Decision phase, I’m getting answers and gradually replacing the questions on the first list with answers on the second. When the first list is empty, I’m ready for Deliver to begin.

Of course, this document doesn’t replace any of the other traditional project deliverables: it’s ultimately a throw-away, since all of the answers obtained should find more permanent homes in one of the other documents produced by the project.

And no, I have no plans to publish the 4-D Manifesto, write the 4-D Developer’s Bible, start a 4-D consulting business, begin holding annual conferences, or give away t-shirts and thumb drives emblazoned with the 4-D logo. I’m not even suggesting that this cycle replace your current development lifecycle — just that you think of this as going on in parallel.

And if you think of a good name for my single 4-D deliverable, let me know!