Into the Twilight Zone

• The Body of Bad Knowledge
• Out of your comfort zone and into the Twilight Zone
• The emerging Project Manager
• The Critical Issue
• The Body of Good Knowledge
• The key to project management - mind-set
• Readings

Bad experience is as easy to pass on as good experience.

Here's a little test for you :

Do you know the time honoured learning that whenever you give an estimate you must be sure to double it first?

If you answered "No" then I am not sure I really believe you or, alternatively, you have just arrived from the Planet Poonsbain. If you answered "Yes" then join over 10,000 IT professionals that I have asked that question to during our Project Management Workshops.

I was taught this project management trick by Bob Smyth in 1969. In those days, Bob was the smartest person I had ever met. However, as a child of the famous 60's, I was determined to make my own rules.

"What would Bob know? He is over 30 years old!!!"

So, I ignored Bob's wisdom and I didn't double my first major estimate. Our big boss, Les Ion immediately halved my estimate. As I now faced an impossible deadline, I had learnt my first major project management lesson.

Lesson # 1 : Believe anyone who has survived more projects than you.

So with Bob now acting as my Yoda and me as his, now willing, Luke Skywalker, I sat at the feet of the master and learnt and learnt. Over time as I began to explore the world of project, people and team management, I learnt yet another important lesson.

Lesson #2 : People who have survived more projects than you, have probably learnt more about survival than project management.

The Body of Bad Knowledge

After teaching project management to over 17,000 professionals, our group is now convinced that there is an informal Body of Knowledge concerning project management that has been passed down from generation to generation of project managers. [A bizarre corollary to this concept is that there must have been an original project manager who passed on the learning to two project managers who then passed it on to …. and so on.]

This informal Body of Knowledge is totally wrong.

However, as we'll discuss later in this paper, it remains the primary Body of Knowledge for many project managers. As each new project manager, recently promoted from a technical role, looks around desperately for help and advice, some wise battle-veteran project manager smiles and whispers "Take it from me, when ….."

Some of the key learnings included in this Bad Body of Knowledge are:

Good project management is about surviving bad projects

This is perhaps the most critical lesson as it brings with it a fatalistic and bitter set of beliefs such as "All project managers are victims of other peoples' games". In effect, this learning creates a negative environment which validates the associated learnings.

It's OK to make up estimates and to manipulate them

This one are variations on the "doubling your estimate" and other estimation games which I discuss in more detail in a previous paper for American Programmer and on our Web Site.

It's acceptable to lie about what work you do on time sheets

If you can't remember where your time went, allocate it to " Research", "User Liaison" or "Meetings".

GANTT charts and schedules don't have to be realistic

Complex GANTT charts and project plans are ideal for pretending that you know what you're doing when you're making it up as you go.

Project schedules are great for confusing management and users

The more complex the project plan, the less likely it is that management and users will understand it…but the more likely they'll think that you are working on a really hard project and are really following the plan.

You don't have to deliver when you promise

After all, you can always blame the users who really didn't know what they wanted anyway.

Users are morons

Obviously. They aren't smart enough to be geeks.

Management are idiots

Let's face it! They believe your time sheets and project plans don't they?

People are a problem

People aren't binary and they are very difficult to understand - unlike programs. My God! They even have emotions!

So you, the American Programmer reader, must ask yourself these questions. How many of these lessons have you learnt, when did you learn them and who taught you these lessons?

The chances are high that you have learnt them; that you learnt them early in your career and; that a battle veteran taught you either directly or indirectly through their actions. If you have been lucky, you will have subsequently learnt that these lessons are just about survival and "playing the game of project management".

Out of your comfort zone and into the Twilight Zone

In 1969, Dr Lawrence Peters and Raymond Hull wrote The Peter Principle which explained how technical professions such as engineering, teaching and medicine promoted people as a reward for their technical skills. However, the continuous process of promotion inevitably resulted in the technical expert being promoted into a managerial position where their technical skills were no longer required. What they now needed was a new set of skills - people and management skills - which their technical career had not provided them [see Body of Bad Knowledge]. In effect, they had been made incompetent by being promoted above their level of competence.

In general, the computing profession has failed to learn The Peter Principle and has continued to promote technical experts into project management and other general management positions. In most organisations that we have worked with, the only formal preparation, education and mentoring available to newbie project managers is from the battle veteran project managers and their Body of Bad Knowledge. Thus, the cycle is perpetuated from generation to generation.

As shown in Figure 1, our group distinguishes believes that there are two related but very different sets of information [and skills] required to manage and develop IT and other products. The Technical set requires expert technical knowledge to understand and develop and is related to the technical deliverables of a project. For example, domain models, data models, use case descriptions, state diagrams, test plans and so on. For most IT professionals, it is into this set that they are trained, recruited and promoted. As they become more expert, they are promoted to Technical or Project Leaders and, eventually, Technical or Product Managers.

The Project Management set completely different to the Technical set. It deals with business and managerial issues of the project such as benefits, costs, project stakeholder relationships, risk management, estimation and so on. Instead of hard technical issues, the project manager is expected to deal with soft issues such as relationship management, politics, people and expectations. This requires a complex partnership between the project manager and the technical manager and technical team. Both parties recognise the unique skills that each brings to the project. The project manager's role is to set and manage the managerial and business context of the project [scope, objectives, risks, quality expectations, benefits, constraints and so on] and, at the same time, ensure that the technical team has the appropriate resources, skills, equipment and technology they require to complete the project. The technical team is trusted to get on with the job.

Fig. 1 - The transition

For many new project managers whose background is technical expertise, this transition is just too difficult. Faced with the complex and intangible issues such as senior management vision, expectations, benefits analysis, personal politics and inter-personal relationships with senior business professionals, the new project manager [with nothing but the Bad Body of Knowledge to draw upon] will often withdraw from trying to resolve these issues and revert back into their zone of comfort - the Technical issues. Who can blame them?

The Peter Principle and the conflict between technical management and project management existed in the building and defence industries long before computing and IT appeared. Historically, the architect [a technical expert] managed the construction of his or her building. Typically, the architect would seek some powerful sponsor [a King, a Pharaoh, a Queen, for example] and, having obtained a commission, would design and manage the construction of their building. A similar situation occurred in the Defence industry, where, for example, a General or Admiral would conceive a new weapon system, lobby Congress to obtain funding and then personally oversee the management, development and construction of the system. However, by the late 1950's, it was apparent that having the technical manager [e.g. architect, General] manage the development project could, and often did, result in a clear conflict of interest.

In Australia, the famous Sydney Opera House was designed and managed by Joern Utzen. After 7 years of construction, Utzon has still not produced any architectural construction drawings and, with the building many years behind schedule and 100% over budget, Utzen was forced to resign. The Minister of Public Works, Sir David Hughes stated to Parliament in 1966, "If the complete control of the Opera House was left in the hands of Mr. Utzen, the building would never be completed" [Hughes, 1993]. The building was finally completed in 1972.

In his stunning book, Running Critical, Patrick Tyler [1986] details how Admiral Rickover, obsessed with building his nuclear submarines, completely mis-managed the project resulting in a compromise of the effectiveness of the U.S. submarine deterrent.

So, we computer people can take some heart. We aren't the only technical people who have problems managing projects.

The emerging Project Manager

However, the defence, aerospace and construction industries addressed this problem by creating a new role - the project manager. Unlike most computing and business groups, the project manager in these other industries is a specialist. For example, on your way home today, examine the hoarding in front of any large construction project. You'll see something like Figure 2.

copyright: thomsett INTERNATIONAL 2006 | contact