Project Managers and the A team conjuncture.

One of the enduring memes in management is that if we can only get the best practitioners on a problem - the so called A team - then all problems, no matter how difficult will be solved. In the project world the client always insists at the contract signing that they want the vendors "A - team" on the job. The vendor solemnly promises to do just that, "a team". The change from upper to lower case is of course very significant.

But the myth of creating a team of super performers that will deliver success has often been proved false in the field where it can be readily tested: Sports teams.

The history of sports is littered with teams whose performance wasn't even the sum of its parts. In soccer the Real Madrid teams of the mid 2000's, the era of the galacticos, were long on stars and short on results. Everyone wanted the adulation, no one wanted to run hard and defend well.

An example of what happens when you recruit super stars and ignore team chemistry can be found in the movie "the Miracle at Oxford". The movie recounts a true story about what happened to the Oxford boat crew when, in 1987, they decided to steal a march on their rivals, Cambridge, by recruiting top American international calibre rowers for their men's eight.

A slight digression is in order to explain the context of this situation. Every spring since 1856 the universities of Oxford And Cambridge have had a race on the River Thames in the heart of London. Each university puts out a crew in a Racing eight - that means eight rowers and a cox - to race over four and a quarter miles on the winding tidal river complete with bridges, eddies etc. This is in direct contrast to normal International competitions which are held on lakes, are dead straight, a third of the distance, and raced in clearly defined lanes. In other words it is a completely unique race, in a unique, almost eccentric, setting. Plus the race and its rowing community have the weight of decades of tradition on their shoulders.

Into this unique environment, with a coach who has won 10 out of the last 11 races, are transplanted five American world-class rowers, with egos to match. Well it goes wrong, there's a rebellion/ mutiny and they are thrown off the crew. The coach then puts together a crew from the loyal members of the crew plus rowers from the B team. He balances out the strengths of the remaining rowers and in appalling conditions   - it is not unknown for one of the boats to sink - they triumph against what on paper was a better crew.

The learning lessons from this movie are that getting the best in the business does not mean that teamwork will occur. In some cases it will never occur. Super stars have super egos and a sense of entitlement to match. Also a lesser stressed point in the movie is that to make a racing eight fly across the water requires a level of coordination and timing that is easy to state and hard to achieve. A racing eight has its rowers alternately rowing left then right. So if the four rowers who are pulling the right side oars are stronger then the left side rowers then the boat is going to veer sharply to one side. Timing is crucial, all the oars should enter and leave the water at the same time, all the time. Many great rowers cannot row effectively in an eight. So the coach doesn't just have to pick the best rowers, he has to pick the ones that can harmonize best, can last the full course, and he has to place them in the right seat in the boat.

Sounds just like a project team. You need good performers who can work with others, aren't going to behavior like diva's, and who have the capacity to last for the length of the project.

So if you want an entertaining movie, with management lessons, watch Miracle at Oxford. Unless of course you’re a Cambridge fan, in which case you know the story already.

Project Managers and "an Annoyance" of Auditors

One of the more recent developments in the corporate world is the advent of internal IT auditors - they even have their own institute! I think they should also have a group noun - I would offer up 'an Annoyance'. 

Once restricted to the accounting world they have recently migrated, infested might be a better description, to the IT domain. Like some invasive species they have been introduced by the bean counters into an foreign clime and they have flourished. How could they not!

The IT world does not sit well in the realm of tight controls and methodology. Developers are loath to accept tight controls, they need the calming interface/buffer that a project manager affords to relate to the outside world. "Deal with the client/ customer, I just want to code", is their typical mantra. One of the main rationales for the spread of Agile methods in IT has been the manifest deficiency in requirements gathering processes and the fast pace of modern development needs. Speed, velocity, responsiveness, flexibility are the new watchwords. Not words that one necessarily associates with auditors. The oft quoted description of an auditor is a person who couldn't handle the excitement of accounting! The same could be said of an IT auditor, a guy who couldn't handle the excitement of being a methodologist!

Now I'm not saying that auditing our processes has no value: Far from it. Anything that constrains the cowboy developers is to be welcomed. Proper version control and release management is a pre-requisite for a mature development shop. However the unholy alliance of an over prescriptive methodology and a pedant auditor can cause havoc. The result of the union of two zealots is always fanaticism. To paraphrase Oscar Wild "to have one zealot might be considered unfortunate, to have two can only be described as carelessness!"

The usual result is that your development team will become bogged down in requests for information and may event become paranoid. Afraid to commit to anything and demanding everything be signed off in triplicate before anything is started. One thing that will happen is that productivity will be reduced and flexibility will be minimized.

So how do you handle this threat?

Well the one thing you don't do is take them head on in the early stages. You aren't going to win that fight. Not at first. The right response is patience. Fanatics always overstep the mark. Nothing is ever enough, their appetite for more and more information just keeps on growing. So feed them the information, keep good records and detail all the productivity hits this work is causing. At some stage the business leaders will realize that their responsiveness to the market is being compromised by the workload associated with the internal audit.

Remember internal audits are self-imposed costs, they differ from external audits in that they are discretionary. They can go away or be scaled back at anytime. So patience is the byword and good record keeping is the method. There's no profit in auditing and bosses are judged by profits. 

Uncertainty and the OODA Loop

This week I heard about two incidents that affected a good friend of mine all in the same week. In the first instance the project she was running had it's business analyst re-assigned at extremely short notice, less than a day. Now given her knowledge of the company's current activities she was annoyed, but not shocked. She'd been anticipating it for a week or more. So the only really uncertain element was the timing. She'd already formulated options for managing the situation. The individual had been asked to make sure certain key project artifacts were either completed or nearly finished. Here her reliance on the OODA loop stood her in good stead. She'd been Observing the environment and formulating her options. Working out what needed to be done, who needed to be consulted and what decisions needed to be taken by who. So, when it occurred she was able to quickly Orientate to the new situation and make Decisions and start to Act

The second instance involved a key team member on another project having emergency heart surgery: There one morning, in the the ER that afternoon. So now she's scrambling on a project that has major implications and whose sole expert is now out for at least two months. She's currently in the Orientate phase. She needs to bring together both her personal knowledge and her teams expertise to develop a new plan.

Uncertainty, in it's various guises, had occurred on her projects. Now if she was a deterministic type of person she'd be cursing her luck and running off to her manager asking for help and refusing to budge until guidance had been given. However she's a probabilistic type, understands that stuff happens and she's going to keep moving forward while waiting for some guidance from her managers.  She understands that uncertainty is the way of the world and that you embrace it and get on with it. Using the OODA loop mental set she's able to re-calibrate her expectations and her plans.

Reality based Project Management vs Matrix Management

 Matrix resource management is the main project structure in most large companies. With it comes a disconnect between project and business goals on one hand, and departmental priorities on the other. Matrix managers are more concerned with handling their budgets and keeping their bosses placated than they are with business and project goals. Now they will strenuously deny this, but, as always, their actions never lie.

In the matrix world reality cannot be allowed to intrude until all the possible alternatives, no matter how implausible, have been endless considered. Consuming time that puts even the reality based alternative in jeopardy. But the illusions of their superiors cannot be disturbed until it is politic to do so. During the Second World War when the allies surged ashore in Normandy the German reaction was hamstrung because vital reserves could not be moved with Hitler's express command, and he was asleep and no one dared to wake him! Times may have changed but human nature hasn't.

Now matrix world projects are always on schedule until it is politic to tell the truth - by which time it is too late to make any attempt to fix the problem. So when a PM creates a reality based project schedule that accounts for all resource constraints, queuing time in the system, and other obstacles that compose the “friction of life”, matrix managers are aghast. They don't want to change delivery dates from the previously published values, no matter how compelling the evidence is. They are the epitome of the "Bad news bears", you can tell them anything but the inconvenient truth!

I was laying out a project schedule and putting in a modest amount of queue time before development and QA. It was modest and nowhere near the real values, but since the management refused to admit there was queue time, never mind publish the values, it was the best one could hope for. Needless to say the owner of the project tried to push back on the delivery date and it took all my powers of persuasion to prevent it. In this case reality based scheduling prevailed, but in most cases it doesn't.

One thing must be understood, reality always comes through and when it does it usually bites, and bites hard.

Situations to Avoid: Dancing with the PM's

A popular reality TV show is "Dancing with the Stars" in which celebrities are partnered with a professional dancer and perform set dances each week. Depending on the ability, or otherwise, of the celebrity then the professional does more or less work. The flash comes from the 'Pro', the celebrity just has to stay upright! Recently I've come across a business version, real reality in fact. It could be called "Dancing with the PM!"

In this example the management decided that they would implement an application that they had no experience with, they would ask the already overworked members of the department to write the business requirements, they would give them five months to implement the application. The department manager then decided to make one of his staff the tech lead although he'd never managed any tech work before and the contract developers he's managing would be working remotely - 2000 miles and three time zones away.

Now this is we're the "Dancing with the PM" happens. Six weeks into the 20-week project they decide that they need an experienced PM to "help" with the project. He's also in the "New guy" stage of his employment.

I think you can guess the outcome. A team experienced in the particular application would have been hard pressed to make the planned date, this group of novices had no chance. Putting a famous classical conductor - Simon Rattle, Loren Maazel, Georg Solti - with an elementary school band is not going to guarantee great music.

The outcome was that the project missed its delivery date by an additional 16 weeks, the PM did however avoid the fall out, and the department manager did not! Now that was a surprise. Usually we take the fall. So the lesson from this example is that when you take over a project carry out a quick, but thorough, appraisal of your resources, communicate your findings/concerns, and make the necessary adjustments to the project plan.