Why Processes need Projects and Projects need Processes

In a recent post, and some back and forth with The Process Ninja, we discussed the Good and Bad of Process Projects; this led me to think about my days learning about process and projects, both of which I am quite passionate about.

Whether you call it a project or not, the only way to make a significant change in an organisation is through a project, as defined “A temporary endeavour … undertaken to meet unique goals and objectives”; however I believe a project is not where a Business Process is made!

How are Business Processes conceived and enacted?

Business Processes have existed in organisations forever, and they will exist regardless of any specific Process Management activities. A Process Management initiative is about improving the way a Business Process is defined, resourced and operated. Therefore, a process project is really about creating capabilities to support the Business Process, not the process itself!

A common theme across my favourite BPM methodologies (Process Renewal Group and BPTrends) is that;

First the organisation understands it’s processes at the enterprise level;
Then, governance at the enterprise level decides to improve a particular process;
A process project is born.

Contrast this to a more traditional approach, where a project is created to improve an area of the business and one of the many outputs of the project is to model the related processes!

So what’s the difference? Firstly, improving the Business Process is why a project exists – so doing process analysis and design is fundamental – not just another output, then once the to-be future process is well understood, then the project is about building capability. This is why a project is necessary – we are changing the organisation to be able to enact the new process!

Roger Burlton defined six areas of capability that projects build to support processes, they are;

  1. Human Competency
  2. Business Rules
  3. Organisation
  4. Facilities
  5. Technology
  6. Motivation

The outputs of the project are to build the required capabilities to support the business process, e.g. The required people skills, decision model, organisational structure, capital equipment, computer systems and reward structures that match the requirements of the business process.

This leads me to a key point; A project does not implement a Business Process; instead the organisation uses the outputs of the project to execute the process the way it has been designed!

  • Projects are created to improve a Business Process (or part of one).
  • Project OUTPUTS are the capabilities that support Business Processes.
  • Improved Business Processes are OUTCOMES of Projects.

What does BPM mean .. in reality?

When I use the word PROCESS in a meeting or presentation; is everyone thinking the same thing? Even when I had just put a definition up on the wall only minutes earlier?

The answer to that question is probably: “No, of course everyone has interpreted it differently!”

This is an on-going challenge for anyone involved in organisational change, and a key source of resistance and conflict. I think BPM is the toughest type of organisational change as it crosses all areas of the business, introduces a new way to manage what we do and a new way of thinking.

Even on this website, I will use terminology in a different way to my peers, and it will cause comment and conflict! To help you out I have added a new page to the Executive Guide to BPM that provides a Glossary of BPM Terms in the way that I use them. The glossary will never be finished, I will continually add to it. I hope it helps.

What process terms are causing conflict?

One term that I have problems with is SERVICE, or BUSINESS SERVICES. What is a service? How does it relate to processes, work practices and IT systems?

A related question was asked on the BPM-Collaboration website, “What is the difference between a process and a service?”. This generated an interesting discussion (registration to the website is required to access).

I see a business service as a discrete function that is provided to abstract over a sub-process or software solution, e.g. Create a New User. Multiple business processes can utilise the business service without any knowledge of how it is implemented, only that it will achieve the desired result. The functional manager of the service can then change the implementation without needing to change any of the referring processes.

If all of the functional requirements of a business process are met in this way then they become very easy to sustain; however there is a requirement for strong governance and change management to ensure each business services continues to deliver the agreed results.

One solution to the terminology problem is to adopt an organisational Process Taxonomy, describing the meaning of all of the terminology used. When this is linked into a Process Methodology that is trained and adopted across the business, then you will have a much better chance of achieving real common understanding. My glossary may be a good place to start!

Do you have any word based war stories to share? How would you achieve common understanding?