Project Managers: Manage thyself first

Sun Tzu in his most quoted aphorism said, “ He who has a through knowledge of himself and the enemy is bound to win all battles.” Notice the emphasis on the knowledge of self first.

Many PM”s ignore this key fact. Too many times I see people who are trying to manage groups and they can’t manage themselves: They are late for meetings, they are rarely prepared for meetings, their status reports are always late. In this day of matrix management the only resource that a project manager can truly control is themselves.

A chaotic project manager invariably means a chaotic project. The saying “a fish rots from the head” applies to all projects. If you can’t control yourself, then abandon all hope ye who would be project managers.

PM's and the depleted ego

In the Orientate phase of the OODA loop one of the elements to be considered is the genetic make up of both yourself and your opponent. One aspect of that make up is the mental energy level of yourself, your team, and your opponent during the process.

Research detailed in Kahneman's book "Fast and Slow thinking" indicates that there is a clear linkage between mental energy and decision making. If someone or a group has been struggling with a difficult decision and then is asked to consider a less difficult but still challenging problem they will not think creatively about the matter. They are more likely to go with their default attitude, revert to the norm as it were. Their mental energy or ego has been depleted.

You know that it exists, just cast your mind back to a decision you made just after a stressful discussion. Did you bring a fresh vigor to the decision or did you either go with the prevailing opinion or accept the solution that was being proposed?

This situation typically occurs during meetings with multiple items on the agenda. If a group has struggled with a difficult problem or one with sharply divided opinions then having solved that they have a reduced appetite for more contention. If you have two or three contentious items in a row the mental energy depletion is manifest and subsequent items will be given very short shift.

From a project managers viewpoint the trick is that if you have to change opinions, to persuade, then you want your item high on the agenda or on a meeting with few contentious items on it. On the other hand if you want a decision rubber stamping then you put it late on a agenda, when mental fatigue is at its highest. Also schedule meetings when not only mental but physical energy is at its highest: early in a morning or in the early afternoon. Also if the meeting is dragging on and you can see interest and energy waning then call a recess and give people a period to recover. Unless of course you don't want them sharp!

Projects and Queues

A fact of life that we all experience but, little understand, are queues. Everywhere we go there are queues: at the supermarket, on the highway, at the ticket office, with development resources for our projects. Now some queues can be reduced by increasing capacity, for instance at the supermarket extra checkouts can be manned. In our world queues can be increased by reducing capacity, for instance developers are re-assigned to bug fixing for production and are no longer available to do development.

In many cases the capacity constraint occurs gradually. The highway was built for 10,000 cars per/hr and now we have 30,000! In the past this usually occurred over a long period of time. These days, given the time period to construct new infrastructure, the grace period is months, if not weeks! Basically the design capacity becomes obsolete by changing demographics, but at least the system was initially designed with spare capacity.

In our world, the project world the opposite is the case. Businesses are managed to maximize resource utilization: 100% utilization is the goal, 90% is the norm. In some industries utilization rates even ignore vacation time and holidays.

All this focus on maximum utilization of an individual resource ignores the impact that it has on system performance, or, as Goldratt put it, system throughput. We all know that if the bridge over the river is fully utilized then we can expect a very slow journey home. Throw in some entropy in the form of an accident and minutes turn into hours.

Now whilst this is glaring obvious to the average motorist, irrespective of educational attainment, and that the mathematical basis of queuing theory was determined as far back as 1909, we still have modern managers designing systems that are predicated on the sub optimal utilization of individual resources. The less elegant phrase is "sweat the assets". Yet queuing theory indicates that if as you increase utilization from 60 to 80% you double the queue, from 80 to 90% you double it again. Once you get near 100% the queue gets to be very large indeed. It follows an exponential growth curve.

The result in our world is missed delivery times, increased risk, more overhead, lower quality, and missed opportunity costs. All in the name of higher labor efficiencies. This is typically a case of managers wanting their cake and eating it.

How do you manage in an organization that has designed queues? Well it depends on what your role is in the organization. If you have some management control in the development area then you can start either changing the queuing management - Reinersten's book: The principles of product development FLOW lean product development, offers some good tips, or the utilization values. If you're a project manager then all you can do is try and enter some reality into your schedules by including queuing time and durations that reflect actual time on your work rather than just effort divided by the hours in a normal work day. One word of warning, managers know about queuing, but they don't like it to be advertised. The one thing you must do is detail all the slipped dates due to queuing. List them all, not just the latest one. That way people know that you were ready but the resources were not.

If anyone asks you to explain queues tell them to visualize the last time they where at the post office and head of them in the queue are people with large boxes, lots of parcels, lots of questions, and then the number of tellers is reduced to handle another tasks. How did that feel?  Well just because our queues are not as visible doesn't mean they aren't there.

Queues are a fact of life, even if they are denied by managers. We need to learn how to survive them since managing them in most organizations is beyond the wit of a mere project manager. 

Car Talk and Entropy

This week I've seen a movie with a car racing theme. with lessons for project managers.

The movie was "Truth in 24 II: a matter of seconds" and it recounts the events of the 2011 Le Mans 24 hour race from the view point of the Audi racing team. Audi had a brand new car and fierce competition from Peugeot. The race had Audi losing two cars in spectacular but fortunately no serious injury crashes. Discussions about tyre and pit strategy and design philosophy all play apart when you are racing for 24 hrs. Team composition, including the three drivers per car, and lead car engineer selections all matter.

Today's racing cars, certainly internationally, are complex systems with just about everything being measured electronically. In fact you could get the impression that because everything can be measured that everything can be controlled, and therefore everything is under control. Well that is were entropy - the natural state is disorder - comes in. Disorder or 'stuff happens' plays a great part in the story of the 2011 race: crashes are caused by other drivers making wrong decisions, tires get slow punctures, it starts to rain, windscreens get covered in bugs and become obscured. Stuff is everywhere!

This is similar to the experience of most project managers. We, and our bosses, like to believe that because we have planned for everything we know about that we have everything covered. What the less experienced of us fail to comprehend is that our project is not in a closed system, it is in an open system and therefore subject to entropy (stuff happening). Our projects are not safe until they are finished. Delivery dates are not definite. Deliverables are never certain. Contrary to management thinking chance, stuff happening, plays a bigger part in delivering a project on time in an open system than most people will admit. If you know it can happen it won't help you to avoid it, but it will prepare you mentally to handle the setbacks.

The biggest problem is the mindset of senior management, particularly the finance people. They live in a deterministic world where because everything appears to be countable, measurable, and definable, that they can control it. They ignore entropy entirely and expect us to make dates even when circumstances have changed the initial assumptions.

So how to handle this? Well you need to make them aware on continual basis how circumstances are varying, good as well as bad - remember chance creates good luck as well as bad. Like a good sailor always have your eye out for changes in the weather and always be giving your boss(es) an updated weather forecast.