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. 

The Project Manager as a Conductor

One of the favorite analogies in project management says that you can consider a project as a piece of music and the project team as a group of musicians: Band, Orchestra, Ensemble,etc. That makes the Project Manager the Conductor or Leader, the person responsible for making the group play and the music to flow. At it’s best the music is transcendent, at its worst it is a cacophony of discordant notes: Beethoven or Schoenberg, Teamwork or muddle. 

The important principle is that members of the group have to understand their role and the impact it has on the performance of the team. Critically the smaller the team the greater the impact of each role. A bum note in a sweeping orchestral movement will be lost, the same error in a string quartet is calamitous. However in a small group feedback on a performance is quick. The error and its creator are obvious to everyone, including them. In a large group then people can deny error and pass it off to another player. So the second violins as a section “carry the can” rather than an individual violinist.

Where the analogy breaks down is in the world of matrix management of resources. Imagine an orchestra in which every section is answerable to a different conductor as well as the person who is standing on the podium in the spotlight. And at random periods during the performance the section conductor is giving different advice on how to play the piece, or worse yanking the player off the stage to play for another group. 

Matrix management manifestly will not work for an orchestra, and it often doesn’t work for projects. Pity too many managements don’t realize that fact!

Project management, software development, and executive management- an intellectual void

The software industry has been in existence for around 60 years. That was when the foundational ideas of Alan Turing and the genius of John von Neumann were turned into practical usage. Project management has been around for millennia, the Pyramids didn't build themselves. But in it's modern recognition as a separate profession it is also about the same age. Similarly modern business management became a teachable subject around the same time.

Yet the three practices do not co-exist in harmony. You would think that after all this time that they would have worked out how to relate to one another, understand each other's needs, and develop common series of practices: Construction has, movie production has, automobile manufacture has. Software? Not really.

Software has developed many astounding applications and enabled devices that where in the realm of SciFi a decade or so ago. Yet the number of projects, large and small, that fail is high. The UK has been trying to create an integrated system for it's healthcare system for decades. Best minds employed, big budgets, etc and it's been one failure after another.

You could argue that it is only the big complex systems that fail, but ask any internal IT department about the success rate of their projects and you'll get a deluge of horror stories. A lot of companies have trouble consistently delivering $50K projects on time and on budget.

Even if the project and software teams have a methodology they have a hard time of explaining their process to their business management. Software projects may be moving to a more flexible iterative process and yet their executive management is still wedded to point in time solutions. "How are you tracking to your milestones?", is a common question. Explanations of the new approach elicit nods of understanding, followed by a repeat of the same question.

Executives are not educated to handle uncertainty. They are trained to expect firm dates and to track to them. Their "profession" lacks the intellectual honesty to admit that they cannot predict outcomes. They expect, no demand, definite dates and expect everyone to stand by their initial estimates, no matter how circumstances change. They are in a state of intellectual denial, in an intellectual void.

Team Morale is Key

A key measure of a team’s health is the state of its morale. High performance groups typically show a good level of social cohesiveness and tolerance. It doesn’t mean that they are free from disagreement, what they are free from is acrimony. Constructive argument is good, destructive bickering is bad. So one of the tasks of any management is to maintain the morale of its workforce. 

At the project level it means constantly assessing the level of cooperation within the team. Low levels of cooperation are an indicator of poor teamwork and morale. It also involves making every member of your team feel that their contributions are essential and that they are regarded has valued members of it. 

The wide spread practice of forcing performance ratings that follow a normal distribution on a team is counter productive to maintaining good morale. It is hard to think of a more destructive action than forcing managers to rank their team within a prescriptive range. It doesn’t take long for people who have been designated as a poor performer to start acting like one.

Maintaining morale is a key management function, it cannot be delegated to some other body. One sign that a management team has run out of ideas is when they create a Morale Committee consisting of members of their workforce. Basically they are saying we know your morale is bad, so fix it! So if your company creates one then it’s time to reconsider your decision to stay there. Bad management cannot be fixed from within.