How We Box Ourselves In (with Software Projects)

August 28, 2013

In last week’s post I advocated that if our goal is to produce great customer outcomes (at a profit), then we shouldn’t box ourselves in. I outlined some ways that plan-driven approaches box ourselves in, such as by fully defining requirements and approving requirements up front – and then planning oriented around delivering those requirements according to an estimated schedule.

This gets ugly if someone high up in the organization has a pre-determined date in mind. Teams can get pressed into the, “What is the date that I’m thinking of?” game. But it can get ugly for other reasons. I’ll use this post to explore why traditional, plan-driven approaches go bad.

It all comes down to what we believe we need to do to be successful. We have supporting “evidence” that convinces us that we should operate in certain ways. One is the cost of finding and fixing defects:


As you can see, I’ve combined the traditional waterfall diagram with the relative costs of finding and fixing defects along with adding the classic iron triangle to the mix. This combines the notion that we need to be diligent about executing each phase as correctly as possible along with using solid project management techniques to be successful.

While every good project manager that I’ve ever run into will state that they view projects as a series of negotiations – which theoretically provides us with maneuvering room to flex on one or more of the iron triangle’s constraints – in practice many organizations are striving to deliver all of the desired features on schedule and on budget.

And by the way, everyone wants those features delivered with quality, which boxes us in:


Operating from this perspective will get you out of the gate on the wrong foot because there are some key assumptions that are incorrect. The first concerns the relative cost to find and fix defects. This cost model is valid only if the work can flow from one phase to the next in neat, never-changing packages.

Unfortunately that doesn’t happen. Questions arise during the implementation and even verification phases. And when we review working software with the customer, we get the “Now that I see it…” dynamic. We need to iterate to shape the solution.

But traditional approaches make plans around those early requirements and design phases. This is predicated on a belief that we can navigate unique, complex work that crosses business and technical domains on a highly predicable schedule and budget. And this is done despite the fact that there is significant evidence and experience that more often than not, this doesn’t happen – as the figures by the Standish Group’s Chaos Surveys on Software Project Success Rates indicate, to cite one source.

And when things don’t go as planned, a typical reaction is that there is a lack of process discipline in getting these phases correct. If you don’t like your current results, this is the opportunity to change your process – really change it – and adopt agile! You can get better by doing less of some things and (most likely) more of other things.

However, I’ve seen reactions that swing the other way, sticking to an existing process and demanding greater detail in the requirements and designs up front along with more detailed project plans and increased controls and reporting that ultimately send the message that conformance to the plan is what is expected (if it isn’t stated explicitly).

However, because of the nature of the work and the dynamics of software development, this becomes an over-investment in activities that don’t help to improve the situation.

Have you ever seen a snowball get smaller when it rolls downhill? I haven’t. (I have lived my entire life in Maine, so I’ve seen plenty of snowballs over the years!) Snow is essentially crystalline water ice, so a locked-down waterfall model should be considered more like snow, where the view to the development team looks more like this:


This isn’t a model that works well, and what it usually does better than anything else is to make everyone miserable – I’ve been involved with software projects where no one ended up happy, even when the project was “successfully” completed. The personal prices paid were simply too high.