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.

9 comments

Nice article, it must be once read by every software developer they know more best ways of pricing their built software to clients...Great Share

November 14, 2013 at 6:38 AM
aliya seen said...

This is so simple to do and reliable source. The wordpress mailchimp plugin is quite useful to build perfect page.


March 9, 2016 at 6:53 AM
jasa seo said...

jasa seo terbaik di Indonesia

June 8, 2016 at 4:04 PM
Cloud Hosting said...

Everyone loves what you guys are up too. This kind
of clever work and coverage! Keep up the terrific works guys I’ve added
you guys to our blogroll.

November 27, 2016 at 4:29 AM

The process of developing custom software is a nightmare for me. We all know how clients often have high and unrealistic expectations, from tight deadlines with crazy software feature requests, endless revisions and bugs-fixing, expecting lifetime maintenance without willing to pay the cost, etc. I prefer to develop a product-ready software which is easier to sell and fast cashflow.

February 3, 2017 at 6:37 PM

nice post and articles, thanks for sharing

August 31, 2017 at 8:53 PM

Post a Comment