Why your project is really a process (and why you should care)
Many companies invest a lot of resources into managing their projects while ignoring their processes. What if most of those projects are in fact processes? This article looks at the benefit of turning projects into processes.
I have talked with a lot of experienced managers who mix up projects and processes. A Project is often considered to be a structure for getting work done. Whereas a process is often seen as a necessary evil to comply with regulations or manage high volume, repetitive work. This is wrong and it results in a failure to learn and ultimately to scale your company. Here’s why:
Project Definition”A project is a temporary activity designed to produce a unique product, service or result.” This is the definition of a project from the Project Management Body of Knowledge (PMBOK).
It means that a project’s purpose is to produce something that the company hasn’t produced before. With this definition then most projects are in fact processes. For instance, product development is a process. Yes, it results in new products but unless the company establishes a new company and produces a radical innovation then it is an activity that will be repeated. The same with strategy. If a company only produces one strategy every few years then it’s a project. If strategy development and execution is ongoing then it’s a process.
“A process is a chain of activities, each contributing to the overall outcome.”
Is this just semantics? No. If 80% of your company’s activities are organised as projects and the number of real projects that fit the definition is 30%, then you’re potentially reinventing the wheel in the 50% of work that should be organised as processes.
Here are some of the processes that I have seen organised as projects:
– Onboard a new customer
– Manage customer segmentation
– Optimise the company website
– Assess customer profitability
What’s the problem?
By organising the activities as projects the company will staff differently each time and each new team would then find their own ways of doing it. They may also bring in consultants to do it. This way there is no learning from case to case.
There’s no performance history. They are reinventing the wheel.
What’s the benefit of treating more “projects” as processes?
The company that treats activities as processes benefits in a number of ways. First, they get an acknowledgement the activity will happen again and that it is part of what the company does. Now, if it is a core activity, they may want to make it part of their operations or outsource it to a long-term, strategic partner if it is non-core. In any case, they will assign a process owner who oversees continuity and learning from case to case. The project plan becomes the process map, deliverables become templates and the 10-20% project management overhead to do it once is suddenly distributed among more cases. Employees are more motivated to observe, document and learn since they know they will have to repeat this sometime in the future.
Which projects are in fact processes?
How many times does an activity have to be repeated before it’s treated as a process (and not a project)? That depends on the overhead you have in setting up a process. The more complex your process excellence set up is the more repetitions you will need before it will have a positive return.
My own rule of thumb is that if the same activity has been repeated three times within a year or two then I will start treating it as a process by the fourth time. Why four times? The first time a chain of activities is executed then it’s clearly a project or ad hoc (unless I know that it will be repeated). The second time I may copy the project chart, adjust and repeat the first project. The third time then I will start seeing the common denominators among the three cases. Then the fourth time I will ensure the activity is executed as a simple process that consists of the activities that were common for all cases.
When it comes to staffing, the first two or three cases can be led by project managers, but cases three and four should be lead by the people who have the formal roles and responsibilities to assume process ownership.
To conclude, it’s advantageous to introduce a more rigorous project definition in your company. Then treat more of your current projects as processes and you will see learning and reuse of work products increase. Your key people can be reserved for the real projects and new, specialised people can take the roles that are needed to execute your new processes. This process will gradually open your project “black boxes” and make them more manageable and easier to delegate or outsource.
Map a project as a process!
Why not try to map a project that your company has been repeating as a process. Here is a guide to simple process mapping that can help you.