Assessing the current environment using logical and physical models
Process modeling techniques should be incorporated in the beginning of any change effort when clear and accurate documentation does not exist for current processes. Analyzing a set of work practices through the use of logical models (what processes are performed) and physical models (how processes are performed) serves multiple purposes. After project stakeholders gain alignment on a true picture of the current state, they can then agree on the process strengths needed to retain or leverage them and the weaknesses that need to be eliminated or minimized. This increased knowledge and level of alignment allow the stakeholders to identify the appropriate initiatives, which will address their real (versus perceived) pain points and opportunities. The resulting models also serve as a powerful educational tool, to be used beyond the project improvement effort, for orienting or training new staff members on the practices and responsibilities of their new jobs. This paper demystifies the process modeling and assessment activities, often misused or avoided by project teams, to enable project stakeholders to embrace these powerful tools with confidence and focuses on:
- A structured process improvement life cycle
- The use of process modeling techniques that distinguish between logical and physical process models
- Collaborative assessment activities that uncover valuable process strengths to retain, process breakdowns to repair or replace, and opportunities to pursue.
After working on hundreds of change efforts with project teams in many different industries, it has become clear that one of the most common challenges project teams face when attempting to introduce change, is achieving alignment on what the current state truly looks like before new solutions are proposed or implemented to change the current state. It doesn’t matter if the project is associated with an expansive process improvement effort, covering many work processes, or is a more focused change to work practices in a specific area of the organization, change efforts can quickly go astray due to lack of skills and techniques for process modeling and assessment. The unfortunate result is that many organizations waste limited and often scarce resources when they continue to run projects that fail to address the core opportunities or process breakdowns.
The use of process modeling may sound like a recommendation for only the most technically adept members of the project team. However, this level of trepidation toward process modeling need not be the case in your organization. Once you understand the concepts and techniques for process modeling and process assessment, you will realize that you can introduce and utilize these tools with all levels of stakeholders. Engaging stakeholders who oversee the processes, perform the processes, and/or support the processes will result in the quickest and most accurate way to complete an assessment and produce a robust list of project initiatives that are ready to be prioritized, funded, and executed.
Although specific guidelines should be applied when conducting process modeling activities, it is important to keep in mind that process modeling is as much an art as it is a science, allowing room for stakeholder interpretation as they describe their environment in a manner that is clear to them. A common mistake made by teams employing process modeling techniques is starting at the wrong level of detail in their models. The tendency is to begin modeling at the lowest level of work in which the most pain will be felt or need for improvement exists. This costly mistake typically leads the team off track or causes it to miss critical components in the work processes. The techniques presented in this paper will provide a powerful tool for every project manager’s toolbox, enabling project management teams to understand process modeling concepts, lead stakeholders through meetings to collaboratively discover and peel back the layers in their work processes, and then confidently assess their practices.
The Process Improvement Life Cycle
A key element of any process improvement effort is a comprehensive list of project initiatives, which differentiates tactical from strategic initiatives and shows a clear link to how each initiative supports the strategic plan of the organization. Coming up with the “right” list of initiatives is often the challenge faced by many organizations. Stakeholders may brainstorm, clarify, and prioritize their list of initiatives, but how can they be sure these initiatives address the real issues associated with process breakdowns? The answer lies in understanding and following a process improvement life cycle. The process improvement life cycle recognizes that establishing an initiatives list is not the starting point of the process improvement effort.
Steps 1 and 2, in the process improvement life cycle ensure there is a common understanding of the current state environment. If the organization has been diligent in creating process documentation as their practices are defined and keeping this documentation current each time processes are updated, then these initial steps are quicker to complete. Current state documentation should consist of end-to-end process models that accurately depict what work is being performed today. When this documentation does not exist, the logical and physical process models are created during these steps. One of the big mysteries associated with process modeling is often: “How do I explain the difference between a logical and physical model?” The answer is simple when you focus on what each type of model is intended to communicate. The logical process model communicates “what work is being done,” whereas the physical process model communicates “how work is being done” (i.e., what = logical and how = physical depictions of work).
Step 3 in the process improvement life cycle, is the assessment of the current environment. During the assessment phase, stakeholders who perform the work, represented in the models, or have a vested interest in this work, will review the physical models and make notes of strengths in the current process that should not be lost, touched, or amended. These strengths should be retained and leveraged as changes are designed. The stakeholders also make notes regarding process breakdowns that should be fixed or opportunities that could be introduced to improve the effectiveness of the processes. The assessment phase ultimately produces a list of opportunities that will be considered for inclusion in future process improvement initiatives.
Step 4 in the process improvement life cycle is the creation of the initiatives list. Opportunities resulting from the assessment activity are transformed into initiatives. Initiatives are considered to be fully documented when they are tied to the organization’s strategic plan and constraints, critical success factors, and assumptions relevant to the initiatives are documented. During this step, initiatives are prioritized based on a variety of criteria (e.g., value to the organization, value to the customer, ease of implementation, etc.). At this point, the process improvement teams now have the information needed to begin the final stage of the process improvement life cycle—executing the prioritized initiatives that have been funded, with the confidence that they are working on relevant initiatives and aligned on what opportunities each initiative is intended to address.
Understanding the Current State – Logical Process Models
Logical Process Model Steps
The logical process model is created first and defines work that is being performed today. The activity starts with a small core group of team members. Be careful not to overstaff this core group, but make sure it does include people who are members from each of the process areas associated with the improvement effort. I suggest that you include two levels of stakeholders from each area: a manager-level stakeholder familiar with the overall purpose of the process and a line worker familiar with actually doing the work. The logical model will be created for at least three levels of granularity: the context diagram (level 0), process model level 1, and process model level 2. As you drill down into the lower levels of the logical process model, it may be necessary to add additional subject matter experts to ensure the processes are being documented accurately. Depending on the complexity of the processes, some may need to be drilled further. A good rule of thumb to follow when drilling down a level is that if you can’t decompose the parent process into three or more lower-level sub-processes, then it is probably at the lowest level needed.
Context Diagram – Level 0
The context diagram is the highest level logical model that is built. Think of each level of the process as a way to look closer and more granularly at the work that is part of the current environment. The context diagram is the highest view of the work and is created at the 50,000-foot level. What does this level look like? Imagine you were in an airplane flying over the United States and could look out a window. You would be able to see the boundaries or edges of most cities you were flying over. You could distinguish between roads with cars on them, buildings and homes, parks, lakes, and rivers, but you would not have a clear view of the details of any of these objects. What types of cars are on the roads, who is in the buildings and what are they doing, and what is happening in the parks? These answers will not be clear to us at the 50,000-foot level.
The context diagram (Exhibit 1) depicts major efforts of work (five to seven) that are being performed (shown as business processes in the yellow box) and the handoffs that occur with entities outside of our immediate organization area (shown as external entities, the blue boxes around the edges of the context diagram). The context diagram establishes the foundation that will help teams clearly see when they have stepped outside the boundaries of the parts of the organization they want to assess and improve.
Business processes are at the center of the context diagram, so don’t confuse them with departments of the organization. Business processes represent work that people in departments perform, and it is this work that is the focus of the logical process model. Think of a business process as a machine that is transforming something: An input comes in one side of the process, actions are performed on this input, which transforms it into a different object that comes out the other end of the process. The transformation can be simple (i.e., an unprioritized list becomes a prioritized list) or radical (i.e., raw materials become a final product), but the transformation definitely produces something that is different from what came in.
The external entities on the outside of the diagram can be external companies, other parts of our organization, people, departments, or systems. External entities have their own work processes that provide the inputs needed for our business processes to complete work or they rely on our processes to produce outputs for them to use. Although our process improvement initiatives do not affect the external entity processes directly, external entities add value to the model, because they show the handoffs of information between the external entities and our processes.
Exhibit 1 – Context Diagram
Another rule of thumb to follow when you create the context diagram is to target the number of business processes in the center box to be between five and seven processes. Typically, our brains can clearly retain up to seven ideas at one time without much confusion. When we move beyond seven ideas, they tend to blur or we may forget some of the ideas without relying on a memory jogger (i.e., a list of ideas). If you define fewer than five processes, you run the risk of over blending the processes—putting too many dissimilar work actions into a process or having processes without clear and differentiated boundaries. There is no single right answer when dividing the overall process into its seven business process components; the seven processes you define may be slightly different from the seven processes I define. What is important is that all of the stakeholders agree on and understand the purpose and boundaries of each of the business processes that have been defined.
Process decomposition is a technique used to create the list of business processes for the context diagram. Working collaboratively in meetings, the stakeholders brainstorm their views of the process components for the overall current state process that will be modeled and assessed. The list will contain many levels of processes, some of which are duplicates, as well as those that are subsets of other processes on the list. As the ideas are reviewed and clarified, the items on the list are continually collapsed together. After clarifying the business process the first idea on the list represents, continue to review each subsequent idea, answering the question: “Is this idea similar to or part of a prior business process we have defined or is it unique and can it stand on its own?” Similar ideas may be synonyms of other processes and are removed from their separate row in the list and added to the description of the earlier defined process. If the idea is a unique business process, it is kept on the list with a brief description for its purpose. It may take two or three passes to finalize the decomposition list, but every time I lead team members through this activity, it never fails that they end up with just six or seven business processes for the diagram.
Process Model Level 1
After developing the context diagram, we are ready to take a closer look at the current state of the work. The process model level 1 diagram is created at the 25,000-foot level; from this viewpoint, we will have an end-end-end picture of the business process interaction between each process. It shows the trigger that starts the overall process and the final deliverable that ends the overall process, as well as the triggers and outputs of each of the business processes in between.
The overall process trigger comes from an external entity and is the catalyst causing action to occur in the first business process added to the model. Let’s assume that the overall process we are modeling and want to assess is for a major function in our company: acquiring new customers. This acquisition effort is triggered when senior management provides funding information for an acquisition campaign effort. This trigger is provided to the first business process: set acquisition account goal (Exhibit 2). A unique output flows from this process: goal information. This output will be the input to the next business process. Before determining what the next process is, it is helpful to know what the end point of the overall process (acquiring new customers) is so we don’t define work flows that go beyond this end point. In our example, the overall process—acquiring new customers—ends when a campaign has been concluded and the campaign performance and assessment information are provided back to senior management.
Exhibit 2 – Process Model Level 1
Now that the starting and ending points for the acquiring new customers process are known, we can fill in the flow for the rest of our process model level 1 diagram. The output from the first business process is the trigger for the next business process (determine the audience universe). This second process provides another unique output—marketable universe—that communicates the size of the overall universe of prospects from which we will solicit new customers. After we have determined that marketable prospect universe, we can plan the campaign effort, which will give us a campaign quantity allocation or the amount of overall universe that will receive solicitations during the campaign. This information is used to build and execute the campaign, which produces campaign performance results and a campaign assessment. We now have the order of the actions for the overall process and the major triggers and output flows between each process depicted in our logical view model. Notice that we haven’t confused our model with any physical details on how to perform these processes.
Process Model Level 2
Process model level 2 will give us a closer view of the current state, bringing the view down to the 5,000-foot level; many additional details will become viewable at this level. We decompose each of the level 1 processes into their three to seven components (sub-processes); we carry down the trigger that initiated the parent business process and indicate which sub-process it flows into; then, we also carry down the final output of the parent business process and indicate which sub-process it flows out of. Now, we can define the outputs from the first sub-process, which is the trigger to the second sub-process and continue to define the flows for all of the sub-processes in between, thereby creating an end-to-end view of the sub-processes that make up the parent business process (Exhibit 3).
In addition to the trigger and ending flows for each sub-process, the process model level 2 also includes the ancillary flows of information required to perform the actions of the sub-process. These flows typically come from the external entities shown on the context diagram or from other processes represented in the model or logical stores of information introduced as work progresses through the model. Focus only on significant flows of information and describe these in generalized terms. We do not want to clutter the model with bits and pieces of information (e.g., include “customer information” or “product requirement information” in the flow versus customer name, customer address, customer telephone number, etc.).
Exhibit 3 – Process Model Level 2
Process model level 2 provides a validation of the models developed at the higher levels. We can now clearly see where each external entity provides input or receives output in the current environment work flow. It is not uncommon to discover new information flows at this level coming from an external entity not reflected in the context diagram. Because we are much closer to the actual work details, it is easier to see these new flows and handoffs, which were not evident at the 25,000- and 50,000-foot levels. New external entities must be reflected on the context diagram. Likewise, when the process model level 2 is completed, we may find an external entity, referenced at the context diagram, which was not included anywhere in the model level 2 diagram. We are smarter now and may decide the entity was never needed; hence, it can be removed from the context diagram. Keeping the diagrams in sync across the levels is an absolute requirement to ensuring that the current state of work in the model is accurate.
Understanding the Current State – Physical Process Models
Physical Process Model
A common misconception is that the physical process model is a completely different model than the logical process model, which is not correct. The physical process model is simply the ground-level view of the logical process model. The physical model changes the focus of the modeling activity from “what work is being done” to “how the work is being done.” This is where teams typically have their “a-ha moments,” as they realize that all of the unique ways they perform work, originally leading them to believe they do very different things for different purposes than any of the other teams in the organization, are actually just variations of the same work they agreed was clearly depicted in the logical process models. The difference is not in what they are doing, but rather in how they are doing the same work across the organization. This is why starting a modeling activity with the physical model is a dangerous approach because it leads to describing different implementations of the same work as if they are totally different processes. Basing the physical process model on the logical process model overcomes this misperception of having many unique processes (i.e., the process of planning the campaign has the same purpose, regardless of whether it is automated in one work area and performed as a manual process in another work area).
Physical details are now reflected in the models by adding the actual names and images of the physical objects to generic names described at the logical level (e.g., customer information is physically provided via the customer demographic database, product information is provided via a Word document, product requirements.doc, etc.). When multiple forms for the information exist, the physical process model will include the physical variations of this object. If the input information for a process is in the form of a spreadsheet, then a page from that spreadsheet is attached to the model where this flow is depicted. If the input information for the same process can also be provided more informally from the content of an e-mail, then a copy of an e-mail is attached to the physical model as well.
Brown Paper Model
As you might suspect, the model becomes very graphic and busy at this level of detail, which is how the concept of a brown paper process model came to be. Up to this point, the models are typically represented in an electronic form (e.g., Visio Document, etc.). These electronic models can now be reproduced in a physical form by affixing long sheets of paper (originally brown butcher or packing paper) to the walls of a large room. All of the objects from the electronic logical model (business processes, data flows, external entities) are placed on the brown paper model in the same order and using the same color scheme as they appear in the electronic version. Long strands of thick yarn are used to represent the data flows between the processes and entities. The physical documents or objects for each data flow can now be attached to the model as well (Exhibit 4).
Exhibit 4 – Brown Paper Model
Don’t confuse the fact that because the model is now physically placed on the wall, that this is what makes it a physical process model. The model becomes a physical model because of the additional physical characteristics of the work flow that are added to the model (i.e., moving away from generically described objects to “as implemented” objects). It is possible to have a physical process model that is contained solely in electronic form. We simply add the physical information to the model (i.e., names and all of the electronic images/snapshots of the physical documents representing flows of information). Many teams opt for the electronic approach of the physical process model when the stakeholders are not located in the same geographical area.
Assessing the Current Environment
The biggest asset to the current environment assessment activity is the clarity provided by the logical and physical process models. A sense of confidence exists when there is an accurate depiction of current work that includes the variations of how work is being performed before any initiative to change the environment is ever proposed. The project team responsible for creating the process models can now socialize these models across the rest of the affected organization as they solicit input on pain points to be minimized or opportunities to be incorporated into the future state. Inviting the people who are actually performing the work depicted in the models is the best way of uncovering process breakdowns and identifying efficiencies and improvements for the area.
As the formal assessment of the current environment begins, don’t make the mistake of rushing through this activity. Invite all of the potential stakeholders/reviewers to a kickoff meeting and walk them through the physical process model that represents the work they are performing, informing them that there is a desire to improve the processes that are now in place. After the orientation, provide each stakeholder with pads of red and green sticky notes. Ask them to walk around the room looking closely at each process and making notes of the key strengths they want to ensure remain in the future state after improvements are implemented. Their comments should be placed on green sticky notes and attached to the specific object in the model they are referring to (i.e., business process, data flow of physical form of the data flow). Then, the stakeholders should walk around the models again and make notes of problem areas they would like to see fixed; ask them to write these comments on the red sticky notes with a brief description of the problem and/or the desired future state and place these on the model.
Encourage the stakeholders to be honest and candid with their assessments, to take their time, and to even consider coming back on their own over the next few days to walk through the models again. The physical process model provides an overwhelming amount of information, so stepping away and coming back later is a great way to remove some of the blinders that may initially exist when the assessment first starts. After the reviewers see their work practices presented graphically in front of them and then go back to their work environment, they often view their day-to-day tasks differently, new ideas come to mind, and they can now put their ideas into words and share them.
Eventually, as the reviews come to an end, the sticky notes are collected and transferred to an opportunities log. As each sticky note is reviewed, it is clarified to ensure the documented issue or need is understood as it is entered into the log as an opportunity. As each sticky note is reviewed, determine if it is a duplicate of, or related to, an opportunity that is already in the log. If so, there may be additional details about this opportunity on the sticky note that can be added to the earlier opportunity idea. If it is a new opportunity, add it to the log with a clarifying description. As opportunities are recorded in the log, make sure to populate a reference column in the log that ties the opportunity back to the specific object it refers to in the process model. This practice creates a cross reference to quickly getting back to the model’s details when an opportunity is questioned or challenged.
An initial investment may be required to build the logical and physical process models to ensure they accurately represent the work currently performed in the organization. Although this activity may take several weeks up front to complete, the time spent will not be wasted. Significant time will be saved on future project efforts, because the models now exist and the modeling activity does not have to be repeated. As new process improvement efforts or projects are funded, the process models can be reviewed to quickly establish alignment on the current state before any proposed changes are ever documented. Once the changes are implemented, the process models can and should be updated as part of the project documentation, before the project is closed, to reflect the new current state.
Beyond the valuable alignment gained while producing the models and the clear framework it provides for assessing the current environment, the process models also serve as an excellent training tool to orient new staff members on the work that is performed in the organization. The context diagram provides a simple, high-level, single-page view of the work processes and handoffs associated with the current environment. It also establishes an easy to understand frame of reference for the boundaries of work performed by the organization. The logical process models eliminate the distracting details of how processes are implemented, allowing the new team member to grasp the essence of work that is performed first. When ready, the specifics for how work is performed and what it looks like as the processes are executed can be clearly represented with the physical process model or brown paper model. I have worked with several organizations that have permanently implanted the practice of posting their brown paper models on the walls of their work areas to serve as a quick reference point when they are considering the impacts or scopes of new projects they will run.
Completing an assessment of the current environment in order to identify the appropriate initiatives to invest valuable time and resources in can now be enhanced by easily including the input of many potentially impacted stakeholders. These stakeholders have access to a common and accurate set of information describing their work practices. The resulting initiatives list, produced as an output of the assessment activity, is a higher quality deliverable to communicate which initiatives should be funded first, because it was derived from an accurate understanding of the existing workflows, their breakdowns, and improvement opportunities.
Project Management Institute (PMI). (2008). A guide to the project management body of knowledge (PMBOK® Guide)—Fourth Edition. Newtown Square, PA: Author.
© 2010 Paul Burek, PMP
Originally published as a part of 2010 PMI Global Congress Proceedings – Washington, DC
Hurricane Katrina decimated thousands of buildings in New Orleans, Louisiana, USA, in 2005, including a U.S. Department of Veterans Affairs (VA) medical facility that served approximately 40,000…
Federal Project and Program Management Community of Practice (FedPM CoP) – How Sharing Best Practices Can Lead to Success
Recognizing the value of a community focused on project practice capability and how such a community could help improve the performance of departments across the U.S. federal government, the leaders…
Developing a Project Management Office in the Department of Energy, Energy Information Administration
This case example, a supplement to the report, PMIAA: Strengthening the Government Delivery Foundation, highlights project and program management capability building within The U.S. Energy…
Commissioned and supported with research from PMI, MIT’s Consortium for Engineering Program Management, and others, this report distills how many government agencies have been leading (and continue…