Oyebola Olugbemi - Process Management - A Key to Successful Project Management

1. Oyebola Olugbemi - Process Management - A Key to Successful Project Management Can process management and project management actually co-exist? Not only have I found that they co-exist, but that they actually drive one another's success. Have you ever heard the phrase "the devil is in the details"? I always thought that this saying was a little strange...until I began to work in project management. The funny thing is that once I got into project management this phrase made so much senses. I can remember being on one project where the project manager was much too myopic. All she cared about was data storage requirements and virtually nothing else. For this project manager, the devil in the details was never thought about, outside of the confines of data storage anyway. On another project, the project manager was so sure of his own abilities to "do his job" that he completely ignored the details altogether. The latter project had some disastrous outcomes...including Social Security deposits being returned to the state that sent them, which in turn resulted in that state discontinuing those payments. In other words, major customer impacts occurred because people were overly confident in their own ability to adapt to a changing process. So what does this have to do with project management? Everything. If a project is creating something unique, then it stands to reason that there are variables that are known and some that are unknown. Think of throwing a rock into a lake. You know that the rock hitting the water will cause a rippling effect on the water's surface. What you don't know is how many ripples it will cause or how far the ripples will disperse beyond the initial impact. Process management is a way of taking into account all that may happen as a result of the ripples in the water.

2. Let's say that there is a project is to implement new processing software into an existing data processing center. On the surface, this looks fairly easy. The processing center already exists and the technology is already in place. So other than information technology and/or information systems installing the new software and some training on how to use it, this is a fairly easy undertaking. This is equivalent to throwing the rock into the water. We have a rock, we have water, and we know that the rock hitting the water will create a rippling effect. Problem solved, right? What happens if all of the users of the new software are not physically located in the same processing center? What if there are individuals that send work to the processing center, via courier, because they are remotely located and therefore not able to use the technology that is available to others? Maybe this seems farfetched to you since we live in the 21st century, but I can assure you that it's not. Here's the crux of the problem. It's human nature to make assumptions based on limited knowledge and/or lack of information...especially when dealing with a project. This is why in the Project Management Body of Knowledge (PMBOK), which is one of the standards for project management, process improvement is included in its Project Quality Management section. Process improvement, whether you call it process management, process design, or process engineering, is critical to ensuring that your project is implemented according to scope. If the project is designed according to scope, but fails when put into production, the project is a failure and its scope was never met. A basic assumption of a project is that it will work once fully implemented. Let's look at process improvement from more of an organic standpoint. I use the term organic because we rarely think of process management and project management together. Like project management, process management has evolved into its own discipline. At its roots though, process management is simply a series of shapes and arrows used to illustrate a process. This is the intrinsic value of process management. It allows you to illustrate the process before it is even in place. Put another way, you can lay out the process before the project is even close to being completed. I stated that at its roots, process management is simply a series of shapes and arrows used to illustrate a process. You can map a process (also called a flowchart) using as little as three shapes, an oval, a rectangle, and a diamond. Each shape represents a specific part of the process. An oval represents the beginning or end of a process...the first or last step. A rectangle illustrates an activity. If you place a rectangular box under another box, the second box identifies a task. A diamond is a call out for a decision. It demonstrates that there is a yes or no question within the process that has to be answered. Interestingly enough, this simple shape often is one of the most powerful in identifying gaps (one or more breaks in a process that can cause rework, customer impact, failure, or any other number of issues) within a project and/or process. The arrows are used to direct the "flow" of the process from one point to another.

3. As an example of the win-win of using process management during a project, I was recently on a project where data was being converted from one system to another. The process for this is often referred to as data mapping. You map the data and the fields in the system where they currently reside and map them to where they will reside in the new system. When this was process mapped, the diamond shape was used to ask if the data from our department had been mapped to the new system. The answer was yes. The next activity was to determine how that data would be identified in the new system, to which no one knew the answer. This was a huge gap. If the data had been mapped, then someone should have been able to tell us what that data would look like in the new system. We quickly found out that no one could validate that our area had been included in the original data mapping. What would the impact had been if after the project no one could find the data in the new system? Once again process mapping paid for itself, as it usually does. Another benefit of process mapping is the ability to flowchart the conceptualized process. Let's say that there are a number of activities that you know need to happen and how they will be done. What you may not know is who will do all of the actual work. Think of a loan being originated. Someone is going to take the loan application; someone is going to process the loan application; someone is going to underwrite the loan; and someone is going to close the loan. But who is going to file the documents and will they be scanned into an imaging application? This is an unknown. By flowcharting the process you are able to take the activities you know will happen and then the activities you "think" will happen and create a picture of the process. By using the same shapes, but changing the color or texture of the "conceptual" ones, you are able to illustrate the know activities from the "how we think it will be" activities. This allows others to opine on the process before there is a conflict, such as incorrect procedures being written or worse yet, that part of the process being totally neglected. Perhaps one of the greatest benefits of process mapping, within the context of project management, is that it allows you to better control the work of the project. When the core processes are placed in flowcharts, it is much easier to identify control gaps within the process itself. Control gaps are, in and of themselves, risks within the project. Let's use the above example of a loan being originated. A decision point (diamond shape) in the process is validating that the loan has been underwritten correctly. What happens if no one validates the underwriting? Or, what if the one validating the underwriting is the same person that underwrote the loan in the first place? Segregation of duties has to be a part of the process in order to protect the integrity of the process itself. A flowchart would show if this control has been sufficiently setup or if there is potential for a control failure. Finally, the use of swim lanes is another value added dimension of process mapping. Swim lanes are used to track a process through all of the areas that need to be a part of it, in order for the process to be completed. Think of an Olympic pool. You automatically picture a pool with swim lanes, each one belonging to a different swimmer. Again, let's use the loan origination example. In most cases the origination of a loan takes several areas (called cross-functional areas) working together for a loan to be completely processed. This could entail various areas such as sales, loan application processing, underwriting, closing, and file management. While no single area owns the entire process, they all work

4. a part of the process to ultimately complete a single loan. By employing swim lanes, you segregate each area in the process into its own lane. Then, using the shapes already discussed, you track the process moving from one swim lane to another. This not only illustrates the areas responsible for the entire process, but also the decision points, controls, and ultimately the interdependencies. Getting the process map validated by all of the areas involved seals the deal. Once all agree on the process, a responsibility matrix can be developed and the project is in a better state of control because of it.