Project Management Book

...chapter 1 continued

However, people who grow up in construction companies have a different experience. When they joined as a young bricklayer they laid bricks in accordance to the project plan - the customer does not ring up and say: "now lay brick number 735"! Work is not triggered by external stimuli but by the project plan. For executives in construction the imperative isn't so much to answer the phone within three rings but to get the housing estate built in the scheduled 3 years. These guys know all about planning.

The trouble is, trying to do projects in inherently process-based environments can lead to a clash of cultures which can cause many problems, though the cause of these problems often goes unrecognised. Have you ever approached a senior business manager and said: "I need two of your people to work full time on this project for the next month to define in detail the business requirements that the new system will satisfy when we deliver it in eight months time." And received the reply: "You must be joking! I've got a business to run here, I can't afford to have two of my people taken off their job for a month. Come back in six months, maybe we'll be able to tell you then what we'd like the new system to do."

Sometimes people who have never been involved in a project have no idea why it's important to define requirements so far in advance of delivery. They are not being awkward or bloody minded, they just don't understand. You've tripped over a project vs process cultural issue.

If you ask IT people who have experience of large projects what helps projects succeed they will tend to answer: "Planning, planning, planning and more planning." But a process-based manager's reaction to this can be: "No! I manage two hundred people on the business side of my company. We don't feel the need for all this planning nonsense, we just get on with the work and do it. In fact it seems to me that planning is just an irritating, initial delaying tactic used by the IT department to avoid ever doing any real work." Now there's a culture clash for you.

However, you will find that if you take the trouble to explain to senior process-oriented managers what projects are all about, they are intelligent people, they will readily understand and will conclude that obviously projects have to be planned, business resources properly assigned, requirements defined at the outset, etc. But all too often nobody explains and the culture clashes persist.

In a pure process-based company the company hierarchy is primarily designed to manage those at the bottom who actually do the work of running the business (Fig 1):

Figure 1: Process-Based Company Organisation

In the extreme you join the company, say, as an order-taker and there you stay along with 19 other order-takers taking orders for 30 years. Your line manager manages his 20 order-takers and that's the limit of his horizon. We exaggerate to make the point.

However, in a pure project-based company things are different (see Fig 2). A resource pool of 50 engineers report to their line manager, 50 IT staff report to another line manager, 50 financial experts to another, and 25 project managers to another line manager. And they all sit around doing absolutely nothing, just sit twiddling their thumbs all day. Until, that is, a project comes along. Then a project manager is appointed. He selects 2 sub-project managers, 6 engineers, 8 IT staff and 3 accountants and fits them all into a one-off management hierarchy for the project. At the end of the project they all return to their respective line managers and sit and wait for the next project to come along.

Figure 2: Project Based Company Organisation

In practice most companies are hybrids: some of a line manager's staff are doing work for him - their "proper job" - while others are rented out full time or part time to project managers. The line manager now has to be a task manager for those doing work for him, a career manager for those on projects and he also must manage the inherent conflict between servicing the day to day business and investing in the future.

In a hybrid company you could join, say, as an accountant: "Welcome," your boss says. "For your first three months you'll be working not for me but for this project manager." Three months later you return to your boss who then assigns you to another project for six months. In fact you could spend your whole career hopping from project to project and never actually do any work at all for your boss. (Though some would say this wasn't a totally unknown phenomenon even before projects...)

Which skill set tends to be in shortest supply in these hybrid companies? Is it accountants, engineers, programmers? No. Project managers. People who can manage projects in process-based cultures are worth their weight in gold. Many if not most projects in process-based companies are managed by people who do not see themselves first and foremost as project managers: "I'm an actuary managing this product development and development of the IT system that will support it." Yet these people are expected to perform well as project managers and overcome the cultural project inhibitors that are often a feature of process-based companies - lack of empowerment of the project manager being just one example.

In some companies being assigned to a project is to be cast out into the wilderness - a vote of no-confidence from your manager, a career-limiting move and possibly a prelude to redundancy. And yet those left handling the day to day business see those assigned to a project as being "off on a jolly", escaping the pressures of the real world.

In other companies top management have established a more project-friendly ethos: "Projects determine our future. I want our best people assigned to projects. I want good project work rewarded with promotion. Indeed, henceforth, I will not appoint anyone to a senior management position unless they have managed at least one significant project." We will see how this state of grace might be achieved.

If you ask people what factors cause problems in projects these are the sort of things they will say:

• Undefined scope
• Unclear objectives
• Unclear roles and responsibilities
• Vague requirements
• Lack of leadership from sponsor
• Lack of user involvement
• Inadequate planning
• Scope creep
• Uncontrolled change
• Inadequate monitoring and reporting
• Team know it's impossible but management believe it will be done
• Ignoring reality, wishful thinking
• Inadequate communication

It is surprisingly rare for people to say that IT technology causes project failure or major difficulties. It is usually project management - or a lack of it - that causes the grief.

There was a touching belief a few years ago that if only one could write down every step a project must tread, then project managers could simply follow the process and out the other end would pop a successful project. Huge methodologies were spawned, money was made. But it isn't like that.

If you wanted to become a plumber you'd learn how to use each of the 50 tools in the plumber's toolkit. On your first, simple job you might only use 2 of them, but knowing which 2 and how to use them to best effect is obviously key. On a large plumbing job you might even use half the tools in your toolkit, but you'll never find any job on which you'll need to use every tool in the box.

The same with project managers: it's all about being equipped with tools for managing risks, defining scope, planning and scheduling, resolving conflict, etc and then using these tools appropriately if and when needed. You cannot manage projects by rote.

Privacy Policy and Cookies