Abstract
Process and project are two different and complementary work management models: While the project is temporary and unique, the process is continuous and sustains the business permanently. Both of them involve planning, executing, monitoring, both of them involve human resources and performance measurement.
The aim of this work is to show a way to combine the two models in a helpful way, in order to obtain a better and more powerful work modelling and resources optimization.
Each enterprise must define its own criteria to establish the borderline between the two models (what is a project? and what is a process?), and find out how to interact with each other. In particular, after emphasizing the differences between them and developing a deeper understanding of how they can conflict inside the performing organization, it is shown how the project approach can help the process and vice versa.
Finally a short look is given to how Information Systems can reflect this cooperation and help to integrate processes and projects.
Introduction
“You own the two indispensable gifts that, being antithetic, it is unlikely to find together in the same human being: the fantasy required for invention and the practical sense to know what can work and what cannot: delirium and pragmatism, craziness and calculus” (Cesar Aira, Il Mago).
Our personal history as individuals has been full of upsetting questions, such as, “Which one do you like most, the sea or the mountains”? “Who do you love most, mummy or dad?” “Who’s your favorite composer, Bach or Mozart?” Most times such alternatives require a strongly traumatic choice: black or white, up or down. In organizational models, sometimes we come to a similar disappointing situation when dealing with processes and projects. Everything seems to bring us to select one field against the other, just like a football team.
Projects are innovation and changing drivers, processes are the substance of the ongoing business; sometimes it is easier to recognize the “value” added by the process, while it is a little bit more difficult to recognize the value of the “cost” of a project. Processes are strictly connected with business success: all of the excellence models (like ISO 900x standards, WCM, EFQM models) teach us how to design, structure, synchronize, optimize, and measure the process. The lean approach helps us to eliminate any non-useful operation in order to have efficient processes and increase added value. On the other hand, projects always need to demonstrate their reasons and opportunity. Why should I change? Why should I reach a new point? Why couldn’t we just maintain the status quo? What’s the ROI of this project?
The most popular and well-known type of relationship between projects and process is the “launch”: a project is planned and executed to create a process. For instance, to implement a new information system, to obtain a certification, to open a restaurant, to carry out a lean production process reengineering: at the end of the project a new or revised process is launched and survives.
In the following, we will explore other ways to combine these two work models, with a higher degree of cooperation and combination: This could bring our companies to a balanced organizational architecture.
Work Management Models
Two far galaxies
Here we introduce the two main protagonists of the integration, a true organizational challenge: process and project.
The idea of project (etymology: from the Latin word pro-iacere to throw ahead, forward) brings us to something dealing with the change, the journey, the reaching of a new point in space and time. Today I am here, tomorrow I’ll be there. It is a concept that accompanies all of human history in every field; each and every man or organization has the necessity to carry out projects in order to solve problems, to bring an evolution process or a change request to a successful completion, to develop something new. In a few words, to manage a project means to organize resources to meet an objective, respecting a set of given constraints. One of the most pregnant definitions of the project is “the art of getting things done.” The project is strictly related to innovation, either radical or incremental.
The mission of the project is to reach the goal and stop.
The idea of process is a basic and common concept in every scientific discipline and it has become part of the most recent organizational models and excellence models; process is sometimes referred to as operations, or workflow: it means work that flows from one step to another, from a competent to another one, following a stated procedure. Procuring materials, selling products, maintaining machines, assembling components, and resolving a customer claim are all examples of typical manufacturing processes. The process, as a cyclic reiteration of the same steps following specific rules, is strictly related to life (think in terms of the vital processes in the human body, such as breath, blood circulation, digestion, etc.)
The mission of the process is to sustain the business in a continuative manner.
Projects and processes are antithetic but strictly connected and they interact with each other: typically a project is set in order to create a new process or to improve or repair the behavior of an existing process. But at a first glance they appear as two quite far galaxies (Exhibit 1).
Exhibit 1: Project and process, two far galaxies.
News from the Project Galaxy
The project is the universe of uniqueness and temporariness. According to the definition in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Fourth Edition: “A project is a temporary endeavor undertaken to obtain a unique product, service or result” (PMI, 2008, p. 5). Here the main properties of a project include:
- Activity (or Tasks) - A set of elementary operations or work components inside the project that are the result of the decomposition of the whole project scope
- Requirements – Objectives, goals, customers' expectations, and characteristics of the product produced by the project
- Product - Products, services or results coming out from the project, typically oriented and delivered to a customer (internal or external)
- Resources - People and materials that take part in the project activities
- Constraints – Fixed points, coming from outside the project, that must be respected (a fixed budget, a time deadline to meet, a particular technology to be used …)
- Customer – Who receives and uses the products of the project.
- Sponsor – Who procure the project funding.
- Stakeholders – Any people and/or organizations whose interest is impacted by the project execution or the project completion.
The project is usually managed through a set of project management processes, grouped into five logical groups: Initiating, Planning, Executing, Monitoring and Control, Closing. These processes represent for the project manager and the project team specific tools to address specific project issues, belonging to a wide spectrum of areas, called Knowledge Areas, such as scope, time, cost, quality, human resources, communication, risk, procurement, and ethics.
The project is assigned to a project manager and managed by a project management team, referring both to the customer and the sponsor. The project management team monitors and controls project performance through scope, time, and cost verification using performance reporting.
The project is usually graphically represented using a network diagram, showing task dependencies, or a Gantt chart, emphasizing time scheduling. No branches or loops are admitted by such a representation: branches and loops, of course present in real life activities, are hidden inside the task (black box model).
News from the Process Galaxy
We can find in the management literature many definitions of business process, in the sense of ongoing operations: Most of them share a common set of characteristics. A business process is determined by:
- Activity (or Tasks) - A set of elementary operations inside the process that transform physical objects and/or information; calculations, decisions taken by people competent and granted to do it. Activities have a duration and can be manual (performed by human resources) or automatic (performed by machines).
- Input - Materials and information coming into the process from outside; they are typically outputs from other processes.
- Output - Products, services, or results coming out from the process, typically oriented and delivered to a customer (internal or external).
- Resources - People and materials that take part to the process activities.
- Methodologies - Set of rules that must be followed in order to achieve process objectives; they contain the organization's know-how, the functional behavior, the identity, and finally the specific company way to face the market or the environment.
- Customer – Who receives and uses the products of the process.
In addition, processes have the following properties:
- Definability – Each process must have precise boundaries and defined inputs and outputs.
- Order – Activities must be coordinated and follow a definite sequence in time and space.
- Value adding – The transformations inside the process must create value.
- Incorporation – Every process is not stand-alone but it is connected with other processes and is embedded in a whole system.
- Cross-functionality – The process is not bound inside a single organizational unit, it does not fit the functional hierarchy, but it runs across many different units.
The organization must be considered a system; this systemic approach tells us that processes are never alone or autonomous inside the system: processes are always interconnected with each other. The responsibility of the process is typically assigned to a process owner; process performances are measured using defined key performance indicators.
The project is usually graphically represented using a flow chart, in which branches or loops are admitted: a single task may be iterated many times and it is not possible to foresee a priori exactly the type and quantity of tasks that will be performed, depending on the events that will happen and the logical conditions that will be found true.
Project Against Process
We would like now to emphasize the difference between the two work management models, exploring some peculiar dimensions. In Exhibit 2, a comparison is shown of the main aspects of the two models.
Communication
Communicating in a project environment is a continuous search for the best way to share information among the project stakeholders, who normally speak different languages and come from different backgrounds. A project glossary must be established and maintained during all of the project phases. In the project environment, stakeholders and team members are usually put together for the first time and it’s a specific concern of the project manager to take care of communication problems and work on misunderstanding. In other terms, data must be always sent together with their metadata in order to help interpretation. In critical projects, the tools and techniques referred to as co-location are used to maximize and speed up the comprehension between members and the raising of a common project lexicon.
In the process environment, things are different: the communications follow patterns and templates that are well-known by the actors of the process. Each process instance is similar to the other ones of the same process, and communicating is not each time something new. Procedures are written in order to explain how to work; the language is application area-specific and makes a wide use of understatements and technical slangs. A glossary is not needed for each process instance, but is part of the whole process description. Typically, it is enough to transmit data, because the metadata are already held and shared by the process activity performers.
Exhibit 2: Project vs. process.
Times and durations
Time perception and time management inside the two models are quite different.
- Project time is definite — a long or short period — but with time constraints; each project has a definite beginning and a definite ending, its best geometric and suggestive representation is a segment. Durations are proportional to the length of the segments that represent activities.
- Process time is a never-ending cyclic moving; the process itself is indefinite, the time is “open.” Each process instance has a definite beginning and a definite ending.
Throughout the project planning phase, after a complete and careful definition and decomposition of the project scope (what’s in, what’s out definition), the duration of each task is determined and also the whole project duration is calculated. An iterative process is then performed in order to obtain a final schedule, where all of the constraints and the limitations due to resource availability are considered and tasks are accepted in people’s timetables. During the execution phase of a project, each stakeholder has a different perception of how time flows in the project: Time is not absolute, it is not measured by the clock, but it is a subjective psychological internal feeling of time flow (see Exhibit 3).
Exhibit 3 – Time perception in projects.
The way of feeling and managing time dimension in the process context may have a very wide spectrum of possibilities, depending on the predictability of the process: A productive manufacturing process is usually well-known and schedulable with a high precision, while the solution of a problem or the answer to a customer complaint is something with a higher degree of uncertainty (something is known, i.e., the amount of time needed to register the complaint; something is unknown, i.e., the amount of time needed to find the root cause of the problem). With a project, we know that all the work shown in the Gantt chart has to be performed, whereas with a process, the presence of branches and loops makes the whole duration of a process instance life cycle not exactly predictable but only probabilistically.
The time in the process is often more a collection of events than of durations (points more than segments). Many graphical representations of a process show the process steps from left to right (see Exhibit 3), as in the mathematics or physics time axis representation, but there is no proportion between the length of a given path and time duration.
Exhibit 4: Example of process flow.
Ownership (Who Cares?)
Both project and process involve responsibility and competence, both models have to distinguish commitment from involvement of human resources. “When it comes to ham and eggs, pig is committed, chicken is involved”: in the project, the project manager is committed, while the team members and the stakeholders are involved. In the process, there are two key roles that can be identified:
- The process owner: the individual(s) responsible for process design and performance. The process owner is accountable for sustaining the business and identifying future improvement opportunities on the process.
- The process operator: the individual(s) responsible for actually executing the process activities.
The process owner establishes process performance metrics to measure the process’s capability to meet the product specifications and process objectives. These set of metrics are called key performance indicators (KPIs).
Talents and Skills
Both project and process involve people’s work. A common element in the two models is the activity, or task, as an atomic element of work. People perform work because they have competencies and skills. The skill mapping may be performed both in the project resource pool or in process workflow definition and role assignment (it is important not to have two separate and autonomous mappings!). Each activity belongs to a type-of-activity, whose execution requires a certain level of a certain set of skills; from the other side, people own skills, at a certain degree. By doing this, the enterprise can perform a gap analysis in order to show what the degree of covering and overlapping between skill requirements and skills owned by resources, with a single integrate mapping for both projects and processes.
Deviation from the Baseline
Both project and process have to face uncertainty and unplanned events—that is, points that place themselves far from the defined baseline. In the project context, the variance between work results (what happened) and project baseline (what should have happened) may bring to corrective actions and/or re-baselining. In the process context, exceptions and errors must be immediately corrected (run-time) — specific exits or reaction plans must be foreseen in the procedure that rules the process — but also, in a midterm perspective, lead to a continuous redesign and improvement of the process (build-time).
Functional? No, thanks!
Both projects and processes are not good friends of the classical hierarchical functional organization. Process and project are cross-functional and spread across the whole organizational hierarchy. Depending on the dignity of the project inside the functional hierarchy, the organizations are classified into:
- Functional
- Matrix (weak, balanced, strong)
- Project-oriented
Exhibit 5: Process across departments (from: ISO/TC176/SC 2/N 544R3).
Human resources and organizational interfaces should be carefully considered in both contexts, to prevent conflicts and help solve the typical “double boss” problem. Each person inside the performing organization has “the right” to have one and only one boss, but his or her boss has the responsibility to help him or her to participate in the processes and the projects with the minimum amount of stress and conflicts. A clear definition of the roles is an indispensable prerequisite to mitigate these kinds of risks.
A Possible Cooperation
After underlining the differences between the two models and emphasized the conflict between them, let’s try to understand the better way to make them cooperate.
How the Project can help the Process
The project model can be very usefully applied in a process context:
Often there is a high degree of uncertainty that we cannot map in the process flow: In a problem-solving process, for example, after determining the root cause, many actions should be undertaken, and they can be conveniently planned and executed in an extemporary way, just as if they were a dynamically defined project.
Exhibit 5: The project helps the process.
- A single step in the flow may be expanded as a set of scheduled tasks.
- A worklist (a list of process instances to be carried out) can be transformed in a Gantt chart (with automatic calculation of the durations, depending on instance properties).
How the Process Can Help the Project
The process model can be very useful for the project management purpose:
- The PMBOK® Guide itself describes a set of project management processes.
- Each project flows, from its beginning to its conclusion, following a sequence of step, phase, gates, ruled by the so-called project life cycle, that is in fact a process.
- Each project activity may be described as and expanded in a process: observing the behavior of such a process with the Business Activity Monitoring tools is possible to have better and more documented estimations for the duration of the task at the project level (see Exhibit 6)‥
- A process model is perfect to describe the pre-historyl unscheduled phase of a project (e.g., feasibility study, business case development) as well as the change request management process, during project execution or after project closure and product delivery.
Exhibit 6: The process helps the project.
Project and Process Integration
The integration should start determining which one is the primary context (whether process or project), then the combination of the models may proceed nesting on many levels, following a sort of matrioscka iteration model; the number of nesting levels is limited only by practice and manageability considerations. Project and process integration (PPI) is a formal approach, with the specific goal of finding the best way to combine the two work management models to obtain a better management of work distribution and monitoring and resource allocation.
The Role of Information System
In a PPI project, the ICT leverage plays a fundamental role, as in every business process reengineering project. In other words, we can say that the role of the ICT system is to make process and project models available inside the platform at different levels. The basic “bricks” of such a building are activities; it is also a good idea to connect to each activity the definition of the required skills, coded and described in a single integrated catalogue.
This approach can grow up to the level of a true conceptual revolution, from a transaction-oriented system to a process aware system. Process awareness can be obtained adopting a third-party BPM suite or encapsulating workflow engines in the applications.
Conclusion
Project is a route, whereas process is a routine; they are different, but they operate cooperatively.
This quick tour wants to underline the wide possibilities to promote a new way of thinking of projects and operations in enterprise, to obtain significant improvements and business advantages.
Don’t forget: a Process and Project Integration project … is a project itself! So you cannot choose in this case the primary context — but with certainty you can successfully apply all of your project experience.
