<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1907245749562386&amp;ev=PageView&amp;noscript=1">
Event_bg

The Leonardo Blog

All Posts

The Benefits of a Process Architecture in Project and Portfolio Management

 16_the_benefits_of_a_process_architecture_for_project_and_portfolio_management.jpg

As noted previously, one of the foundations of Business Process Management is a business process architecture. In fact, in our view, it is the first of the seven enablers of BPM, and indispensable for process-based management in any organisation. This article explores the ways in which a process architecture can assist to prioritise and manage portfolios of projects.

Project Scoping

The first benefit of using a process architecture in managing projects is that it assists with project scoping. Understanding the boundaries of the project (i.e. what it will and won’t change in the business) is fundamental to understanding which processes it will affect. A process architecture is of great value in this, as it allows a top-down, coordinated approach to assessing scope. Because a process architecture collects processes in a hierarchy, grouping related processes together, it is easier to see the scope of a project by assessing which parts of the process hierarchy it will affect.

This offers two major advantages:

  1. Scale can be assessed quickly by looking at how many processes the project will affect, and to what depth.
  2. Scope boundaries can be set against a commonly understood and agreed reference point; that is, by setting limits on which processes the project is allowed to modify and which ones it will not affect.

This enables project portfolio managers to make informed decisions about the scope and scale of proposed projects, and clarifying scope reference points by using a stable point of reference to understand what the project will and won’t do.

 CLICK TO TWEET
Use a process architecture to tighten up your change portfolio. http://ctt.ec/L1yp8+ #bpm #7enablers

Project Impact and Dependency Analysis

Second, a process architecture offers a concise, repeatable way of understanding exactly what impacts a project will have. Because we have set the scope of the project against the processes it will affect in the process architecture, we have a quick way of narrowing in on exactly what the project will change or replace.

This is because the process architecture identifies which detailed business processes will be affected. Using this information provides project portfolio managers and decision-makers a quick way of identifying the people, activity, and technology impacts of a project, as all these elements are tied together in a process architecture. Understanding the processes affected by a project provides a huge boost in understanding whether people’s roles or daily activities will change, identifying potential training, and work instruction requirements. Examining processes will reveal, for instance, that a change to supporting software may impact related processes that also rely on that software, or on related pieces of software that support an affected process.

A corollary to this is that using a process architecture to assess project impacts, assists with understanding the impacts of decommissioning processes or supporting technology. Frequently, projects are assessed from the point of view of the effort and cost of introducing a positive change – that is, what it will take to change something currently running in the business, or to introduce something new. However, the cost and effort of retiring existing processes and technology can be just as significant. Using a process architecture to assess what is affected when a process is decommissioned can be a powerful way of identifying impacts that, otherwise, would only be discovered in the course of the project; this may cause time and budget problems.

A related concept is analysing dependencies. Dependencies between projects will be discussed below, but it is important to note that the impact analysis described above provides a powerful way of identifying the dependencies of any given project in relation to the environment it is operating in. Because the process architecture offers a way of linking things that make processes run, any changes to those things can be readily identified as dependencies for a project. Managing dependencies thus becomes easier to do up front; this reduces the project risk by increasing the amount that is known at the start of the project, and decreases the chance of discovering potentially disruptive dependencies in the middle of the project.

Watch 7 Enablers of BPM Video

Benefits Management

A properly designed and executed process architecture will include important information about how the performance of processes is measured and assessed. The ongoing management of process performance is the job of Business Process Management, but a key concept is that the measurement of processes is built into the architecture.

This information is critical in understanding how projects will realise benefits. By showing which processes a project will change, the process architecture also provides a view of which performance measures will be affected by the change. This enables project managers to assess and set targets around performance improvement for their changes.

Project Design

One of the positive effects of this approach is that project teams themselves can benefit from having a suite of information to accelerate design. Rather than having to construct or reconstruct significant amounts of process documentation from scratch just to establish the groundwork for the project, having a viable, functioning process architecture means that project teams can focus on the project deliverables knowing that they are targeting the correct problems.

Likewise, this has a similar benefit in ensuring that the work a project team hands over at the conclusion of the project is useable within the architecture without significant rework, and makes a valuable contribution to the depth and currency of the existing set of information.

Project Prioritisation and Portfolio Analysis

One of the most important benefits in using a process architecture in managing a portfolio of projects is in prioritising, sequencing, and coordinating large portfolios of projects. In many organisations, the need for change is constant, which gives rise to increasingly large and complicated portfolios of projects running concurrently. This can lead to unwanted duplication between projects, as well as potentially harmful competition between closely related projects for time, resources and attention.

Using a process architecture can help in the following ways:

  1. Laying out proposed projects against the major elements of the process architecture makes it relatively easy to visualise how much work is proposed in which processes. This helps decision-makers understand the extent of change in a process, making it easier to identify potential conflicts.
  2. By following the scope and impact analysis approach suggested above, more is known about projects earlier, and the impact they will have on processes will be known in more detail. This enables portfolio manages to understand in more depth exactly what a project will change. This, in turn, allows for better identification of potential duplication or competition between projects, enabling active decision-making on project scope and viability before potentially costly commitments have been made.
  3. Combined, the two points above provide useful insights into the dependencies between projects, because they enable portfolio managers to see how different projects are related as they make changes to processes. Where multiple projects are proposed at the same time for a given business process, the two points above allow decisions to be made about sequencing of projects – that is, how to resolve dependencies by making decisions about what parts of a project must happen first for the process to continue to function.
  4. Taking a more macro view leads to the ability to make better decisions about prioritisation. By understanding the impact and likely scale of benefit, as well as understanding how projects fit together against critical business processes, decision-makers are better able to prioritise projects when they first to determine which processes are most in need of improvement and, second, by seeing which projects will benefit most.

In conclusion, using a process architecture as a key tool of process-based management does not have to be solely about managing day-to-day operations or making strategic decisions. A process architecture offers real value to shaping, scoping, and delivering portfolios of projects.

DOWNLOAD PROCESS ARCHITECTURE PAPER

Darren Wright
Darren Wright
Darren Wright, Senior Consultant with Leonardo Consulting is a specialist process architect with extensive experience in the Higher Education, Technical and Further Education and Government sectors.

Related Posts

The Ultimate Guide to Process Modelling

A new day, a new process modelling project. The project plan has been signed off, reference documentation was gathered, all stakeholders have been identified and now…now what? While process models increase in popularity and most businesses seem to agree that process models are indeed a good way of representing how an organisation creates and delivers value, there is little to no guidance on what a good process model is, how to create one and how to successfully go about executing a process modelling project. While this guide does not claim to be a silver bullet for all your process modelling problems (look at our Modelling Excellence framework for that!), it aims to be a guide for Project Managers and BPM Professionals in every stage of the modelling journey, regardless of whether you’re just kicking off a new modelling project, are in the middle of a major project, or are just looking for a refresh. Please note that this guide does not address steps to set up or configure a process modelling tool. It is focused on the activity of process modelling.   Let’s get started! This section includes topics that should be covered prior to kicking off any process modelling project. If a project is already underway, but struggling, we recommend revisiting this section to ensure the basics have been covered. If your project is already underway and going well, you may opt to skip ahead to the “Business Process Modelling” section. It’s all about the purpose… Firstly, ensure the purpose for modelling has been identified and agreed upon by all stakeholders. Whether it is communication, training, process measurement, improvement or configuration of a workflow tool, any modelling effort must serve a purpose. Major decisions such as “What modelling tool is the right one?” as well as minor decisions such as “Should I include this detail in my model?” can easily, logically and consistently be answered once the purpose has been identified. Consequently, if a clear purpose for modelling cannot be identified, no time and money should be spent on modelling as the models would end up being waste. The start of a process modelling project is also a good time to identify additional use cases for process models and pitch those to the stakeholders. The more use cases there are, the more robust the business case for process modelling becomes. Models that are re-used often are valuable to the organisation, rather than just useful for a one-off project. This does not mean that creating models for one-off use is waste. Although we generally recommend maintaining and re-using process models as much as possible, there are many valid use cases for and circumstances under which organisations choose to create process models that will be deleted once the project is completed. We do however emphasise that this purpose needs to be clearly identified and agreed upon, so nobody comes looking for the model two years later and needs to then kick off another modelling project since the former models are either out-of-date or nowhere to be found. Understanding the purpose of modelling will also help Modellers in the information elicitation and model validation stages of the project. They must always be prepared to explain what they are doing, why they are doing it and how it benefits the organisation. A strong pitch for modelling, tied back to the purpose, will help to keep stakeholders focused during workshops.

Moving From Continuous Improvement to Continuous Process Management

  Continuous process improvement is a common organizational aspiration, and it is one of the most difficult things an organization can attempt. The continuous aspect is quite a challenge, as is realizing business performance improvements—especially once the easy and obvious changes have been made. Organizations need an ‘internal improvement engine’ that replaces insistence with evidence.

Process Architecture vs the Organisation Chart

  In my working life I spend a lot of time working with client organizations to discover and capture useful models of their process architecture. In every country, industry sector, organization type and size, there is a common problem that bedevils every project. We all, and I include myself here, can too easily slip into the habit of the last 100 years (or you might argue 1,000 years) of visualizing the organization as its organization chart. Comments such as “What about the work they do in department X?” might just be a useful test for a developing process architecture, or they might indicate a lack of understanding of what the architecture represents.