Why you should manage processes not (just) projects

© Jultud | Dreamstime.com - Steel Spring And Pulley Photo
© Jultud | Dreamstime.com – Steel Spring And Pulley Photo

Project management is a big thing in the corporate and public sector world and there are therefore often high expectations about how projects are delivered. Whether you use PRINCE2, PMBOK or any other project management methodology, a standard exists.

Process management is entirely different – although some tools do exist that can be useful to both disciplines – but is so often overlooked by organisations. However when you consider the amount of time, effort, cost and errors that can be saved by leveraging work that is undertaken on a repeatable basis by capturing and managing these processes, it is surprising that it is so overlooked.

In this post we are just starting to scratch the surface of what the distinction is between projects and processes and why it is so important that processes are managed properly in their own right. I expect that this is a topic I will come back to fairly soon.

We’ll cover this topic today by exploring five questions.

  1. What is the difference between a project and a process?
  2. Can projects become processes?
  3. Can processes become projects?
  4. Can you manage a ‘project’ like a ‘process’? And should you?
  5. Can you manage a ‘process’ like a ‘project’? And should you?

What is the difference between a project and a process?

Let’s first hark back to some general definitions first, to make sure our terminology aligns at least. A process is a series of repeatable steps that should be carried out in order to produce a specific outcome. On the other hand, projects are initiatives that are undertaken once-off only for a single result.

Can projects become processes?

Yes, in three ways.

Process documentation and/or improvement projects, sometimes known as business process reengineering projects, or business reform projects, are once-off initiatives to improve procedures. Therefore the outputs of such projects are procedures, which (in a disciplined organisation) continue to be followed once the project has been wrapped up. The outcome of such projects would be that activities are undertaken in an improved way.

Other projects that result in new activities – whether that be the construction of infrastructure, the development of a new system, or the addition of a new service or product to the organisation’s portfolio – also result in processes.

And finally, new types of projects that haven’t been undertaken by an organisation before can also be a vehicle for the creation of new processes. By taking a single project, reviewing how it was carried out and thinking about how it might be applicable to another similar type of project in the future, you can take out the detail of the project plan and convert it into a more universal process. This means that at the end of the project, not only have you delivered the desired output, you also have a new procedure that can be picked up elsewhere in the organisation and used to guide future work. This is a brilliant way of capturing the organisation’s intellectual property, not making the same mistakes twice and generally getting the most out of projects.

For these reasons, it is important to be aware of this distinction between projects and processes from the beginning of any project, because at some point these projects will cause new processes to be created or existing processes to be modified. It is good for project staff, existing operational staff and other relevant stakeholders to be talking through how the ultimate processes will be documented (often in procedures), communicated and handed over.

Think of it as creating a template for future activities and leveraging your existing experience. I tend to think that when you are producing ANYTHING it is always worth at least thinking about whether it can be done in a way that is more universally useful, rather than just achieving the immediate task at hand. Therefore if you are delivering a project, I suggest you do have a think about how much of those steps can be made more high-level and into a more universally reusable process. Sometimes you do not have the time to spend on doing it, but where you do it can – for similar projects in the future – speed up things, reduce errors, and allow project managers to spend their mental energy on more strategic tasks.

Can processes become projects?

Well yes, but this involves essentially deleveraging your process and tailoring it into something specific. Not that this is always a bad thing.

For a very operational and detailed activity, for example operating a piece of machinery or receiving an application form, it probably is not useful. These activities are likely to happen frequently and need to happen according to the same procedure each time to minimise variability and maximise efficiency.

However, for a more high-level activity which happens less frequently, this might be exactly what is appropriate. Developing a business plan for a division within a department is a good example. In this case, if someone has created a high-level, universal procedure for this, the benefits of leaving it like this are that each division in the department is following the same steps according to the same timeframe in a way that has been tested (and hopefully improved) previously.

But perhaps there are differences between the divisions. The divisions may have different stakeholders to consult with and a different range of issues to address, so therefore need a slightly different approach or timeframe. On the one hand, the more a process has been universalised, the more it should be able to cater for these differences. However, on the other hand, if the division’s director is very keen on planning (which I have no complaints with!) and does want to put in more detail around the process steps, he could either convert it into a more detailed procedure that links with the higher level one, or use the detail in the procedure as a starting point for developing a detailed project plan. But at least there was a starting point in the form of an existing procedure. Talk about efficiency!

Can you manage a ‘project’ like a ‘process’? And should you?

 A common understanding is that a project is a once-off enterprise, whereas a process is repeatable with the outcomes. Really it all comes back to how far you are willing to ‘decustomise’ or universalise the steps undertaken to reach an outcome and make it into a process.

You can make the steps you undertake in a project into a procedure – so that future projects are based on previously trialled steps. This saves you starting from scratch, ensures more rigour in your project management, can be consulted on once – instead for every project – and means that previous iterations can be more easily learnt from. Essentially you can turn projects – or at least aspects of project management into processes. I think this is actually a really good practice.

Does it work the other way?

Can you manage a ‘process’ like a ‘project’? And should you?

You can in the sense that you can specifically tailor things that happen on an ongoing basis to a once-off instance. This might be necessary in an organisation that runs everything as a project with a start and end date and a project plan. But then the next question is, what do you call the start and end date – how do you train the process into something that can be managed as a single project?

You see, in organisations where they try to manage all their activities as projects, you have three options for doing this. Let us use the activity of deciding on the operation of a piece of infrastructure as an example – but let’s keep this as universal as possible and imagine it as a physical or conceptual piece of infrastructure – which controls how much of a specific substance (people, services or a resource) is used. So how do you document this as a project so that stakeholders know how this decision-making activity occurs (including who is involved in making the decision, timeframes, evidence base and how learning from previous decisions are being learnt from)? Here are the options coming right up…

  1. You document a whole new project plan each time you have to make the decision. Ok, that’s possible, but what if you are making the decision on a daily basis and/or only have an hour between knowing that conditions have changed and needing to do something about it. This would be not a particularly efficient way of making the decision you need.
  2. You document a whole new project plan on a regular basis that must be referred to each time the decision needs to be made.  By ‘regular basis’ I mean whatever period is useful for the organisation – probably every six or twelve months. This is much more doable, but that is potentially still a lot of work each planning period, and of course it does not necessarily incorporate learnings and successes from the last period because it is not based on the previous plan. It also gets tricky though when you think about how a project schedule is relatively linear and does not generally support repetitive loops. You also are unlikely to know how many times these decisions are going to need to be made, or when – they are based on conditional triggers being met, not certain dates being reached. Therefore the inevitable inaccuracy of your project schedule and the inefficiencies of taking this approach make this less than ideal.
  3. You use the previous project plan and revise it on an each time basis. Well this starts to be a more smart way of operating. Your project plan will include the steps that need to occur to make it more transparent and instead of starting from scratch you are essentially reviewing what happened last time and hopefully improving it along the way. However I still have concerns that (amongst other things) you are going to have issues with getting your ‘project’s’ Steering Committee to endorse the project plan in a timely enough fashion for it to be useful and you are going to drown in paperwork. After all, not only might you need to create a new project plan dozens of times in a year, it is likely that the business area that manages this activities also leads a number of other activities which will all need their own project plans.
  4. You use the previous project plan and revise it on a regular (let’s say annual) basis. Another marginally better way of doing things, which includes the benefits identified in option 3 – as well as the shortfalls identified in option 2.
  5. You don’t go down to this level of detail at all and instead write a whole new project plan for how a group of related activities (eg activities that a specific business team undertakes) on a regular (let’s say annual again) basis. However if these activities involve a lot of stakeholders, critical timeframes and technical information, and if these activities are central to how the organisation provides value to its customers, this is extremely risky. I know if I was on the board of a company that did not have information about how core business activities occurred, I would be demanding this information to meet my legal obligations. In the same way, if I was part of the Executive of a government department, I would be demanding this information in order to ensure appropriate accountability to the Minister. I suppose this kind of project management could be appropriate if the project plan was able to reference formal procedures for the relevant business activities – but this again brings you back to managing activities through procedures in some form at least. Just not purely through project management.

So to be completely honest, my opinion is that you cannot manage a process purely through project management. You can apply tools that are often used in project management to process management – for example tools used for risk management, resource planning and budget planning – and if you are serious about good management, why wouldn’t you? But at the end of the day, to put rigour around how an organisational unit operates, you still do need a documented set of processes (probably in the form of endorsed procedures, depending on the appropriate level of rigour required) that can be used on an ongoing basis and, if necessary, referenced by a business plan or a project plan.

But I am very interested to hear what you think.

Do you think processes should be managed like a project? And what do you think process management should entail?

One thought on “Why you should manage processes not (just) projects

What do you think?