Projects as a distinct class of activity

Projects and processes

Everything that people do in an organization can be categorized as either a project or a process. A process is an activity which happens continually or a set of activities which happen continually, that is, they are always happening or being made to happen. For example, payroll activities are a process because they happen every month, or week or fortnight. Merging a business with another is not normally a process, because the activities involved are not always happening in the organization it is a one-off activity, and so by definition is a project^[6].

So that we are quite clear on the difference between a project and a process, consider an oil refinery or a telephone exchange. Running an oil refining plant is a process. Upgrading it or repairing it is a project. Running a telephone exchange is also a process. What about upgrading the telephone exchange to handle broadband? Upgrading the first exchange is a project, but if the telephone company owns a few hundred identical exchanges, and the same team is upgrading them, then after the first few times, upgrading them becomes a process. Telephone exchanges are more numerous and more standardized than oil refineries.

The examples of upgrading oil refineries and telephone exchanges show that the distinction between project and process is not fixed and absolute. There can be activities which have elements of both project and process. The distinction between project and process is useful, however, because it helps us to manage well. Project management is used where there is a high degree of novelty, uncertainty and therefore risk. Process management helps us reduce costs and risks and increase quality where there is a history of having done more or less exactly the same thing before, and where the same thing will be repeated in future. Upgrading Cyclops Oil's one and only refinery is predominantly a project for Cyclops Oil, but it might be predominantly a process for the Millennium Oil Refinery Upgrading Specialists Corporation, which does one a week.

Cyclops Oil and the telephone exchange upgrade also illustrate another strategic importance of projects. Projects are the primary means by which organizations grow and create value, in fact, projects are the only way in which organizations survive. As the world changes, organizations, like individuals, must adapt or die. Companies must create new products and new markets to replace old ones that wither and eventually vanish. (Government sector bodies too must innovate and change or, like Tsarist Russia or the Soviet Union after it, revolution will replace them, ultimately.) Figure 1.1 shows how projects continually provide replacement for the value lost in an organization as its environment and customers change.

Figure 1.1. Growth, or new value creation, in the organization comes only from projects

This diagram shows the role of projects in creating value in the future to replace value that will be lost as the organizations environment changes, through technological advances, changing customer preferences and in the case of the private sector, competition, and in the case of the government sector, changing stakeholder and societal needs. The area above the horizontal axis shows value, that is revenue (or societal value) minus costs, created by doing the things that the organization has done before, plus, in the case of Year 2 and Year 3, new value created by projects. New value can be either reduced costs, or increased revenues (or equivalent for the government sector), because value is revenue minus cost. Projects incur cost now to create value in the future. All value originated, at some point in the past, in a project; projects change or create business-as-usual processes.

Why does the difference between processes and projects matter to you? Why does this distinction between project and process matter? Is it not just theory, irrelevant to getting on with the job? It matters to senior managers and it matters to project managers and others involved in projects for slightly different reasons. For senior managers in an organization, an understanding of the difference between a project and a process will enable them to deploy the best management techniques to each thing that the organization does, and to have a more realistic mental picture of what is likely to happen in each of those things and how they should be guided and directed. For project managers and all those involved in doing project work, understanding this distinction is like knowing where you are on a map: you will have more confidence in when to apply project management techniques and a greater understanding of how what you are doing relates to all the other activities of your organization.

The dividing line between projects and processes (Table 1.1) depends on whether the organization repeats an activity often enough for it to become routine. For example, a large construction company might build a new housing development consisting of hundreds of near-identical houses. Their process of building a house is very well defined, but there may be different drainage or access requirements at different ends of the site so that the construction methods may be slightly different as a result. For this company, house-building is a process that can be repeated with a little adaptation. But if you were to build your own house, then it would almost certainly be a project. You are very unlikely to be as practised at building houses as the company that builds the housing development.

Table 1.1. Features of projects and processes
Project	Process
Novel: has not been done before, not in exactly the same way. May be managed across divisions or directorates. Some key risks involved are not well understood. Value to the organization is by delivering the project on time and on budget.	Repeated continually: has been done before, will be done again. Managed by a single division or department. Most risks involved are well understood. Value to the organization is created by continuous improvement of the process.

One way to interpret Table 1.1 is that we may distinguish between a project and a process according to the degree of execution risk involved. Procedures that get repeated frequently are usually refined through experience to the point where they are unlikely to fail catastrophically. Thousands of cans of beer pass along a canning line every minute and the likelihood that any particular can will be found to be outside its specified limits is very small. Continuous improvement initiatives such as Six Sigma use the continual repetition in processes to create value by making incremental changes to the process to reduce risk, increase quality (fitness for purpose) and reduce costs. But as the novelty of a process increases, so does the risk of not producing the expected result, and with entirely new ventures there are no pre-existing processes that can be refined.

Projects, in their purest form, create entirely new processes. Creating a new process necessarily involves doing new things. Discovering the right way to do them necessarily involves making some mistakes. New combinations of technologies or new markets usually mean that the people who have to do the project have not worked together before and there is no pre-existing organizational framework or protocol to guide their interactions. So before ground-breaking projects can begin to achieve their business objectives they must first create a new organization and this is itself fraught with risks. These activities involve such high risk that trying to manage them within the framework of the firm's usual activities is very likely to lead to disaster. A different management approach is needed for these high-risk activities, and this is why project management is different from day-to-day management. Having defined projects in absolute contrast to processes, we can see that in real life there is a continuum between pure processes and pure projects. Some projects have fewer pre-existing processes in them. Figure 1.2 illustrates the differences between projects and processes and recognizes this continuum. The Cisco example is one of many that illustrates how activities which are part of a project the first time around can become more process-like as they are repeated.

Figure 1.2. Projects and processes

Case study

Acquisition projects at Cisco

The acquisition of another company is a rare event in the life of most organizations. Acquisition clearly changes the organization and requires careful planning and execution. It would be a major project in almost any firm.

Cisco, the Internet equipment supplier, grew from $28 million in revenues to $8.5 billion in only nine years, having deliberately adopted a strategy of growth by acquisition. At one time Cisco was acquiring another firm on average every 16 days! Acquisitions are notoriously difficult to get right, particularly when the most valuable part of the acquired firm is the people. But Cisco's growth plan required lots of acquisitions, and so one of the four main parts of the plan was to 'systematize the acquisition process'. Rather than reinvent the wheel with every acquisition, Cisco had strict procedures that included things such as:

Standard pre-acquisition criteria and due diligence processes.
A strict timetable for getting acquired companies' supply chains integrated into the Cisco system so that cost savings were immediately realized and the greater reach of the Cisco sales network could increase sales of the acquired company's products.
A formal system of 'buddying' new employees with Cisco employees who had similar experience. The Cisco buddy had specific responsibility for making sure that new joiners knew the Cisco procedures.
Structuring the deal to ensure employee retention and to align motivations of new employees with Cisco.
Appointing a respected senior manager from the acquired company to lead the integration process.

These measures had been proven to address many of the common reasons for failure of company mergers. Cisco repeated the acquisition project so many times that it was able to formalize procedures in a way that greatly improved the speed of company integrations and the chances of success. Cisco had taken what would normally be a rare and risky project and turned it into a routine process.

Definitions of project

It is sometimes helpful to have a definition of a key term so that we understand it better. Many organizations have their own definitions of what is a project for their purposes. If you do not already know, you should check whether your organization does. One of the main reasons why projects fail is that they were not identified as being projects and so were not managed as projects. Understanding what projects are and knowing their features and how they differ from processes can help to reduce the amount of waste and risk in your organization. It does not matter whether the word 'project' is used within your organization to describe an activity the argument about whether to call something a project or not is not worth having but what does matter is that project management techniques are applied to projects, whether or not they are called projects.

'A temporary endeavour undertaken to create a unique product, service or result' Project Management Institute.
'A set of coordinated activities, with a specific start and finish, pursuing a specific goal with constraints on time, cost and resources' International Standards Organization (ISO 8402). This definition extends the set of identifiable characteristics of a project to include constraints on time, cost and resources. (Were we to have unlimited time, cost and resources then there would be little need for proper management.)
'A management environment that is created for the purpose of delivering one or more business products according to a specified business case' PRINCE2.
'A unique process, consisting of a set of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective conforming to specific requirements, including constraints of time, cost and resources' BSI^[7].
'An endeavour in which human, material and financial resources are organized in a novel way to deliver a unique scope of work of given specification, often within constraints of cost and time, and to achieve beneficial change defined by quantitative and qualitative objectives' alternative definition, Association of Project Managers^[8]. (The primary APM definition follows the BSI definition.)

Programmes and projects

A programme is a set of related projects, sometimes called a portfolio of projects. The term programme is sometimes used, confusingly, as a synonym for project. Although these two terms are related, they do not mean the same thing. Programme management is different from project management. The project manager is focused on making their project succeed; delivering the project is all, and if the project does not deliver the project then they have failed. A programme manager has more complex and subtle success criteria. Take the hypothetical example of a government programme to manage the consequences of harsh weather, floods, drought, snowstorms and climate change. Within this programme there might be a project to manage flooding and another to manage droughts. Now by logic alone we know that there will not be both floods and drought at the same time. For the programme to succeed it is not necessary that all of its projects succeed, or even happen. Or, to take a commercial example, commercial organizations often have some projects designed to manage a downturn in the economy, and others aimed at exploiting boom periods. These two kinds of projects are not both going to run at the same time, nor are they designed to, but they may be part of the same programme.

So programmes comprise a number of projects. Similarly, projects may comprise a number of sub-projects. What then is the difference between on the one hand programmes and projects, and on the other, projects and sub-projects? To some extent this is a matter of taste and organizational preference. Indeed, there is one investment bank that defines terms such that what it calls a programme is what the rest of the world calls a project, and vice-versa. Generally speaking, sub-projects are categorized as such because they are tightly or closely related to the project, and the success of each and every sub-project is necessary to the success of the project. In the case of programmes and the projects of which the programme is comprised, the programme can succeed without every single project happening or succeeding. In this sense, in contrast to projects and sub-projects, projects are loosely related to the programme. As we have said before, one should not be excessively concerned about how these terms are used and whether your particular organization uses them in a pure way; what matters is that you understand the principles, and you understand how to relate the terms as we will use them in this book to what happens in your organization, so that you can be a better project manager, and your organization can get projects done as well as possible, meaning at the lowest cost and risk, delivering the greatest business benefits.

Identifying projects

There are advantages to identifying projects, whether or not they are so called, in order that they can be properly managed. Projects do not always have a label attached with the words 'This is a project'. That is, the customer service improvement project is not always called 'The customer service improvement project'. It may also be called an initiative, plan, scheme, strategy, measure, proposal, step, action or approach. As we have already seen, there is a continuum between processes and projects. The new 'Zap initiative', which is, let us suppose, the corporate name for the customer service improvement initiative, may include some process elements and some elements of a project. It is your job as the senior manager responsible for this, that is, the sponsor, or as the project manager or a member of the Zap team, to understand what within it is project management, so that you can do the best possible job in making the Zap initiative succeed. The point is that the ability to identify projects as such is a valuable one. And it is not difficult.

So how do you recognize a project when it is not called a project, or how do you check that something called a project is in fact a project? Projects have some or all of the following characteristics:

Projects are the means to bring about change faster than it would happen otherwise; projects accelerate change to beyond the rate at which the organization naturally evolves and changes.
Projects have a definite start and end point. (This contrasts with processes, which continue in a cycle.) Once a project reaches its objective, it finishes.
Projects have high risk. This is a corollary of accelerated change.
Projects are about doing something new. Consequently, projects have to develop new approaches and means of doing things.

Projects come in all sizes and every variety of difficulty. Some can be planned, managed and executed all by the same person working part time. Others require tens of thousands of people working on many sites doing many different things. All of them share some common features and will benefit from some parts of the body of knowledge that has built up around project management in general, but which parts of the body of knowledge should be applied will vary according to the specifics of the project. One of the skills that both organizations and individuals should try to acquire in project management is a sense of judgement of what tools to apply to different kinds of project. Figure 1.3 illustrates some dimensions in which projects can differ, and shows the different risks of failure associated with each.

Figure 1.3. Project difficulty

Top of Page