Models and Biases

One of the abiding myths in economics is that there is such a being as homo economicus, or a perfectly rational person when it comes to making decisions. Now that myth has been undermined by the work of behavioral economists, who have described a whole series of biases and proclivities that control how we think and make decisions.

Their work has been used by the "big number" crunchers to justify a process called business analytics; they claim that by using their models we can avoid these biases and thereby reach a rational decision. Models don't have emotions and they don’t have biases, they're inorganic so they can't be swayed away from the facts. Sounds logical, right.  However, who creates the models? 

We fallible Homo sapiens create the models. us with all our pesky biases and non-rational behaviors.  People who build models do so with an end in mind. The model is built to reproduce a process. It is created from a set of requirements. It is formed from someone's belief in how a process works. That belief requires the creation of assumptions that underlie the models design. We know that assumptions are very susceptible to bias.

For example the financial models that were used in the mortgage industry pre 2008 did not allow for a decrease in property values, the widely held assumption was that property values always increase. Also the efficient market theory, much touted by economists, and its models assumed, no, asserted that the price of houses and shares was always right because the market "knew" all the facts about an asset and would price it correctly. The models did not, and still do not, allow for a price bubble. Can’t happen, so in theory the worldwide real estate crash and the resultant financial crisis shouldn’t have occurred, but it did. Oops. Guess the models are as flawed as the people who build them!

We project managers should always be careful when we are told that the “model” or the “tool” gives us a perfect answer. Unless we know the assumptions that went into building the application we should never take that statement on its face value. Do your own quick analysis to see if the answer is realistic, trust but verify. All PM’s should construct a mental bullshit detector. There’s never a shortage of BS, or people to spread it around!

Maps: The Big Picture and PM’s

I have been on vacation in the UK, a big deal for someone who has had a triple bypass, since it involved a nine hour trans Atlantic flight. Being the recipient of a CABG has a way of moving your “bucket list” from the status of “I’ll get around to it” to “better get started, pronto”.

Most of the week in London was spent "getting culture", as I trailed my wife around the National Gallery, the V&A. Museum, the Courtauld Gallery, both Tate museums- British and Modern -, and the Wallace Collection: Lots of Gainsboroughs, Turners, Monets, Manets, plenty of impressionists, classicists, modernists, with a smidgen of cartoonist. By the end of the week I was in dire need of another  ‘ist’, a chiropodist!

However I did manage to visit Prime Minister Winston Churchill's war rooms under the UK treasury building: the place where he directed the British war effort from 1940 until 1945.

One of the key exhibits is a collection of map rooms that Churchill ordered to be created showing the current worldwide deployment of British forces. These maps were kept up to date, 24/7,throughout the war. Only ceasing when the conflict finished in August 1945.

At a glance the PM, other members of the war cabinet, and the Chiefs of the Imperial General Staff, could see the current position of the war in any theatre: Europe, Middle East, Far East, etc, For the British, along with the Americans later on, were fighting a global war; the other participants were not! So it was important that the leaders could see, and be reminded of, the whole picture and not get sucked into concentrating upon one area, to the detriment of the wider conflict.

The lesson I drew from this museum is that every project manager needs her map room, virtual or otherwise, where she regularly, daily or weekly, looks at her project in total and resists the temptation to focus narrowly on the crisis of the day. So that the important is not crowded out by the merely urgent.

The technique I use is to mind map (http://en.wikipedia.org/wiki/Mind_map) my project or projects and to review and update the diagrams at least every week. At the end of the review I prepare an action list of project tasks that need to be done in the next week. That way I minimize the chances of important actions being overlooked. 

Captain Picard and Blunders.

In one of the Star Trek TV series the main protagonist is Captain Picard and he has a phrase that he uses to indicate that he has made a decision, the phrase is, “make it so Commander Riker”. So in episode after episode he listens to his subordinates as they come up with highly complex solutions to the apparently intractable current dilemma. Solutions involving tachyon beams, time shift distortions, black holes, phase modulation, the face angle on a sand wedge (I made that up) are put forward and in an instant Picard says, “make it so Commander Riker.  And low and behold in a short amount of time it’s done, it works and we are on to the next episode.

Now this is all great entertainment, unfortunately we have a generation of decision makers who have a similar “make it so” approach to policy making. They dream up policy solutions to problems and then give them to someone else to implement or not, as is usually the case.

Evidence to support my hypothesis can be found in an excellent book - The Blunders of our Governments, by Anthony King & Ivor Crewe - on project failures in the political realm. Failures that cost the British taxpayer billions of pounds over a 30 year period. A period that covers governments of all parties so political bias is not present; incompetence, as most project managers know only too well, is not ideological. Ideology may blinker people's thinking, but even if the policy is correct the application may still yet be a disaster.

Nor is incompetence technologically based, many of the examples where poorly conceived from the beginning, the technology just added to the confusion, or in some cases the lack of practical knowledge of the technology augmented the poor decision making. Nothing is so dangerous as a politician or executive who is convinced that there is a "silver bullet" solution to a complex problem.

One of the key points of the book is the apparent dividing line separating the policy makers from those who have to implement the policy; between the thinkers and the doers. In many cases the policy makers failed, in some cases deliberately, to consult the people with practical experience of the processes to be changed or "improved". This failure to consult resulted in the setting of arbitrary deadlines, which often had more to do with meeting political timescales or personal agendas than with how long the work would take. This of course is not limited to the public sector the private sector follows the same pathology. The problem is with the policy maker mind set and the divide with operations rather than with public or private sector. As the book illustrates the private sector companies and consultants called in to work on these solutions failed to meet the level of basic competency. And we are taking about household names in the consultancy field. No names, no lawsuits, just read the book!

So how does a project manager address this divide? How do we try to make the policy makers aware of the problems? Notice I use the word try, for try is all we can do. In reality there is nothing so blind as a policy maker with a dream. They can be zealots, who can see no other way than their way. No other solution. No other timescale.

The answer is through risk analysis. Use your knowledge and the experience of subject matter experts to detail the implications of various decisions. Make sure the findings of the risk analysis are circulated widely. Not just to the immediate stakeholders but all parties with an interest in the policy. In some of the cases quoted in the book key politicians were not aware of the implications of the changes and had they been aware they may have prevented the fiascos. The concept of unintended consequences is very relevant in all major organizations. Decisions have knock on effects that adversely impact other parts of the system, so the wider the consultation the better the chances of minimizing them. In real life “make so” rarely makes anything other than a mess.

King’s Cross and Paddington can’t Bear it!

Generally I comment on the failings of the IT and Financial industries when highlighting project management failings. However this time I’ll use a more traditional industry as an example that project failings are almost universal. It not just the boys using bits and bytes that can screw up, the guys using nuts and bolts are also fallible. 

Over this Christmas holiday period the UK’s Network Rail organization, they are responsible for the rail infrastructure: signals, tracks, overhead power lines, etc, planned to carry out major maintenance work on the main line running from London up the east coast to Scotland. With the main work taking place just north of London. The main rail terminus for this line is King’s Cross station. In addition Paddington station was also seriously affected.(Which lends its self to the slightly humorous title of this piece.) 

The entire exercise was due to be completed on the two public holidays - Christmas Day and Boxing Day - which traditionally have a much reduced volume of traffic, with normal service resuming on December 27th, which is a very heavy travel day with people returning home from the holidays. Despite the efforts of 11,000 workers the work ran past the scheduled completion time, not by hours but by days. The outcome was the closure of Kings Cross station because trains couldn’t get in, and also Finsbury Park station because it couldn’t handle the mass of additional passengers sent its way by the King’s Cross closure. You know things are bad when the police close a station because of overcrowding. 

Currently the executives of Network Rail have not declared what caused them to miss their completion times and dates. As with all these events rumors circulate as to the cause, but early excuses are usually wrong so I’ll wait for the alibis to be prepared and then the outcome of the cross examination when the whistle blowers undermine them. 

What we can opine is that somewhere in this farrago there will be a series of estimates that have very rosy colored assumptions and happy path timings. Best case scenarios will have been run and selected. Project friction will not have been considered and confident projections will have triumphed, and the higher up the chain they went the more confident they became. 

When you deploy 11,000 people it takes serious planning errors to miss your completion date by twice the scheduled time. A project of this size will - should - have had a lot of planning effort put into it. So there’s no excuse, absent a natural disaster, for getting it so wrong. Lots of qualified project managers and executives will have participated in this work and lots of project plans will have been created, reviewed, revised and approved. So not a great advertisement for our profession or methodology. This waterfall has turned into a deluge. 

Sony hack and Risk Management.

The hacking of Sony pictures computer systems is only the latest of a long series of hacking attacks on commercial and government systems. This one became “big” news because it resulted in the release of derogatory comments about celebrities and culminated in the withdrawal of a movie because of threats to cinema chains. 

What has been overlooked in all of the public furore about who the hackers actually were, who slagged who off, and the cancellation of the film’s launch, is the reported poor state of Sony’s computer systems security. Some 3 years ago hackers gained access to the accounts of 77 million paying users of their Play Station network. Improvements were promised. This year both their German and Brazilian networks have been penetrated. Also they allegedly stored all their key passwords in a file called, wait for it, “Passwords” - ‘oh deary me’ as my grandmother would have said - talk about making the hackers job easy! Computer security would appear to have been a low priority for someone at Sony. 

Bad enough that sophisticated hackers should attack your system without you aiding and abetting their efforts with poor security.

The alarming fact is that Sony are probably no better or worse than most large companies. The lack of basic encryption, poor password standards, and lack of effective system monitoring are common place. Any decent risk plan should address hacking and have detailed actions of how the system is to be protected. 

I would not be surprised if somewhere in all of these corporations there are reports that show that these problems exist and also Potemkin spreadsheets that also show that there is no problem. No prizes for guessing which documents the Board has been seeing!

Risk and its consequences

This week I came across two examples of risk. One avoidable, one happenstance.

My wife is a ceramic artist and she shares studio space in an old factory building. This week she received the news that the water main supplying the sprinkler system had burst and flooded her studio to a depth of thirteen inches. Partially submerging her potters wheel and her electric kiln. To compound her misfortune she'd left her laptop on the floor, only the third time she'd left it in the studio. As I write we are drying it out: more in hope than expectation. The rupture of the main and the damage to the laptop come under the heading of happenstance or sh*t happens.

The second incident was reported in the UK and it concerned the computer system failure of the Royal Bank of Scotland (RBS). This failure resulted in some of its customers being unable to gain access to their accounts for up to three weeks. This week the bank was fined $90M by the UK's financial regulator. This fine was in addition to the $112M it paid out in compensation to bank customers and $168M cost of staff overtime to fix the problems. All told the error cost the bank $1.2B!

The reported cause of the error was deemed to be the incompatibility of their old, as in ancient, computer code and their new mainframes, an issue that had apparently been highlighted in a previous audit report but not fully addressed. Now this organization has an annual IT budget of $1B. So money wasn’t necessarily the prime cause, but poor risk assessment surely was. This incident definitely comes under the heading of avoidable. The worrying thing is that there are an awful lot of corporations who are in the same boat, with old code and a lack of willingness to fix it. Tick Tock, Tick Tock, goes the time bomb.

Project Managers and the Goldfish Syndrome

There is an analogy that uses the supposed fact that Goldfish have such a limited short-term memory that for them every trip around their bowl is a new experience. Nothing from the previous short trip is remembered. This analogy can be used for certain sectors of the project management profession: where many projects are a trip around the fish bowl.

This doesn’t apply to projects in the construction and manufacturing industries where they are using known methods and technologies. Most skyscrapers and bridges follow known techniques and industry standards are widely accepted. Only when they start using new technologies are the benefits of the familiar reduced. The vast majority of construction projects are finished, not always on time or budget but they are completed. Our cities are not riddled with partially built structures. Only the collapse of the developer’s finances, as in 2008/9, stops the work once it is started.

Not so in the software world where the analogy is very apposite. Many projects are launched on the expectation of fair winds and favorable tides and with shifting requirements. They are always the children of the victory of hope over experience. The result is a computer landscape littered with abandoned projects. The largest consultancy companies all have multiple failed mega projects on their resumes. But does it stop them and their clients from repeating the same mistakes again? No it doesn’t. The UK Health Service has had a number of mega projects aimed at consolidation patient records, all failed with huge amounts of sunk costs written off. In fact the only thing that has improved on these projects is the size of the losses.

No management discipline can consider itself to be professional when, in significant sectors, the Goldfish syndrome afflicts its practitioners.