Techn@gerial

Various posts on this blog have discussed the vagaries of planning for software development projects. This post goes a little further than that and will explain what can happen when you get good at delivery and confidence grows in your ability to deliver. This may not be easy to read if you are currently delivering successfully.

There is a cycle in any company’s ability to plan software projects end to end. The cycle usually starts badly with massive undertakings, failures, disappointment, unhappy customers and even sackings. However, with decent project managers and a business that is willing to learn openly, this can rapidly improve to a point where confidence grows, the rate of successful delivery increases and people start to smile. Ambition, it seems, is worth considering, great things *can* be done.

So after the renaissance phase of the cycle comes a period of embedded expectation, a period where everyone believes the bad delivery problem has been solved, once and for all. Stuff just gets done, the planning function can exercise its duties effectively and the various stakeholders, resource managers and other contributors understand what is needed and how to work together to build a successful plan. This in turn bleeds into the more strategic planning required to outline and articulate a credible release roadmap, again based on the confidence instilled by having become so good. See my previous post about the Expectation Gap to understand where we are, the gap is filled, with over-brimming optimism and delivery success, resources are matched to the needs of the business and in turn the business is getting what it needs to be successful.

The temptation at this point is to “fill your boots”, get as much of this success stuff going as you can, address all your goals, and begin to blur the line between necessary work and nice to have work, not worrying too much about which project is more important. After all, they will all deliver, right?

Resources are assigned to the max and the business stakes a lot on the basis of this maximal potential. These circumstances, especially in software development will often yield a high level of dependencies between projects, some relying on technology delivered from others to be possible, or simply some have to wait for specialist resources from one to another. The result will be what I call a Porcelain Plan. It may look deliverable and rational, but is likely to be overoptimistic, based on previous balanced success, and due to the likely dependency chains, prone to catastrophic failure if a key component doesn’t deliver as expected. It will look beautiful but be horrendously fragile and prone to shatter expectations and reputations.

You might get lucky, if the business management and leadership is stable, you can be on a roll, continually delivering benefit and the mature decision making, driving rational decisions to proactively avoid problems. Invariably, though, something will change, whether it is a key manager, a supplier, or a wider external influence, like the recent world financial crisis. Then the cycle can turn decidedly negative as business priorities change, strategic focus is forced in a different direction and the best laid plans are suddenly looking oh so unhelpful if not downright irrelevant.  Porcelain is after all difficult to re-sculpt.

The flexibility required to adapt under these kinds of circumstances is paramount and a lesson for all Programme Directors is to ensure a relevant level of unfashionable caution is communicated upwards during successful times. No one will want to hear what you have to say, but given the rigidity of your plans and the speed with which you may have to re-factor them, some float is essential in your planning.

Ultimate rigidity and over-tenacity is not at all suited to software project planning. The *cats-cradle* of technical intertwining is a context that always, always needs flexibility and  often requires priorities to change very quickly. Never discard contingent resource allocation and rational planning, irrespective of the track record or the pressure asserted by the business.

It is absolutely possible to squeeze efficiency improvements out of your organisation but it is all too easy to become a victim of your own success if you think this can continue without growth and without contingency.

Tweet This Post