Towards a Project-Centric World
by Mike Harding Roberts

Strategic IT

As organisations become ever more dependent upon IT systems to transact their business, projects become far too important to leave to IT. Mike Harding Roberts considers what "process-based" organisations such as banks and insurance companies can do to become more engaged in managing the projects that shape their future.

"There's no such thing as an IT project." So said my boss many years ago. "There are only business projects, some of which involve IT, some of which don't." Projects developing systems that will run an organisation's business are clearly critical to the organisation's success, even survival. Yet some organisations leave the management of these projects to their IT department and they, the users, get involved (sometimes reluctantly) when IT asks them to (which is usually at short notice). How often has one heard "the project failed because the users weren't properly involved"?

In process-based organisations, banks and insurance companies for example, most work is triggered by external stimuli. Someone walks in to cash a cheque, someone rings up to insure their car. The resulting task is relatively short, virtually identical to many other tasks, and is executed independently of other tasks. Managers who grow up in these organisations develop a management style appropriate to this reactive, immediate world. Basically: just do it.

Projects

People who grow up in project-based organisations have a different work experience. From the age of sixteen when they joined, say, as a bricklayer they were working to a project plan. The customer does not ring up and say "Now lay brick no. 357." No, the project plan determines when each task will be done. Tasks can be long and complex, may have unique features, and are most certainly related to other tasks. People who run these organisations know all about planning. For them the goal isn't so much to answer the phone within three rings, but to achieve the project goal three years away. At the extremes these are two very different styles of management.

The trouble is, when you come to do projects in inherently process-based organisations there is a real opportunity for culture clash. People may observe the resulting friction but not realise its underlying cultural cause. Asking a senior business manager for two of his best people full time for a month to define requirements in a project that will deliver in twelve months' time can provoke the reaction: "you must be joking, we've got a business to run here. I can't have two people taken off their proper job for this project thing - come back in eleven month's time, maybe I'll know then what I want." People who have never been involved in a project sometimes don't believe that it is necessary for their people to be involved so far in advance of implementation. In the process world you make a decision and tomorrow you're doing it that way. The idea that you must decide things in detail a year in advance just does not ring true. Beside, his boss has given him no headcount for extraneous activities like projects.

IT people will tell you that the three things most likely to make projects succeed are planning, planing and more planning. Whereas business people might tell you that they don't see the need for all that planning - they in the business just get on with the work and do it. And they may even see planning as an irritating, initial delaying tactic used by IT people to avoid ever doing any real work.

So, how do we overcome these cultural challenges? Well, enlightenment is the first step. People who run businesses are bright people - when it is explained to them what projects are all about and why they are different, they quickly get the message. But all too often nobody has taken the trouble to explain what a project sponsor should do, what the systems development process actually is, why and when the users should be involved and so on.

Challenges and Changes

After enlightenment comes action - a shift towards a more project-based culture.

We've all bought something via the internet. Some transactions, like holiday insurance, are now completed with no human intervention. Computers increasingly perform the day to day business processes and consequently business people are less and less involved in performing the operational tasks. What are they increasingly doing? Changing the business: new products, new processes, new ways to market. And how do organisations effect change? Projects. Projects are the way change is effected.

In the past a business manager might have managed a number of people all of whom were performing essentially the same operational task. Now and increasingly, some of the manager's people will be performing operational tasks but others will be involved in projects - and some doing both concurrently. Those involved in projects are not working for their boss, they are working for a project manager. The role of the business manager changes: they not only manage day to day operations but also provide career management for those people rented out full time or part time to project managers. Servicing the immediate needs of the business and providing people for projects naturally conflict. The business manager has a more challenging management job. And they may also be thrust into projects themselves, even into a project management role, with no previous project experience. Not only are they expected to swim, they are also expected to show others how to swim! You're a manager - manage this project...

In the past a company would have had a deep, static management hierarchy designed principally to manage the operational work being done by large numbers of people at the bottom. There were clear functional chains of command - you had a boss for whom you worked. The need now is more for resource pools: a pool of financial skill, of engineering skill, of legal skill, etc. The people are available to do projects. In the extreme case if there are no projects they have nothing to do. The company hierarchy does not manage any work, it manages the people. One-off project hierarchies manage the work. The day Joe joins the organisation his boss says: "Welcome. For the next three months you'll be working on project X working not for me but for the project manager." And when that project finishes Joe is assigned to another project working for another project manager. In the extreme case you spend your whole career never doing any work for your boss. (People say this sometimes happens anyway...!)

Every year Joe's boss gives him his appraisal based, of course, on the input from project managers and others. A familiar concept in project-based organisations, but a culture change for hitherto process-based organisations. If business people do not see working on a project as part of their "proper job" it is hard to get their commitment. If Joe knows his next appraisal partly depends upon feedback from the project manager he has an incentive to do the project work as well as he would his operational work.

Project Culture

Business managers' headcounts must reflect both their operational workload and resources they will supply to projects. This means an organisation-wide project resource planning process that determines how much resource from each business area each project will need. This is an important planning role to be overseen by a business executive. There is a clear distinction between the resources needed to keep the business running and those the organisation chooses to invest in projects which will yield future benefits. Many individuals will be split between these two activities.

Project sponsors must become accountable for projects, including "IT" projects - they must be more than just a name on a piece of paper. If the project fails, the Board holds the project sponsor accountable. The sponsor can't just blame IT. In this regime, sponsors become much more interested in their projects and who is managing them: the sponsor's fate is partly in the hands of the project manager. The sponsor will do what he can to help the project succeed.

If project management is viewed as an IT discipline it is difficult to get the business fully engaged in it. Most IT organisations have project management standards. However these are often integrated with technical IT standards, voluminous and perceived as unnecessarily bureaucratic. Experienced IT hands don't need to read them. Novice IT people may not understand them even if they did read them. Business people are often unaware of them or see them as relating only to IT people.

Project management rules and guidelines must become the property of the business, not the property of IT. The project management rules would be, say, a ten page booklet (not the 17 volume methodology so beloved by some IT shops) laying down the minimum mandatory things that must be adhered to on every project. The rules do not include IT technical standards and should be written in business-friendly language - a simple common sense "Highway Code" governing all projects. Separate project management guidelines may offer advice, checklists, useful forms, etc.

The business, not IT, has a (small) project assurance function which: ensures project management rules are followed; helps project managers adopt best practice; and conducts in-depth health checks of key projects on behalf of the project sponsors. (Project managers never lie about project status, but they have been known to forget to mention certain things, which can inadvertently leave the wrong impression in the mind of the sponsor... If they know an independent review is coming in a couple of months they are more likely to report warts and all today.)

Business Leadership

Who are the project managers? In the past they would have been IT people. Increasingly business people manage "IT" projects. The business may even have a pool of people whose profession is now project manager. They may well be certificated, for example by the Project Management Institute. They will be called upon to manage the organisation's major projects, particularly systems development projects.

All business people who become involved in projects (not just the project managers) receive project management education. However, invite a senior manager to a project management course and he will see the words "management course" and conclude he does not need another one of them! The idea that project management is an additional set of management techniques has to be sold.

The education is not how to use a PC based planning tool or how to do PERT network analysis. It is not training in the bureaucratic impositions of a complex methodology. It is not training in how to pass a project management examination. It is training in how projects are run. It includes an insight into the black art of software development - though the education reveals it isn't such a black art after all, and that business people are quite capable of taking a leadership role in it.

The business, including the HR department, understand that when an individual is managing a project they can have the title "project manager" even though they are not a manager in the organisation. Similarly the title "project director" can be given to an individual who is not a Director.

Business people understand that when they are assigned to work on a project, full time or part time, they are working for the project manager even if the project manager has a lower job grade than them. The project hierarchy takes precedence over company hierarchies and seniorities.

Competitive Advantage

A senior user once said a project is like a train: you start it off then it goes into a long tunnel and emerges as a quite different train neither where nor when you expected. In his company IT were the train drivers. The project manager, from the business, must have weekly updates of status and the sponsor a monthly report of status and outlook to completion. At major checkpoints the sponsor should be obliged to authorise continuation, in writing, based upon an updated cost/benefit case: is the project still worth doing?

Business people must see projects as being a part of their job, indeed an interesting and rewarding part. They understand that projects build the future. They want to be part of that. Senior managers reward project performance at least as much as performance in running day to day activities. Eventually business people find it incredible that anyone would propose they should not be managing and taking leading roles in projects, and find it hard to believe it was ever so!

Many organisations now have a full project management capability - they can comfortably work in project mode when the need arises. Others are in transition. Others do not realise there is a transition to be made.

Whilst running the business operations remains the key focus, senior managers in project-capable organisations have the ability to manage projects as efficiently and effectively as they do the business operations. They know that new products are born out of projects and that running these projects well means getting good quality products to market sooner. They know that an effective project management capability confers competitive advantage.