It's all about priorities, stupid!

Over previous posts I've bemoaned the incapacity of executives to prioritize projects. Too often like small children in the proverbial candy store they want it all. They are great at willing the ends, but lousy at providing the means. When tasked about this the usual response is to trot out glib sayings: be creative, think outside the box, work smarter not harder. All of which carry the sub-text of: "don't bother me with details that's what I hired you for."

Recently a project I'm working on was hit a by a resources conflict with another pressing project. In all truth the other project had a more compelling case in the short term. What was required was a realization that both could not be delivered has scheduled and that my project's schedule needed to be re-planned. Simple really.

“Not so fast my logical project manager,” was the reply. “We need your project to finish on time. Just tell us what you need to manage this problem and we'll make it happen. Give us the information and we'll escalate with senior management.” Sounded promising.

Well five weeks passed and nothing has happened. We are now at a point where action will be futile. The damage is done and can't be undone. The schedule has slipped but in an uncontrolled manner, with lots of confusion interspersed with bouts of frustration. We can manage most things, but stupidity can only be endured.

Experience of working has a team matters more than the sum of the parts.

The longest battle of the Second World War was the Battle of the Atlantic. It lasted from September 1939 until May 1945, thousands of seamen died and millions of tons of shipping was sunk. The combat between the allied convoys and the U-boats ebbed and flowed, with first one side on top and then the other. Technology and tactics evolved at a startling rate, British innovation and American manufacturing capacity ultimately triumphed, but not without many travails and setbacks.

One of the key findings that the navies discovered was that if a convoy escort group - usually four to six warships - had worked together previously the lower the loss rate of merchantmen from the convoy. Even escort groups comprising ships from different navies performed significantly better than those that had ships from the same navy. It was the experience of working together that was important not the common tradition or language. 

This was such a key factor that the British Admiralty insisted that all escort groups undertake a realistic three day training exercise before every convoy sailing from British ports, even if they had worked together before.

So what does this mean from a project viewpoint? Well it confirms what last blog stressed; that teams are better than ad hoc groupings cobbled together under the matrix management rubric. That time spent by the team familiarizing themselves with the task and how it will be addressed before the project starts is time well spent. A lot of projects do have a Kick Off event, these are only valuable if they address the launch of the project and who's doing what etc. However some are just glorified management ego trips - 'look at how smart we are to have got this project approved. Now don't you workers go and screw it up, we'll be watching!' is their tone.

So get your project's shake down cruise - naval term - done as soon as possible and if you can't have the same team always try to have a comprehensive launch event and activities. Remember Briers law: it is never to soon to start failing!

Team Building and Matrix Management

There are four phases in team building: Forming (team is created), Storming (team debates and argues about what it needs to do), Norming (team agrees how it will work), and Performing (team starts to deliver). The first three phases are time consuming and during this period the team is rarely performing.

So intelligent managers try to ensure that they minimize the amount of team creation they have to undertake. Establishing permanent teams is the most effective from a performance point of view. Replacements or additions to the team are easily incorporated.

Compare this with the situation in a matrix management system. Here the teams are loosely integrated, they are temporary, and they go through the Forming, Storming, and Norming phases on a regular basis - with the resultant negative impact on efficiency and effectiveness.

A clear indicator of project performance is the amount of matrix management involved, the more the matrix the less effectiveness, at least during the all-important starting phase of the project. Matrix management helps to invoke Briers law, which states: that it's never to soon to start failing. The time lost in perpetually re-creating teams greatly affects the ability of teams to deliver projects on time.

Prioritization confusion: A fractal sign

One of the first sign that management has lost the plot is when they are incapable of prioritizing projects.

Once when working as a consultant I had an engagement with a manufacturing company in Bolton, UK. During a tour of the factory I was shown the production controller's office. In there I saw the production schedule board, on that board where displayed all the current work orders with their individual priorities. I noticed that the majority of the orders had a red tag against them, and a large number had two red tags.

I asked the obvious question, "What do the red tags mean?" And I was told that it meant they had the highest priority.

"And the double tags?"

"That's because we had so many red tagged orders that we had to introduce a higher priority, an ultra priority, as it were."

So as a consultant I could see where I could make an easy win. Further as I continued my investigations I discovered that the inability to prioritize the work schedule was systematic of the management team's chaotic style. It wasn't an aberration it was a standard practice. It was a classic example of management fractals: Chaos at the top resulting in chaos at the bottom.

Now in case you think this is a problem confined to manufacturing let me tell you about an episode just before the holidays. I'm in a software management meeting when two department heads said that their different projects were the company's number one priority and that they had first call on key resources. Both were shocked to discover that the other project had a same priority, me, not so much. The senior management has a record of defining multiple number ones in all its activities. Their indecision flows down through the organization. They exhibit fractal management symptoms and, like all such managements, they don't realize it. Prioritization for them is a word, not a practice.

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.