Old economic paradigms don't die, or fade away; their believers get awards.

In the past few months the Institute of Economic Affairs in the UK announced it's annual award to the person who made great contributions to free enterprise during their working life. The recipient of this honour was Viscount Ridley, the Brits do love a Lord, who's main claim to notoriety in the UK was to be Chairman of The Northern Rock Bank, an institution that had existed since 1850. It started life has a building society and converted to a bank in 1997, following the trend advocated by the IEA and Thatcherite economic theology.

As a bank it adopted the prevailing economic ideology, and then some, and followed a highly risky loan strategy, which included giving borrowers mortgages of up to 125% of their properties value! The end result was that in 2007 it suffered the first run on a British bank in 150 years. It had customers lining up outside it branches demanding their money back! Over a few days they had to pay out $3B. But it wasn't enough and the Bank had to be nationalized at a cost of $40B to the UK taxpayer.

Yet the man who presided over this debacle, the 5th Viscount Ridley, instead of facing any sanctions or censure ends up, seven years later, being given an award for economic achievement! A decision that would beggar's belief in rational world. Lose billions and get an award. The epitome of failing upwards.

So what does this mean in the project management world? We have an entrenched paradigm that is waterfall, and we have contending methods such as Critical Chain (which is a variation of waterfall) and Agile. Like the failed “efficient market” model in conventional economic theory education, waterfall is considered to be mandatory on all project courses, especially for beginners. So any “new or improved” PM model has to overthrow decades of conditioning and also to get the PM establishment to demote waterfall to a subset of models that only deal with well established technologies and methods. As the financial example above indicates getting any establishment to change is difficult even when the evidence of failure is over whelming.

OODA Loop and Six Honest Working men.

The famous British writer Rudyard Kipling wrote that in carrying out his work he used “six honest working men”: Who, What, When, Why, Where, and How. By asking these questions he could write an article for a newspaper, a poem, a story. They were the starting point for his exploration of a subject.

Similarly they should be the foundation for all project managers combating bias and the tendency to believe that “What you see is all there is” (WYSIATI). Forcing yourself to ask these six questions when you reach the Decide portion of the Observe, Orient, Decide, Act (OODA) loop will prevent you from rushing to a premature conclusion because your mind’s system 1 (the reptilian part) overrides your lazy system 2 (the rational analytical part). 

Certainly after every new piece of information you should ask yourself “so what?” What does this piece of information mean? What is its impact on the current situation? What should I do with it? And so on with the other “honest working men”. It doesn’t mean you’ll always come to the right conclusion, but you are certainly more likely to avoid a rushed one. 

Conclusions, WYSIATI, and the OODA loop.

In his book 'Thinking: fast and slow' Daniel Kahneman introduces the concept that our brains have two separate systems, the first one is fast thinking and is what we use to recognize danger and decide whether to fight or flee, the second one is slow and is what we use to analyze complex situations: buying a car or a house. The problem is that system 1, to use Kahneman's terminology, is always on and always making judgments, jumping to conclusions on the merest amount of evidence. It doesn't evaluate the quantity or quality of the evidence, it just takes what it has and comes up with a conclusion. It doesn't search our memory for additional facts that might contradict or even confirm its conclusions. It acts as if 'What you see is all there is,' or WYSIATI. Unless we make a decision to engage system 2 then we are at the mercy of system 1.

This genetic predisposition has profound implications for the Orient phase of the OODA loop. Left unchecked system 1 can open the door to all kinds of filters and biases that will screw up our evaluation of a given situation. Causing us to make poor decisions. We need to discipline ourselves to always question what our first reaction to information is. Ask ourselves is this all the information there is? What is the quality of this data? Are there other facts available to help me to better analyze this situation? It takes time and effort but it is what a master politician or strategist does. 

PM Education and Briers law:

A good friend of mine on hearing me utter for the umpteenth time my advice that for projects: “its never too early to start failing” sarcastically named it Briers Law. Well what applies to projects also applies to the profession and particularly its education courses. The main examples are the Introduction to Project Management ones given to executives and consultants, usually the only course on Project Management that they ever take.

These courses are specifically designed to give their attendees a simplified explanation of what happens on a project. In fact in many cases the courses are not merely simplified they are made simple, as in Project Management for Morons!

The attention challenged executives and consultants in fact demand short, the shorter the better, simplistic courses because they don’t have the time to spend on a detailed course. In other words they don’t want to be educated, never mind seek a deep understanding of the process.

During the simplification of course material all the uncertainty associated with projects is swept under the carpet. Complexity is expunged from the process and the sequential process of waterfall is explained in terms an average eight year old could understand. The aim is not to create a sense of unease in the attendees by exposing them to the realities of life, but rather to give them a sense of comfort that project management is not that difficult.

From this education they take away the certainty that definite, deterministic end dates can be derived and managed to, irrespective of project scope and complexity. And that a project budget can likewise have a definite value that can be baked into company financial plans with all the permanence of a tombstone carving.  

So from the very start of our project management education curriculum we open up the possibility that some, maybe many, of our executive students gain incorrect expectations about what they can expect from project management processes. And in doing so make life very difficult project managers who work with them. Truly a fine example of Briers Law: It’s never too soon to start failing.

Project Measurements: Standard versus Specific

A common question for all project managers is:  "Am I measuring the right things in order to gauge my project's health?" We all know about earned value, burn rate, project velocity, issue resolution, days outstanding on bugs, but these are general terms that can be applied to any project. In many cases they may mislead you as to your projects progress, earned value certainly can hide issues until it's too late for the project to recover. 

The dangers of only relying on a standard set of measurements were brought home to me during my recent cardiac experience. During my visit to the Emergency Room the medical staff measured my: pulse, blood pressure, and took snapshots of my EKG readings. All were very good, all in the range for an excellent heart condition. In fact at one stage my wife and I were getting concerned that they would say there was nothing to worry about!

However the medical staff was not treating me as someone who needed to have his heart monitored, they were treating someone complaining of medical problems. So they also ran specific tests that would investigate the reported symptoms, one of which was a blood enzyme test that indicated that I had in deed had a heart attack. Good for me that they did, otherwise I wouldn't be writing this entry.

So what as this to do with projects? The answer is quite a lot. You can't treat all projects as being the identical and run them just using a set of standard metrics and expect everything to turn out fine every time. You have to be listening to the project team members, to be monitoring the interfaces with other work groups, to be using situational awareness, to be checking the symptoms of your project's health. The standard metrics are the minimum you need to use, not the only metrics.

So listen to your team, look for abnormal items and that way you end up paying for a cardiac surgeon rather than an undertaker. They cost about the same but only one has an upside to their profession!

Agile, Cabbages, and Cardiologists.

Apologies for the long interval between postings, at the end of May I went on vacation to Hawaii. Just at the end of the second week I became, in medical slang, a CABG, no not the vegetable, I was the recipient of a cardiac arterial bypass graft, three of them to be precise. Some end to a vacation!

One of the interesting events during my medical treatment occurred on the morning of the actual operation. I was literally wheeled into the operating theatre, moved to the operating table, surrounded by a surgical team all bustling about their duties when all of a sudden the cardiologist calls "Time Out". At which the entire surgical team paused and was asked to give details of what they knew about the operation and raised any questions they might have. So I knew that it was me they believed they where operating on and what they were going to do to me. So it was a "Scrum Meeting", Needless to say I was paying close attention to what everyone was saying. They even asked me if I had anything to say. Silently I hoped that they were all on their “A” game.

My second thought was that I can't get away from project management even in extremis!

Needless to say it was successful, so chalk it up to another success for Agile practices.