Recently, I was engaged in a lively conversation about enterprise agile transformations and the topic turned to Project Management Offices (PMOs) and, specifically, Project Managers (PMs). The gentleman I was speaking with said that in ideal agile, there is “no need for Project Managers”. His argument was that they are replaced by Product Owners, Delivery Teams, ScrumMasters, and/or Functional Managers.
At first glance, there may appear to be merit to his statements. Let’s look at some of the evidence:
So was the gentleman correct? I contend that he was not, especially as you start to scale agile in larger organizations. In fact, in my experience, buy-in and alignment of the PMO and Project Managers could make or break your transformation.
I will not deny that the traditional role and responsibilities of a Project Manager changes and may be distributed in agile, however, the skills and experience PMs bring to the table are extremely valuable.
Effective Project Managers have good organization and communication skills. They are well versed in risk and dependency management. They understand ways to manage time, cost, and scope. They know the organization and how to remove impediments.
So what becomes of Project management in an enterprise agile world? There are many roles a traditional Project Manager can play. One such role is as a Portfolio Manager on a Portfolio Team.
The Portfolio Team is responsible for setting the vision and strategy, deciding on initiatives in which to invest, and ensuring value is aligned with business strategies. The Portfolio Manager helps make sure that the team has everything it needs to function effectively. This goes beyond just scheduling recurring meetings. The Portfolio Manager can act as a servant leader, removing impediments, measuring progress, and enabling the team to make decisions on the portfolio.
The Portfolio Manager is the facilitator for the team. They help keep the team accountable to adhering to processes and working agreements, as well as ensuring the team operates efficiently.
Another role could be that of a Program Manager on a Product Owner team. As an organization scales, it becomes difficult to manage dependencies and risks. It becomes overwhelming for a Product Owner to provide clarity of the backlog to their delivery teams.
By forming a team around a Product Owner, many individuals can lend support and capacity to the Product Owner, providing delivery teams that backlog clarity. A vital part of that team is the Program Manager. They help to clear impediments, manage dependencies and risks, hold the team accountable to providing all the things necessary to ensure the delivery teams are never starved of requirements. They can also serve as an escalation point for blocks and issues that cannot be resolved within the delivery teams.
Other areas and roles a traditional Project Manager could serve or grow into include Release Manager, ScrumMaster, Community or Practice Lead, Product Owner, or Internal Coach. I tell Project Managers to really think about their long term career goals and be proactive in pursuing those areas of interest.
The biggest lesson I try to impart is how to be a servant leader. Changing your mindset from directing to serving can be difficult. But, in an Agile world, servant leadership is what is needed to be truly successful. Enabling others to be successful, will make the organization and the individual successful. When the teams win, everyone wins.
I encourage Project Managers to seek opportunities where they can help the organization and the transformation. With a Project Management background and a servant leader mindset, PMs can grow into incredibly effective agents of change.
Quite often, when process work enters the analysis phase, there is either a fair bit of confusion or (perhaps more typical) a lot of running forward with no direction. At this point in a project, the effort of gathering process information is finished and people are eager to move on to the next phase of fixing/improving the process or redesigning it. However, they know they "should" do some analysis first. Sadly, the very approach that created problems in the process may be used at this point to analyze the problems, e.g., fire-fighting, checking the box, or "the way we've always done it" (whatever that is). This is really unfortunate. The highest Return On Investment (ROI) from a process improvement effort will be generated by excellent analysis. Really good analysis of a process will uncover the real problems instead of the symptoms, the perceived problems, or the personal pain points. Improving/changing a process based on the symptoms or pain points results in sub-optimization and frequently produces negative, unintended consequences.
For example, I recently sat in on a presentation by a group whose project objective was to solve the problem of not knowing who, how, or where to contact the staff in the event of an emergency situation (such as a hurricane in the Gulf). They put together a very good presentation on their solution, which included compiling all the necessary information so that it would be readily available in the future. That's a great idea, right? Not really. They missed the fundamental problem. The real problem was that the assessment process that was supposed to ensure that there was a process in place when an "event" occurred to contact people was completely inadequate. Otherwise, the problem would never have been a problem. With their solution, they now have a contract list, but the next time an "event" occurs, if the people are different or their numbers have changed or the person responsible for actually doing the contacting is different or... they will still have the same problem. Had they done a proper job of analysis, they would have realized where the real problem was. And by fixing that core problem they would have helped not only their own area of the business but several others as well since this safety assessment is an integral part of almost everything in their business.
Understanding the various analysis techniques won't necessarily fix this kind of problem, but it does provide a well-stocked tool kit to pull from when planning the analysis of current business processes. This in turn results in higher quality, with more accurate and valuable results.
There are a multitude of analysis techniques that can be applied to business processes in an effort to determine what problems need to be addressed. This article provides a brief overview of the most common and useful techniques. Many of the techniques are referred to by different names in the various disciplines of process analysis. The most common/generic names will be used although it should be noted that many of these techniques are also used in Continuous Improvement, Lean, and Six Sigma efforts but have acquired different names even though the techniques remain the same. This can cause confusion for people who are new to process and process analysis efforts and it can create the impression that the Lean and Six Sigma concepts are new ideas. In fact, the techniques in both disciples have been in existence and have been used by analysts for many years prior to the Lean and Six Sigma 'branding'. A mapping of the original or most common name to the Lean or Six Sigma names will not be part of this article but will be included in follow-up articles that go into more detail.
Focus on the "Right" Things
Often, just deciding on what to analyze creates a frustrating dilemma. It's so easy to be distracted by the identified pain points and symptoms, making it very difficult to step back and view the information objectively. There are no "silver bullets" for this but the following concepts should help.
There are other questions, but hopefully this list will get you started and will help generate ideas for other appropriate questions to ask.
Process Analysis Techniques
There are a multitude of techniques that can be used to analyze processes. This is part of the problem — too many choices. It has been my experience over that last twenty years that there are five techniques that should be used every time. Beyond that, the answers to the questions in the previous section, as well as common sense, help determine if other techniques will be necessary or useful.
Critical (5) Analysis Techniques
The critical five techniques are:
The first three can be done in facilitated sessions.
Other Analysis Techniques
Other useful and frequently-used techniques include:
The Critical (5) Analysis Techniques
Gap Analysis — Utilizing all Process/Activity Information
Gap analysis is one of the most useful types of analysis. However, if complete information about the process isn't available to conduct this analysis then most of the value it should provide will be lost. The complete information about process includes inputs, guides, outputs, and enablers. This is not a new concept, although many people haven't seen it or haven't seen it in a long time. It is part of the oldest modeling technique. Definitions of each component follow.
Input: something that is consumed by or transformed by an activity/process. Guide: something that determines why, how, or when an activity/process occurs but is not consumed.Output: something that is produced by or results from an activity/process.Enabler: something (person, facility, system, tools, equipment, asset, or other resource) utilized to perform the activity/process.
Input: something that is consumed by or transformed by an activity/process.
Guide: something that determines why, how, or when an activity/process occurs but is not consumed.
Output: something that is produced by or results from an activity/process.
Enabler: something (person, facility, system, tools, equipment, asset, or other resource) utilized to perform the activity/process.
When analyzing gaps in the process from an input/output perspective, it is useful to consider the following items:
Guides are the source for the greatest opportunity for improvement; therefore they should be carefully analyzed for:Legitimacy Accuracy Relevancy Appropriateness Value to the Customer/Business
Guides are the source for the greatest opportunity for improvement; therefore they should be carefully analyzed for:
Value-added analysis is a detailed examination of every activity/task in a process to determine if it supports/contributes to customers'/stakeholders' requirements or needs. To add value, a process/activity must produce an output that creates value for the customer, and the completion of the activity must be required to create that output. The objective is to optimize the value-added steps and to minimize or eliminate non-value-added steps. It is worthwhile for the team to identify the non-value-added actions as early in the analysis as possible.
The decision tree shown here depicts a very basic approach for the initial evaluation of the "Outputs from Activities." Each activity should be evaluated for its true value to the process. This technique can be used as a starting point in a facilitated session with the business.
Depending upon the discipline for "process improvement" that is being followed or implemented, the titles assigned to the three categories of value-add are:
When evaluating the potential for value, activities are classified into the four phases of a typical process life cycle: Plan, Execute, Review, and Adapt. Furthermore, Plan can be broken down into planning (VA) and preparation (NVA) activities. Execute can be broken down into execution (VA), storage (NVA), movement (NVA), and handling (NVA). Review can be broken down into prevention (VA) and control (NVA). Adapt can be broken down into prevention (VA) and processing defects and waste (NVA).
The Planning part of Plan and the Execution activities in Execute normally are considered value-add activities based on these definitions:
The verbs in the table below describe activities that are normally considered value-added.
Utilizing the concept of the process life cycle to evaluate value, the verbs used in the activity naming convention are the focal point. This method examines the verbs that should be part of the verb-noun naming convention. There are many verbs that indicate a strong potential for an activity to be non-value added from both the customer and business point of view.
As a key to identifying non-value-added actions, the following is a sample list of verbs or actions that are normally considered to be non-value-added. This is a valuable method for creating the "top suspect" list. This list can be used to ask more detailed questions, if necessary, regarding who, what, where, when, how, and why (5 times).
To change something to make it fit, conform, or suitable for use.
To give consent to someone or something as being good or satisfactory.
To set something apart from something else or mark it for a specific purpose.
To alter, substitute, or replace something with something else.
To put something in its proper order.
To gather things together for some purpose.
To make an imitation of an original thing.
To carry something and leave it at the proper place or places.
To give something out, scatter, or spread it out.
To take someone or something out; remove it or get rid of it.
To speed something up or make the progress easier.
To arrange something in order for future reference or to put it in its proper place or order.
To look at something carefully or examine it critically in order to detect flaws or errors.
To put someone or something into or on something else.
To keep something in good condition, position, or repair.
To determine or estimate the dimensions of something by the use of a standard.
To check on or regulate the performance of someone or something.
To change the place or position of something by pushing, carrying, or pulling it from one place or position to another.
To make arguments, ideas, texts, or accounts of something consistent and compatible with something else.
To put something back in good condition after damage or decay.
To express a wish or desire for something in a polite or formal way.
To bring, send, carry or put something back.
To examine or inspect something formally.
To read something over carefully and to correct, improve, or update it where necessary.
To choose or pick something from among several alternatives.
To prepare something for future use.
To stop something on its journey through a process and hold it in a particular place.
To bring something up to date or make it conform to the most recent facts, methods, or ideas.
To test or check the accuracy or correctness of something through investigation, comparison with a standard, or reference to the facts.
To stop and wait for someone or something to catch up.
Root Cause Analysis
Root Cause Analysis:
This technique uses what is commonly called a "fishbone diagram," Ishikawa diagram, or "cause and effect diagram." This diagram relates all possible causes to specific effects. Finding the real root cause of an identified problem is not a science but rather a technique that repeatedly asks why things are the way they are.
In conducting root cause analysis, examine the following areas related to a process:
Root Cause Analysis-Cause and Effect
Another technique often used to determine the "real" root cause is a Cause and Effect Matrix (or Table). This technique identifies the potential cause or scenario where a problem occurs then records the most likely effects of that scenario for analysis. For example:
Observation — Observing the Process ... "In Person"
One very important (but rarely applied) analysis technique is that of "observing the process." This must be done in person. As workers and workplaces have become more decentralized and many teams work in different locations, this has become very difficult to do, but that doesn't reduce the importance and value of the technique. Nothing is as enlightening as actually seeing the work done. More often than not, when people simply talk about how they perform their work, the description is more of a "should be" than it is a true representation of how the work is actually done. Observing people at work confirms whether there is an accurate understanding of the current As-Is process.
In a perfect world, it is best to see the work under various scenarios. The list below represents various scenarios or approaches for seeing and understanding the "real" process activities.
Examining the Experience
Quite often the quickest way to reach a destination is not via the most obvious path.
All organizations have experienced and competent staff. These individuals (who typically have 15+ years of experience) are a wealth of knowledge for a process analyst. Their knowledge and experience is an integral part of why the business runs smoothly, even when the unexpected occurs. These are the individuals who know how to expedite a six-week activity and make it happen in two days. They intuitively know all of the non-value added activities and the policies, traditions, or culture that drives them. A complete and accurate analysis of process is never complete without input from this group.
The analysis phase is often the phase where the focus of the improvement effort is lost as the goals and objectives are forgotten and the assumed problems are addressed and solved without due consideration given to whether these are the real problems. Or it can be the phase that is given the least attention due the fact the initially-identified problems are the only problems to be solved and little or no actual analysis is done. Yet, the analysis phase has the potential to provide the highest ROI of all the phases. That includes the To-Be or redesign phase because if the real problems are not identified then the To-Be work may (unintentionally) actually design the same problems back into the processes.
The world has changed dramatically over the past two decades. Email, the Internet, and now social media have increased the interconnectedness of the world. Globalization has led to intense competition, forcing companies to expand product portfolios and design increasingly complex manufacturing processes and supply chains. Government regulation has become progressively more active, forcing companies to create new organizations and processes to ensure compliance. All these changes have driven substantial complexity into the environment in which companies operate, and the pace of change continues to accelerate.
Complex systems have several characteristics that make them especially susceptible to high consequence/low probability events. First, complex systems have many interdependent variables that do not necessarily act in linear or predictable ways. Second, they have feedback loops that act to amplify or dampen reactions. As these interdependent variables are amplified or dampened by feedback loops, complex systems often exhibit emerging properties causing them to behave in ways that are virtually impossible to predict.
A flock of birds is a classic example of a complex system. No one bird is in control of the flock. In fact, no single bird even knows in which direction the flock will move. Each bird follows a few simple rules (i.e. don’t run into each other, maintain a standard distance, align flight to match neighbor, etc.), and from these simple rules, a very complex pattern of behavior emerges. As companies become more and more complex, their performance becomes more like the flock of birds in that it is difficult to predict and impossible for a single person to control.
Traditional approaches to risk management are not well suited to preventing the high consequence/low probability events that arise from complexity. First, traditional approaches rest on the ability to predict potential failure modes so that actions to prevent or mitigate the risk may be put in place. The emerging properties exhibited by complex systems make this virtually impossible. Second, the feedback loops present in complex systems often cause circumstances to change so fast that there is not adequate time to identify the risk. Finally, these events happen so infrequently, and with so little notice, that there is not ample opportunity to study and learn from them.
Unfortunately, recent history is evidence of this trend. High consequence/low probability events are becoming more and more frequent. Disasters of the scale of BP’s Deepwater Horizon, Fukushima Daiichi, and the West fertilizer plant are becoming all too common. And this increase in catastrophic failures is not limited to safety and environmental incidents. We have seen similar trends in financial markets (e.g. 2008 housing collapse, current collapse of oil prices) and product quality incidents (e.g. Takata air bag recall, Blue Bell Listeriosis outbreak). The bottom line is that unless we do something differently, as the world grows increasingly complex, we will continue to find new ways to cause destruction and devastation. In fact, some leading thinkers have resigned themselves to this fact and simply accepted these catastrophes are the new normal.
In fact, a select few organizations have been able to defy this trend. These High Reliability Organizations (HROs) have been able to demonstrate extraordinary levels of performance even in highly complex operating environments. We look to these HROs to understand how they are able to achieve extraordinary levels of performance, over sustained periods of time, despite operating in highly complex, high-risk environments.
One of the most significant lessons we take from HRO’s is the importance of culture. An organization that expects people to just do what they are told, mind their own business, and not question authority, simply will not succeed in today’s complex world. It can’t because it is impossible for leaders to predict what will happen next and direct all activities. To survive and thrive in a complex environment requires a culture that encourages people to understand not just what they do but why they do it, question things that are out of the ordinary, and back each other up. Organizations that can create a culture consistent with these characteristics of HROs will not only avoid catastrophic failures, they will outperform their competition across every measure of operational performance