Project Managers and Consultants - Gota Bill!

Most consultants are decent intelligent people who can add value to a lot of companies. Consultancy firms are another matter. Their job is to be billing machines who measure success not by the value they provide to the customer, but purely on how much revenue they have extract from a given victim.

Strong words I know, but rooted in personal experience. When you’ve seen sensible people driven to perform in an unprofessional manner by their company’s utilization targets, like I have, then you’d use strong words to.

The first adage in a consultants business life can best be summed up in a paraphrase of Gene Kelly's line in the movie 'Singing in the Rain', which was: "Gotta Dance!": for consultants it's Gota Bill! Gota Bill!

So the first thing to do is to recognize that a consultant is just like a taxi; the meter is always running! If they’re on site with you or assigned to your project and you don’t get them working straight away they’ll still be billing you. When I worked has a consultant clients would sometimes apologize for keeping me waiting. I would smile, say it was fine and inform them that I was a taxi and the meter is running! I usually didn’t find myself waiting too much after that.

Consultant are measured on how much they bill you or your client. Typically consultants are given utilization rates of around 90%. That means that in a regular forty hour week they need to charge for thirty six hours. But the target in general doesn’t account for vacation time, holidays, travel time, sickness etc. So avoiding tedious math it generally means that the consultant is driven to bill more than forty hours per week on your project.

So, in the context of “know your enemy”, if you have consultants working on your project make it you’re first task to find out what their utilization targets are. They will have a significant impact on your budget. If you’ve been planning on a burn rate of forty hours a week and they are billing you forty four hours then it won’t take long for this to show up in your project metrics. You’ll either need to adjust your project plan to reflect this, so they have forty four hours of work to complete per week, or continue to plan on forty hours and tell them, and their management, that up front.

Also watch out for “extra services” that you didn’t know were coming. One device for extra billing is to assign a proportion of their manager’s time to the project. So you suddenly find on the invoice a bill for the efforts of a person you’ve never seen.

Another addition is training time. Some consultants will charge you for their internal training or for internal meetings, your project’s money paying for non-project activities. If you see this type of billing, challenge it straight away. 

Billing is always an issue on projects when consultants are involved. The best political strategy is to have a meeting very early in the project, first week should be the goal, and thrash out the billing process and their billing philosophy. Ask the hard questions and get some concrete answers, no consultant flannel. Then check the first few billing cycles to see what they are actually doing and challenge them if they are doing something other than what they promised. Better to have a discussion when the amounts are small than wait until they are large and it becomes a major point of contention.

Project Managers and Risk - Rumsfeld Matrix

Donald Rumsfeld attracted a fair share of ridicule when he famously announced that:

“There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some  things we do not know. But there are also unknown unknowns – there are things we do not know we don't know.” So, if you consider his response as the ubiquitous grid then he was mentioning that in any situation we either have or do not have information about it, and we either know its relevance or we don’t.  So it isn’t foolish to say that there is category of information about a situation where we have no information and we don’t know it’s relevance. Hard to know the relevance of information that you don’t have. But logically it’s correct. What he didn’t mention, which in many ways is more important, was the category of the unknown knowns. Those pieces of information that we don’t know the relevance of. The facts that we haven’t found a place for: joined up the dots so to speak. These are of a much greater concern. And in his case there was plenty of information known about Iraq that properly understood would have made the aftermath of the invasion less of a disaster. For example details were known about the 9/11 hijackers enrolling in flight training, not being interested landing the planes, and two being on watch lists. Enough to generate warnings in the field. But crucially no one joined the dots at the command level. This is not a critique of what the CIA and FBI should have done, it is an illustration of not knowing the relevance of known facts.  Another example is the sub-prime mortgage disaster. In this case lots of information was known, in many cases warnings were sounded. But at the leadership level of both the financial industry and government no one joined the dots, or, in some instances, wanted to join them.  Yet another example is the Titanic. There the captain knew about the presence of icebergs, but who, in his arrogance and folly, ignored the information, deeming it irrelevant. Also this concept occurs in the realm of unintended consequences. That sad state of affairs were the results of a given policy are more than expected, and not in a pleasant way. In many of these instances the facts were known, but their implications were not. So project managers should be very careful of the unknown knowns. Just because you and your team don’t recognize the importance of a piece of information doesn’t mean it has no value or impact. Make sure all your information is reviewed by a wide range of specialists. You never know, one of them might join the dots and save your career.

”

Team Members - Hyper-actives

This may seem strange that a project manager would see enthusiastic and energetic self-starters as a problem. Well in general they aren’t, as long as they’re working to the agreed plan. They are a positive menace if they exceed the responsibilities of their project role. By straying outside the boundaries of their duties they run the risk of alienating other team members or client personnel.

Every horse no matter how spirited has to be bridled at all times. They only run when the rider says so. 

The German army used to have a guideline on how to handle different types of officer: if you have an intelligent and energetic person promote them rapidly; if you have an intelligent but lazy officer keep him around for in a crisis he will be of use; if you have a stupid and lazy officer then use him to command a barracks or some other nonessential facility; if you have a stupid and energetic officer then SHOOT HIM, because he will cause no end of trouble.

Now I’m not suggesting the use of capital punishment on your projects, but I am suggesting that you do not let your team members go off on their own initiative until you know their skill and interpersonal capabilities. Relationships take time to build and can be destroyed in moments by the blundering of a well meaning but maladroit individual. Should you get someone like this assigned to you then them keep inside the team until you can control her, or ship her out to another project ASAP.

Project Managers and Cognitive Intelligence.

There’s a new book out called Fast Thinking and Slow Thinking by Daniel Kahneman, a Nobel Prize winner for Economics. It deals with new knowledge on how humans think. Fast thinking is the way in which we reach quick and dirty decisions, whilst slow thinking occurs when we weigh evidence and reach a rational decision. Quick and dirty thinking is of the flight or fight variety. While the slow one is of the valuation of different courses of action by weighing all the options. They both have different purposes and can be considered as instinctive versus deliberate actions.

Issues only arise when the methods, particularly the fast thinking, are used inappropriately. A snap judgment on which investment strategy you should pursue on your retirement plan is probably not a recommended method. Weighing all your options when suddenly faced with a rattlesnake also might not be sensible.

The problem we face is that deliberative thinking is hard work, literally, for the brain. It takes focus and it requires the full use of our frontal lobe – the frontal lobe doesn’t do multitasking. So in order to reduce the cognitive workload the brain is pre-conditioned to try out the quick and dirty methods first, they do allow multitasking. It looks for rules of thumb or previous experiences, close or otherwise, to help it come up with a decision. It takes a real effort for us to overcome this tendency to jump to conclusions. The English language is full of sayings that warn us of the dangers of hasty decisions: Look before you leap, Can’t judge a book by its cover, Marry in haste, repent at leisure, Count to ten before answering, etc.

This knowledge is important for everyone, not just project managers, because if you know how the brain really works then you can both adjust you own thought processes and also assess other peoples. In fact in a political sense you can try and trigger a fast response and thereby lead your opponent into error. So paraphrase the Sun Tzu saying: ‘know your opponents thinking process know your own and you’ll be successful.’

Project Team Types - The fire fighter

These are the warriors of the project world, the crisis management specialists; the people who enjoy eighteen hour days and working all night to meet a deadline. There are times when you need these folk. However you don’t need them all the time.

One of the problems with firefighters is that they see all situations as fires. When your only tool is a fire hose then all events are a conflagration. In some cases they are so addicted, yes, addicted, to living in crisis mode that they deliberately go there. They let the project slip so that extreme measures are needed. 

They are like, fortunately rare, actual firefighters who resort to arson in order to get the adrenaline buzz. In addition they glory in working extreme hours and look down on those who plan their work more prudently. There gung ho attitude can lead to project team burn out well before you’ve reached any critical stage on the project. They can also burn through your project's budget if overtime is charged or uses consultants. This attitude is especially prevalent in software project teams.

Handing this behavior is the project manager’s responsibility. It’s your budget and you have to manage it. So restrict over working from the start of the project. Limit their hours and if need be send them home at a reasonable hour.

I was working on a major project with a large insurance company when I noticed that one of my staff was signing on at midnight on a Saturday night! So on Monday morning I asked her what was going on. I got her answer, which was actually reasonable, and then gently informed her that she should curtail it. I was going to need her when the new system came on line and an exhausted programmer was no good to me, she’d create more bugs than she was fixing.

Fire fighters are also judgmental. They judge everyone by the hours they work rather than the value they provide. If you let their opinions color the perception of team members you run the risk of alienating and losing good people. On a project I had a couple of fire-fighters who viewed another programmer as a slacker. Well I had him transferred to work for me at another location and I found out he did great work without the need to be one short step for hysterics every time we had a small hitch. Worked wonders for my budget and stress levels.

O-O-D-A - Step 2 Orientate Part 3 Past Experiences

We are all molded and guided by both our own and our mentors experiences. They provide a ready reference to us when we need to make a decision. The experience of others can be a short cut to gaining knowledge and maybe wisdom. As the German statesman Bismarck said, ‘Fools say they learn from their mistakes, I prefer to learn from the mistake of others’; and George Santayana counseled ‘Those who cannot remember the past are condemned to repeat it’. Therefore derived experience can be a great guide.

Provided, that is, it relates to the current situation. Lessons learned are very valuable as long as they do not lead us to ‘fight the last war’. Also there is a great danger that the lessons we draw from history are the incorrect ones. History is written by the victors and their viewpoint will color the analysis and flavor the conclusions.

Ask the question: ‘Who really won WWII?’ and you’d get different answers depending on who you asked, and also when you asked them. If the question was posed immediately after the end of the conflict then the British would say we did, and the American and Russian would say likewise. Ask in the fifties, at the height of the Cold War and Russian efforts would be downplayed. Ask now, sixty or more years later and you’ll get a more balanced view.

So knowing your opponents past experiences can help you decide how she might respond in a given situation. Also, if you make the situation resemble, in part, that which they have dealt with in the past then they can be fooled.

In commerce lessons learned are incorporated within a company’s business model. If your business model becomes outdated then you are in big trouble. Look at the consumer PC market: Initially the business model of Compaq and IBM was to use distribution channels – dealers and retailers – to put their products in front of the consumer via stores. This meant that they had to forecast the type and specifications of machines that the consumer would want. If they got it wrong then they had unsold machine and eventually obsolete stock.

Then along came Dell and Gateway and they started to build machines directly to a specific customer’s order. They didn’t have to build the machines to a forecast and therefore could adapt quickly to consumer needs and reduce uncompetitive and obsolete inventory. Now they still had to forecast the component parts, but that is a lot easier than forecasting finished goods.

Both Compaq and IBM tried to combat the market change created by the new business model, but their efforts never really worked. They became prisoners to their past experiences and cultural traditions.

Lessons learned, or conventional wisdom to give it another title, can also be a trap for an industry, as well as a company. In the 60’s and 70’s the conventional wisdom was that in order for a television manufacturer to succeed in Europe they need an extensive distributor base that would provide access to a comprehensive appliance repair organization. This view had been created as the industry tried to handle the quality problems that beset early valve based TV’s. The cost of building such a network was deemed to be an almost insurmountable barrier to market entry for new entrants into the business.

However, a combination of quality driven Japanese manufacturers and the replacement of valves by less fragile transistors destroyed the barrier in less than a decade. In fact the barrier to entry turned swiftly from an advantage to a major detriment as this network became a major financial millstone for the European manufacturers. In this case lessons learned mired the industry in a complacent mind set.

Your business model can be a strength, or a weakness, depending upon whether or not other people can respond to it.

In the realm of project management we have the lessons learned from running software development projects. If your cultural tradition is one of using the waterfall approach then your lessons learned will lead you to conclude that what is need are more detailed product requirements, the more detailed the better! Every analysis of both successful and unsuccessful projects will point to the need for better requirements documentation.

However other people have looked at the long list of failed projects and come to another conclusion. For them the problem was that the time taken to create detailed, but never quite accurate enough, requirements was time wasted in a fast changing environment. By the time you had hammered out detailed requirements, the market had changed; particularly in web development. So they resuscitated iterative development methods, of which Agile and Extreme Programming (XP) are the more famous, and deployed them as a more flexible alternative.

So, same issues, but different lessons learned, leading to diametrically opposed solutions.

Past experiences are not only critical in assessing the current situation; they also condition how we respond because they form the basis for our education and training. What we need to know is determined for us by our predecessors in our profession or trade. Old knowledge is either enhanced with new developments or it is discarded as being obsolete. No matter what field we work in our range of knowledge is constrained by the lessons our predecessors learned, or did not learn.

An example of where valuable lessons learned were prematurely ejected occurred in the air war over Vietnam. US Air Force doctrine had determined that dog fighting was a thing of the past. All a pilot had to do was aim his missiles at an opponent many miles away, fire, and then go home. So new pilots were not trained in the art of dog fighting, a skill that US pilots had excelled at in both WW2 and Korea. Well it didn’t work. The missiles were unreliable and the rules of engagement further negated their effectiveness. So the US had to re-learn the skills of dog fighting all over again.

Past experiences have a duality to their value; they can offer sage advice, or completely mislead you: Guide you or mire you. 

Clients and Customer Types - My Way!

Every project has a client or a customer. It’s been carried out to meet someone’s need. It can be a commercial customer or another department in the same organization. Each client is different but a lot fall into dysfunctional groupings.

The first grouping I classify as the My Way mind set.

Most project teams are experienced at what they do; typically they’ve done similar work many times before. So, they have a proven method and working practices. Typically the client has not done this stuff before or, if they have, not often. So, they have no proven methods etc.

Most clients recognize this and accept that you are the experts and follow your leadership. However, there is always a group of people, usually in the bigger corporations, who don’t just think they know better, they are convinced that they know better. They are: the anointed, the chosen, the select, born to rule and guide. So throw away your proven project methods and now start to do it our way. The unproven way!

There’s an old military saying that “plans don’t survive the first contact with the enemy”, well there’s an equivalent saying in project management, to the effect that “implementation plans don’t survive the first contact with the client”. On Day One of your project your client will want to change the approach, the forms, the time recording system and on it will go. How you handle this will determine how badly you will fail. For even with your methods you know that failure is an option, change the methods and the risk of failure increases.

So, how to manage this situation? Trust me no one wants a major row on day one of the project, no one. The first criteria and the most important, is that someone in your organization needs to grow a set of testicles, figuratively speaking for our female readers. You have to show early on that you are not going to be shoved around by the client. The customer is not always right. Being a customer does not endow people with the gift of infallibility. Wisdom is not doled out with every purchase order that is issued.

Secondly you need to look at what they are asking for and select those issues that cost you nothing but will give them a warm and fuzzy feeling. So, changing a reporting form to meet their internal needs is OK. You can use it during your project review meetings. Allowing them to dictate the sequence in which you implement or build you solution is not.

I once worked for a software company and when we where installing a solution the customer wanted the system implemented in a non-logical manner. We tried educating him and his staff, for it was a he, it’s nearly always an he, to no avail. Then our management, salesmen to a man, caved in. Their testicles miraculously shrank over night. Needless to say two months later, the penny drops with the client, but we have lost time and the client and salesmen have forgotten why it happened. It’s a sad fact of life but the My Way people have short memories. They will never acknowledge that their meddling caused problems.

So, to repeat, give them some simple cosmetic changes to allow them a trophy or two, but refuse to change your method. You might think that this is a drastic step, but the alternative is sure failure. Once the termites get into your method and start chewing, you’re going down and your project will be a failure.