Great ideas from my research archives: “By randomly allocating objects across all the miniheaps, DieHard makes many memory overflows benign ….  The effect is that, in most cases when running DieHard, a small overflow is likely to have no effect.”  Emery Berger, Software Needs Seatbelts and Airbags, Communications of the ACM September 2012.

Ok Bruce, you tell us to get rid of buffers (time between tasks, extra resources, etc.) to force us to deal with our inefficiencies and then you tell us to put in buffers to handle random error situations!  Make up your mind!

For more see the series on Honesty Buffers

OK, let’s try to sort this out.

First, we usually need to get the current job done.  Second, we need to continuously improve at what we do.

How do we do both of these at the same time?

I want to deliver my project in six months.  However, we’ve never done a project like it in under nine months.  How do I get it down to six months?

We don’t.  At least not the first one.  We start three months earlier and take nine months because that is our track record.  We deliver on time, with good quality and an improved process.

An improved process?

Yes, an improved process.

What are those improvements going to be?

I don’t know, but our folks will figure out how to do most things faster and more efficiently without us having to say a thing. This assumes we allow them a reasonable schedule and actively encourage them to find ways to do a better job while they are doing their current job.

I don’t believe that!

I know, most people don’t.  It appears to be counter-intuitive. I wish I could guarantee it but while it has always worked for me, for over 30 years, I can believe it won’t happen in every circumstance.

OK, but that doesn’t explain why in some cases we take out buffers and in others, we put them in.

Sure.  When we are working to improve our focus is first on getting the job done.  In this case, using my classic “use the average past project duration for your current project’s duration” we are potentially putting in more time than we need (about 50% of the time).   Yet, once again in my experience, this will take a project organization that regularly and consistently delivers projects late and gets them to where they deliver most, if not all, projects within a few weeks of their target delivery date.  This also means that to deliver on time we often have to start earlier than we’ve started in the past.  Both of these things, starting earlier and agreeing it takes longer than we had planned for in the past, are hard things to admit in most organizations.

Now we are delivering on time.  Our quality will improve and we’ll improve how we do our jobs.  This is where we start to employ techniques such as eliminating buffers (including honesty buffers).  This is also where we need to fight to keep our success going. As with most organizations I’ve worked with, there still remains that internal friction and often dysfunction that caused us to have unsuccessful projects in the first place.

See how to not get taken for granted after becoming successful

In the quote above, the notion was to allocate extra space and to allocate it randomly across all the available space.  Here the purpose is to handle the common errors we encounter in programming.  We still want to work towards removing the need for these techniques, by eliminating bad coding, but first we want to deliver working programs (and stay in business) and then we want to reduce or eliminate the errors (increase quality).  In one organization we would turn off all the software “seatbelts and airbags” while we developed and tested the software but would turn them on in the final product delivered to the customer.

The bottom line is that every project management tool we use is used in a context.  We need to understand the tool and when and where to employ it and when to remove it.  This insight is why such elevator pitches and one-liners such as “you can only manage what you measure” or “let’s do Agile” don’t work magic in many cases.  These things have to be applied where it makes sense to apply them.  Watts’ Humphrey in his book “The Software Process” stressed that we needed to work on improvements based upon our current organizational maturity. Where we are now, currently determines what kind of things we would work on first.

See the One Perfect Project Management Methodology

Are you working on the right projects for what your organization needs to do now?