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.
Tagged , , , , , , , , . Bookmark the permalink.

6 Responses to Why Processes need Projects and Projects need Processes

  1. Steve Romero, IT Governance Evangelist says:

    Very interesting post. I don’t generally encounter somebody who contemplates the nuances of business process design and improvement project management. It is encouraging and confusing at the same time. I am confused because I am not sure what problem you have encountered that would prompt you to make the quite accurate assertions in your post.

    I think it is reasonable for a project to focus on “improving an area of the business.” That is simply another way of characterizing the need to review and potentially revise the processes of said business area.

    The “business area improvement” would simply be the “program” and each subsequent associated business process requiring improvement would initiate sub-projects of that overall program. (I like two projects per process. The first focuses on the redesign. The second focuses on implementation of the new design – and the massive organizational change management required.”

    I completely agree with everything in your post. I am just a little fuzzy on the precise problem you’re solving.

    Steve Romero, IT Governance Evangelist
    http://community.ca.com/blogs/theitgovernanceevangelist/

  2. @Steve Romero, IT Governance Evangelist

    Thanks Steve, I have been mulling over your final point – what is the precise problem?

    The problem is that the majority of the time my Process Management efforts are pushed aside by projects that are scoped to deliver an IT system. The project thinks they are doing the right thing, why they have a Business Analyst busily mapping processes; however this will not lead to sustainable process improvement. Usually it just delivers a new IT system.

    I have worked with several BPM frameworks that clearly define the “Process Project” coming before the IT project – this is what I am aiming for in the above post. Even talking to non-IT project people, they always seem to miss the concept and the project is back to delivering the wrong change.

    Cheers
    Craig

  3. Chris Molloy says:

    I agree, Craig. I have seen too many projects either fail or only half deliver because those involved do not realise the importance of defining the processes. It actually does not matter whether it is an IT project or a business change project or program, if you do not define the “as is” and “to be”processes FIRST, and then design the journey to deliver that change the project will not succeed.

    Cheers
    Chris

  4. Thanks Chris for a good sum-up of what is often the issue with projects. The related problem is how projects often don’t achieve sustainability, we celebrate successful delivery of outputs and don’t achieve benefits (even in the rare cases where benefits are measured).

    The solution in my mind comes from strong governance over the project process, driven by people that care about the value the organisation is getting from it’s projects. I am a strong supporter of Programme Management Office (PMO) and extending this to include a Process Management Office.

    Cheers
    Craig

  5. Felipe says:

    Excellent article. And your response to Mr Romero just summarizes our improvement professional’s everyday life.
    To improve takes time and a lot of effort. Most of the times people prefer to apply some tool in a stand alone way, without connecting it to a process improvement project, or to build some IT system that is just going to make an inneficient process goes inneficient faster.

    Cheers.

  6. Thanks Felipe for your comment, and yes, it is often easier to implement the quicker, cheaper approach rather than tackle the real improvement problem – it is understandable, given that is how most people approach problems every day!

Leave a Reply

Your email address will not be published. Required fields are marked *