Projects and processes, what is the difference? First of all, it is crucial to understand that both process management and project management are not pure vertical disciplines. Some managerial competencies are very specific to given organizational roles. For example, marketing competencies are crucial for people working in marketing departments, but they might be less useful for people working in accounting. Project and Process management competencies, instead, are horizontal and general-purpose. Managers are required to organize their resources to get the work done, and this is true in any function you work. A manager must start from the output, define the needed activities, allocate them to different resources, and finally recombine their outputs into a final result. There are only two possible ways to perform the coordination of these activities, namely processes and projects. Each manager should master both process and project management as these competencies serve two very different scopes. Processes are useful for doing better what we already do. Projects are needed to introduce new results, outputs or even processes. Think about a restaurant, for example. All the activities needed to cook and serve the meals are repetitive processes done thousands of times and continuously improved. Instead, the introduction of a new recipe requires to do something new: it requires a project. Projects are the art of mastering innovation and change. In many cases, as for restaurants, banks, car manufacturers, or education providers, this output will become standard since then. Thus, it will become a process to be delivered and improved. In other cases, instead, the output of the project is unique and not repeated anymore. We call them one-of-a-kind projects, like the Golden Gate Bridge or the Burj al Arab skyscraper. Let's try to understand the relationship between processes and projects by looking at two examples. On the one side, we consider a total standardized output, like a car produced on an automated assembly line. On the other side, we consider a unique output that has never been released before by us or by anybody in humankind's history, like... the teleport. In both cases (the motor vehicle and the teleport), we have an output to deliver. To deliver that output, some activities need to be performed. Finally, different typologies of resources like human, financial, or material ones, are required to perform those activities, requiring time and an organizational effort. So, what is the big difference between a standard and repetitive activity that we usually call process and a completely new one that we usually call project? The main difference lies in the nature of the output. In the case of a project, the outcome is not routinary and standard: it is unique. Besides that, there is no difference between processes and projects. Projects are processes indeed, but processes that have never been done before. Processes that cannot rely on past experience and, above all, processes that will be performed only once. From the managerial point of view, this single difference increases the level of complexity dramatically. Think about the learning curve effect, for example. According to this curve, when we run a process repetitively, we increase our performances as we correct mistakes and acquire mastery about it. We know that every process will be improved, and we have space for some errors at the beginning. Projects, instead, are performed only once. They are unprecedented processes releasing unique outputs. We never did them before and never will again. We need to perform well at the first and only attempt. We can now imagine that the space between repetitive activities (for example, the assembly line) and unique activities (for example, the teleport) as a continuum. Most probably, if we look at our own activities, we find that most of us do not carry out completely repetitive activities at work. Still, we don't even face the complexities of developing a teleport every single working day. Most likely, our activities are variegated, laying in between these two extremes. In some cases, our activities are very similar to others carried out by us, or our organization in the past. In other cases, we probably carry out activities that are significantly different from any other performed in the past. Thus, our daily job can potentially be located in different points of the continuum, and, based on the positioning, we will have to adapt our management style. The idea is simple: the more we move away from the pure processes, the more we will have to introduce new tools, new techniques, new approaches that allow us to face the uniqueness of the project. For example, we will have to start by understanding which activities must be carried out (in the case of processes, they are already defined since we did them already); what are the durations (in the case of processes, they are standard), and what resources we need (in the case of processes, we already have them). In other words, the more our outputs become unique, the more we will have to apply planning and controlling tools, which are mostly useless in the case of routine activities. Still, the extent to which we need to use these techniques depends on our managerial sensibility. If I am managing the project for a new space shuttle or the organization of a small birthday party for my seven-year-old daughter, I will have to define the activities to be performed using the WBS tool. Nevertheless, I will not use it with the same intensity and degree of detail, as the two activities lie in different portions of the project-process continuum.
