Strategic Planning: Is it a myth in software?

 A project that I've come across is 10 weeks into its expected 57 week duration. Its software architecture has been worked on for over 15 months prior to the commencement of the project. The key to a significant part of the project is a new data model that is planned to remove the problems associated with the existing ram shackled system. The new model has been worked on for 12 months. It is complex but uses industry standards and would make additional enhancements and inter-connectivity easier.

So imagine the surprise when the project leadership announced that it was going to think "tactically" rather than "strategically" and would therefore reluctantly scrap the new model. In its place we would create a simpler model from scratch within four weeks and the project would still be able to make its schedule and provide the level of functionality required. (Enquiries are on going as to the medication that they are using.)

As a rule when managers decided to think "tactically" they are saying that they have realized that they cannot make the project schedule they originally planned. This is usually because they underestimated the work involved, or in many cases didn't carry out any detailed planning work at all. Ball park estimates allied with over confidence are the usual culprits.

So if as a project manager you come across a project with a complex architecture and an aggressive time line be prepared to move into "tactical" mode sooner rather than later. Middle managers love to talk strategy but really they are tacticians at heart. Much happier with duct tape than with detailed drawings. 

Corporations as learning organizations ?

One of the great book selling ideas of the late nineties was the concept of the learning organization. It was based on the premise that organizations that are successful in the long run are those that are continually educating themselves and in order to do this they have created sustainable methods to institutionalize it. Each book usually finished with the ubiquitous check list and a road map of how to get to there.

Rather than trying to quantify the impact of this strand of management literature the approach should be to ask the question are corporations actually learning organizations?

I would contend that most, not all, corporations are very poor at learning the lessons of their own history never mind the history of their industry.

In this past week Lloyd's Bank in the UK was fined $42M for mis-selling to its customers. It had instituted, after the 2009 crash, a regime where its staff either made their sales quota or they where fired. The phrase was a "grand in your hand or you're managed out of the business" -that's the new euphemism for firing someone. Customers were pressured to buy financial products they didn't need or understand. So bad behavior, but surely it was an aberration for such a large and venerable bank? Well in 2003 the bank had been severely criticized by the regulators for the same sort of behavior. So not much learned there, then.

Then we have JP Morgan who has paid out a $920M, a fortune in shareholders money, in fines over the "London Whale" episode, as well as losing $6.2B on the derivative trades, the same sort of reckless speculation that brought down other large banks in 2008/9. They exhibited the same toxic mixture of gambling on derivatives allied with poor internal controls and risk management. Again not much learning taking place.

So to paraphrase one of our great presidential orators - George W Bush - "Our companies ain't learning!"

What are the implications of this state of affairs for project managers?

It means that we cannot assume that our leaders are actively conducting lessons learned over their stewardship of the company or that they are harvesting our lessons learned work sessions to ensure that it "never happens again". All the evidence indicates that all our wisdom is not resulting in changes in behavior. Corporate incentives overpower evidence based recommendations for improvements. George Santayana adage; "those who fail to learn from history are condemned to repeat it" rings all to true in too many organizations.

Efficiency v's Robustness

I've been absent for a few weeks due to a trip to the UK to see my old mum and the rest of the family, followed by a couple of weeks of semi-deafness caused by having a head cold on a ten hour transatlantic flight and being unable to clear the fluid from my ears. It was both a blessing and an annoyance. It was a blessing as I work in a Dilbert like cubicle area, so the partial deafness acted like noise canceling earphones. However it was a major annoyance as I was constantly going around saying 'pardon, could you please repeat that.'

During my illness induced isolation I came across a learning episode for Project Managers. This related to yet another computer system melt down for the British bank, RBS. They had a system malfunction on Cyber Monday that lasted for quite a few hours during which their customers could not use their ATM, Debit, and Credit cards, or access their bank accounts. Many of their customers could not take advantage of the super deals on offer. More disconcerting was that they could not pay for purchases at supermarkets and petrol (gas) stations, or get any cash. Given that the bank handles 250,000 ATM type transactions per hour it meant that close to a million of their customers were seriously inconvenienced by this error.

This snafu on their computer system was a follow on from RBS's major melt down eighteen months ago when their customers couldn't access their accounts for days, in the case of their subsidiary Ulster bank the outage lasted for over a week for some customers.

The learning lesson is not that this bank has a less than stellar computer system, it is that it had lots of customers who where totally reliant on them for all their financial tools: Single bank account, single provider of debit and credit cards. The customers had no back up resources. All their eggs where in one basket, and it was a basket with a poor track record. Had these customers had accounts and cards with banks on different computer systems then they would have been inconvenienced, but not embarrassed. Standing by a petrol (gas) pump having filled up and not being able to pay is the epitome of embarrassment.

The lesson for project managers is that you need avoid all single points of failure that can bring your project to its knees. Even if that resource or asset has a good reliability record. There is no substitute for redundancy in a system when it comes to reliability. This lesson is particularly relevant in this age of cost cutting and efficiency. It is not commonly appreciated that the more efficient a system is the less robust it is. Efficient systems are by definition full of single points of failure, in fact the aim of creating the most efficient system is to remove all redundancy and make every element a single point of failure. In a choice between efficiency and robustness for critical systems we should pick robustness. 

Project Managers: OODA Loop and Act

Act is one of those multi- meaning words that infest the English language. Words apparently created to trap and confuse the learner and the unwary. In our context it means to execute a decision: to do. 

And if there is anything that separates the successful from the failures it is usually the execute phase of the project. This is the area where expectations meet results and the encounter is often unpleasant. 

It is also an area of great political risk. On many projects the initial phase of project evaluation and selection is usually a battle of ideas and concepts. Of contending visions and aspirations. In many instances it is a conflict of estimates and benefits, project A against project B. nothing is concrete, all is conjecture. 

Not so in the Act phase. Now we have a schedule and a budget to be measured against. And just because the decision has been taken to proceed it is never an irrevocable decision. Many projects are cancelled before they are completed, according to many experts not enough of them suffer this fate, and therefore this is when you enter a new iteration of the OODA loop. 

You have to be continually observing what is happening and orienting towards the changing situation. You must move into the observe phase of the new loop cycle from the first day of your project's execution. Remember it is never too soon to start failing. 

Fractals and Management

In project management the theory is that we have some bad projects, but that in the main most projects are well run, on time, and on budget in all companies. In fact it's not even true for most companies. Why is that?

The project management discipline has been, in its modern critical path guise, around for over 50 years. So practice of that age should now be delivering repeatable and predictable results. The usual advice given to people on how to acquire a skill is: practice, practice, practice. Well we've been practicing project management for decades and yet we seem to be no better at it. Of course the unwritten assumption in the skill acquisition adage is that you're practicing the right thing!

If so many companies have problem projects then the question has to be why? The usual approach to answering this question is to conduct lessons learned sessions and then change procedures to ensure that it doesn't happen again. And yet it does! No amount of fiddling with methods, tools, or procedures seems to make things better.

Benoit Mandelbrot, Nobel Prize winner, developed the concept of fractal geometry. One of whose points is that as you magnify a given shape you see the same shape, and as you increase the magnification you see the same shape again.

So what as this to do with projects?

Well maybe it's not just the projects that are troubled. Look at the management level above the projects. Are they troubled? And are the layers of management above them also troubled. Like the fractal under the highest magnification maybe they are images of the layers above them. Projects will reflect the behaviors of the management system within which they exist. If top management is reactive and panicky then all the layers below them will exhibit the same attributes.

Bad management must be a systemic issue because if it weren't then good management would have exercised the practices from the body corporate.

So if you see a number of troubled projects don't just look at the individual projects, also look at the management milieu that they exist in. Look at he management chain and if you see fractals then you know you have a serious problem.