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. 

OODA Loop Orientate Step: Denial is not a river in Egypt

One of the elements in the Orientate step is the genetic makeup of yourself and your opponent. This includes the various mindsets, biases, and filters that we use as part of our personality. Denial of facts, evidence that contradicts our worldview is a common failing and it is not only infects individuals it also applies to groups. It is not a condition that only affects the poorly educated; in fact the smarter you think you are the more likely you are to fall for this condition.

This week we witnessed in the UK a prime example in the world, or should I say the alternate universe, of finance.

In 2008/9 the large UK bank HBOS failed with nearly £50 billion in losses. At the time it had £200 billion more in loans than it had in deposits. It was so out of control that a bank that in 2000 did not have one person who owed it more that £1 million had by 2008 9 people who owed it a £1 billion each!

This, to quote its own finance director in 2004, was "an accident waiting to happen". Its failure would have happened without the 2008 financial crisis: That event only accelerated the day of reckoning.

Now you would think that the men in charge of this disaster would have realized the errors of their ways, said a few mea culpas, uttered some apologies, donned sackcloth and ashes. Far from it. To this day they still don't see what they did wrong. It was events that undid them. Their bank was sound.

Last week, in unusually trenchant language, a British parliamentary commission said, "We are shocked and surprised that, even after the ship has run aground, so many of those who where on the bridge still seem so keen to congratulate themselves on their collective navigation skills.” It said of the board of HBOS that "It represents a model of self delusion, or the triumph of process over purpose.”

So if so called smart people at the top of a major financial institution can exhibit denial then it is safe to say it is rampant where ever we look or work. In fact the higher up the management chain the greater the prevalence.

So what does this mean for a project manager who discovers he is prone to this? Well the first thing is to always be observing the situation, processing new information, and incorporating it into your plans. To sound like one of those self-improvement con men you need to be rooted in reality, dreams are what happen when you are a sleep, not when you’re working.

What happens if your management is in denial? Doesn't want to hear the truth. Well the bad news is that people who tell the emperor that he is without clothes usually get fired: Sad and not fair, but a true statement. The only way is to tell the truth and immediately start searching for new job, you’re going to be out of one before long anyway. Denial doesn't hold off reality forever. 

Project managers and the committee.

One of the weaknesses of modern management practice is the neglect of the power of the committee. One of the modern meme's is that committees are bad, weak, staffed by compromisers etc. whereas what we need is the standout iconoclast, who goes against the stream. An Horatio on the bridge type personality, taking on all foes.

Of course this cult of the individual has its downside. One obstinate individual taking advantage of other people good nature can stop everything in its tracks. Mix in the modern tendency to seek consensus rather than reach decisions and in the project world this can lead to paralysis.

How do you manage this situation?

Well the much maligned institution of the committee, in skilled hands, can enforce decisions and move the project along. Now I'm talking about a committee with apparent power to act. Not one who's role is to make recommendations. So it must be a committee with a nominal membership of the main movers and shakers in the business and that has empowered its PM to manage the project on its behalf. Delegated power to give it a fancy name.

These types of committee usually arise when there is an urgent problem to fix in the business. An urgent meeting is called and an action plan agreed. Then the PM is empowered and can act on the plan. Also the PM, through the issue log, can raise further matters and get committee approval to act.

Now she can use the power of the committee to move the obstructionists out of the way.    Even the most stubborn of individuals finds it difficult to hold out against the combined power of the movers and shakers. Now here is where the skilled hands come in. Attendance at committee meetings always dwindles, the great and the good always have more demands on their attention than they have time. So the committee will have a core group - the "turners up" - and if the PM manages them adroitly she can move from taking direction to giving direction. Functionaries run committees, run companies, run nations. Don't neglect the power of the committee.