Successful process projects that will change your company
As organisations seek to improve their internal business processes, many of them have learned that process improvement is most efficiently done through the use of project management. Individual business process improvements (BPI) and enterprise-wide business process integration efforts are effective ways to make a company more efficient by removing ineffective processes and eliminating redundancy.
However, process improvement efforts are fraught with potential failures. If the business has been in existence for more than a few years, the processes often no longer resemble their original designs. Processes grow and evolve as the business changes and, even if they were documented when first designed, the documentation is almost never kept current. Even more important, processes are a combination of activities performed by people and activities performed by IT systems, and therefore are neither the province of business analysts (who often don't understand IT) nor the province of IT (who almost never understand business processes).
Most important, process projects affect how people work. Long-time employees who have been doing the same thing for many years are now being told that their jobs are changing. The normal reaction of employees to the announcement of a process improvement project is to assume that people will be laid off. Even if there is no intention by the company of letting people go, those rumors will start and will severely impact the project if the right amount and kind of organisational change management is not made part of the project.
An example is given of how these areas are being managed at a major utility company that is facing a strict regulatory environment, high growth, and the loss of over 10% of its experienced workforce due to retirement within the next five years.
Davenport defines a process as “a specific ordering of work activities across time and space, with a beginning, an end, and clearly identified inputs and outputs: a structure for action.” (1993, p 5) While most of us now have an understanding that businesses are run through business processes, this is a surprisingly new viewpoint. As recently as the late 1980s and early 1990s a much more common view of a business was as an organisation made up of functional departments, clearly identified by the organisation chart. Business processes, on the other hand, cut across organisations – they may be done by multiple parts of the organisation in multiple geographic locations. We understand this now, but it was a pretty radical thought only 15 years ago.
What are some business processes? Order processing, manufacturing, hiring employees, payroll – all of these a processes. Each industry, and each company, has their own set of business processes. A manufacturing company has many different processes than a pharmaceutical company or an architectural firm. Some business processes must be done by virtually all companies, but the exact details will vary from company to company. A universal business process is creating payroll checks. An employee enters the week's timecard information into the computer. The software takes the time information and the financial codes for the items the employee worked on during the week, pulls the employee's deductions from the database, calculates national, state, and local taxes as well as retirement information, Social Security information (in the U.S.), insurances, any deductions such as medical or educational set-asides, and prints out a stub that is passed to the employee. Sometimes a physical check is printed and given to the employee, sometimes the money is automatically transferred to their bank account.
Like all processes, this common process involves people, process steps, and technology. It has an input (timecard information), process steps, and outputs, including the payroll stub, the check or money transfer, and the storage of information needed to report pay and Social Security to the government.
Effective processes are an integrated combination of these three items: people, process steps, and technology as illustrated in Exhibit 1:
Exhibit 1: Integration of People, Process Steps, and Technology
Inputs to processes come from suppliers and the outputs go to “customers”. The customers for most business processes are other processes that utilize the outputs of the preceding process. Occasionally the output may go to a person. The payroll process mentioned earlier consists of multiple small processes, each of whose outputs form an input to the next process in line. Only the final outputs, the pay stub and the check, go to a person.
There are two characteristics of processes that contributes to the difficulty of managing a process improvement project – processes interact with each other; and processes can have other processes, lower-level processes, embedded in them as well as being part of higher level processes. Both of these contribute to the criticality of exactly defining the boundaries of the project – what is included in the project scope and what is excluded.
Why Companies Are Looking At Their Processes
Companies throughout the world are under pressure to reduce costs and provide the same products and services at lower prices. The first approach of many companies is to reduce the number of people. Next, they begin to outsource work to cheaper labor if possible. The next step (which historical research shows should actually be the first step, not the last one) is to improve the efficiency of their internal processes. The more efficiently these processes run, the greater the cost savings while still providing the same or better results.
Making a company's processes more effective and more efficient is not a one-time effort. With the evolution and changes in technology there is a continuous stream of new ways to do things. This requires a continuous-improvement approach to improving processes rather than a single large change.
One major U.S. electric company is currently undergoing a massive, enterprise-wide business process integration effort. They began this effort when upper management suddenly found themselves facing a serious problem: as much as 10% of their experienced workforce was eligible for retirement within the next five years. In one core business unit, the BU that was responsible for power transmission and distribution:
- 30% of their (largely unionized) workforce was over 50 years old
- 16% were eligible for retirement
- They were adding 70,000 new meters every year, within 5 years they will add 50% new customers
- The average work package to add a new meter took over 200 pages of documentation.
In addition, the utility discovered that they had 17 time management systems, over 170 IT applications that don't talk to one another, and their costs were 50% higher than that national average for an electric utility. In 2004 they began studying what could be done to improve themselves internally and in 2005 embarked on a large scale, enterprise-wide improvement effort that will span several years. The author created a course for them in project management for process improvement projects and taught it to several dozen of their project managers. These numbers are not atypical in either private industry or in government organizations such as NASA and indicate the pressures on management.
Why are Process Improvement Projects Different?
Process improvement projects are fraught with dangers, even the small ones. Clearly defining the boundaries of the project is critical If this is not done carefully, it is almost certain that someone in the organisation will assume the project is making a change to part of a process when there was no intention of making that change. This will result in a missing interface to either data or to another process. The end result is a failed project, with management feeling that these projects are a waste of time and effort.
More critical even than this is the changes that will be implemented if the project is successful. The IT portions of the project will not be a problem, that just requires money and expertise. What will make the project successful, or destroy the work entirely, is getting the employees to buy into the new processes. Anything that impacts how people do their day to day job is treacherous. You're threatening the one thing that provides them an income and impacts their social relationships at work.. If you don't believe this is important to them, you will likely not do the right things on the project and it will fail.
Getting Buy In
Getting buy in to the project cannot be overemphasized. There are three levels at which buy-in needs to occur:
- Executive level
- Upper/middle management
The Executive level of the corporation is the least likely to create a problem. They have probably already bought into the need to do process improvements, otherwise the effort would not even start. While there may not be universal agreement among the executives as to the extent of the changes needed, there is at least enough support to authorize the BPI effort.
The people that project manager needs to be concerned about are middle management and employees. Both of these need to be shown the benefits of the change effort (different for each one) and either of them can sabotage it.
Middle management is likely to feel threatened by changes to their organisation or power. If part of their organisation is involved in the process being improved, they have a stake in the project and will be impacted by it. They must be carefully shown how the change will improve their organisation in order for them to start thinking favorably of it. If they only see a downside to the project but are being told by their executives that they have to go along with it, they will often sabotage the project in subtle ways – not attending meetings, assigning their worst employees to the effort, not signing documents, not meeting timelines. In any BPI project there are an infinite number of ways to damage it while not appearing to do so.
The third group that is impacted are the employees. As soon as employees begin hearing about changes at work, the FUD factor (Fear, Uncertainty, Doubt) starts coming into play. People will start wondering if management is truthfully telling them everything or if this is the beginning of layoffs and downsizing. This is an emotional response, not a rational one, and begins as soon as people hear about the process change effort or as soon as someone comes around asking them how they work. People are going to be nervous about what you're doing will react to your team and to the project based on that nervousness.
In order to mitigate employee concerns, the project manager needs to involve the employees as much as possible in defining the new processes and include a serious amount of communications and of Organisational Change Management (OCM) effort in the project. The utility company the author is working with hired a consulting firm specializing in OCM to lead this portion of the overall change process. A representative from the OCM organisation is an automatic member of each project team and leads the project communications effort.
Most organisations have a mix of skills and experience levels in them. People who are relatively new, and people who have been there for years. People who are happy with the way things are right now, and people who are unhappy. People who see no problems with they way things work right now, and people who are willing to improve things. There's an old saying in managing organisational changes: 20% of the employees will be in favor of what you're doing and are willing to go along with the change; 20% of the employees are happy with things right now see no reason to change, and will resist you; and 60% of the employees are somewhat neutral. They will support you if they can see the benefits to themselves, but will turn against the project if they don't.
Successful change projects are careful to involve the employees early, clearly sell them on the personal advantages of making the change, and show early successes. Change projects that end up with the changes not be successfully incorporated into the daily work of the employees have probably concentrated on just the mechanics of the change itself and not on the employees.
The Process Project
Beyond the normal steps involved in any project, there are some steps in a process improvement project that include:
- Creating the organisational change management and communications efforts
- Identifying the sources of the process information
- Defining the process boundaries
- Clearly defining the goal of the process
- Creating the “as-is” diagram.
- Creating the “to-be” diagram
- Developing the gap analysis
- Developing the pilot project
Throughout the project, any part of the organisation that is impacted by it, employees and management both, need to be communicated with constantly. No matter how thorough a job the project team does on the technical aspects of creating the new process, all will be a failure unless the people agree with it and buys into it. Getting this buy-in may require some workshops in organizational changes for the employees in addition to constant communications.
Creating the organisational change management and communications efforts
The criticality of the OCM and communications efforts was discussed earlier. Rarely is a process improvement project done as a standalone effort. Most often improving one process points out the defects in other processes so they also need to be improved. The most efficient way to organise an improvement effort is to set up a programme and to create individual process improvement projects under the programme umbrella as shown in Exhibit 2:
Exhibit 2: Change Programme Organisational Chart
Because processes cut across organisational lines, sufficient representation from each affected organisation should be on each project. A typical process improvement project might have the following groups (taken from Harrington (1991)):
- Executive Improvement Team (EIT), including a high-level czar
- Process Improvement Team (PIT)
- Sub-process Improvement Team (Sub-PIT) if needed
- Department Improvement Team (DIT)
- Task Team (TT)
with the EIT being part of the overall programme and only monitoring individual projects at a very summary level. In addition to the programme manager, a high-level manager or an executive should be appointed as the Change Czar to emphasize the importance of the work and to have ultimate decision authority when changes that improve one part of the organisation make another part less productive. The relationships among these different groups is shown in Exhibit 3 (taken from Harrington, 1991):
Exhibit 3 – The project team
Identifying the sources of the process information
While it would be nice to just pick up the organisation's existing documentation on the processes to be changed, in reality the documents almost never exist. Or, if they exist they became outdated years ago. The best source to existing processes are the IT documents for any steps that are automated and the employees themselves for any steps that are manual. The most productive way of understanding the employee-performed steps is to simply watch how people work. This gives you much more information than asking them how they do things.
Defining the process boundaries
Drawing a clear line defining the scope of the project is critical, as mentioned earlier. Because processes generally overlap and interact with other processes, a clear delineation of what items you will include in the project and which you will not prevents any misunderstanding as to exactly what is being changed. The scope exclusions section of the project charter may be larger than the scope statement itself.
Clearly defining the goal of the process
Defining the specific goal of the process helps you decide what the new or revised process should do. Is the goal of the payroll process to primarily provide a paycheck to the employee? Or is it to gather information to feed to the government on an employee's salary? Or both? By clearly identifying the goals you can create a more efficient process than exists now.
Creating the “as-is” diagram.
The “as-is” diagram shows the process as it exists right now. This is usually done in the form of a flowchart showing the process steps, inputs, outputs, and decision points. Because most people in the organisation don't know where the process starts or where it ends, let along the steps involved, documenting the process is a matter of starting anywhere in it, asking where the inputs come from, where the outputs go to, and then putting the pieces together when all the steps have been identified.
A traditional way to start is to create a very high-level diagram identifying the Suppliers, Inputs, Process Steps, Outputs, and Customers of the process (SIPOC diagram) as shown in Exhibit 4:
Exhibit 4: SIPOC Diagram
Once the process is diagrammed at a very high level, then normal flowcharting techniques can be used to document the details of the process steps.
While it would seem important to understand the existing processes as thoroughly as possible, the project team should only spend enough time on this phase to gain a general understanding of the process. Remember, the goal of the project is to replace the existing process. Much more time should be spent on designing the new process than in understanding the existing one.
Creating the “to-be” diagram
As part of the analysis, the team should clearly designate value-added (VA) activities from non-value-added (NVA) activities. By definition, a value-added activity adds value to the information or product flowing through the process steps, NVAs do not add value. NVA activities can be further subdivided into necessary activities and unnecessary activities. Going back to our payroll example, value-added activities would include entering the timecard information into the system and moving the money into the employees account or printing out the check. A non-value-added but necessary activity would be giving the employee the pay stub showing the details.
Creating the new process steps is where the team's creativity can be exercised. The goal of making the change is to make the value-added activities as efficient as possible and to eliminate or reduce the NVA activities.
One goal often desired by management is to automate as many of the process steps as possible. While an admirable goal, this should be done very cautiously. Virtually every process needs to have decisions made and needs the ability to handle exceptions. A fully-automated process has limited ability to make intelligent decisions and it is very limited in its ability to handle the small percentage of cases where exceptions from the normal process need to be made. This is where people need to be designed into the process. In one case, when a new employee started his first day of work the computers were down in the HR department. Because there was no way for the staff to perform the processes manually until the computers were back up, the new employee did not have a telephone assigned, a network address assigned, or receive a paycheck for six weeks.
Developing the gap analysis
Once the new or revised process steps have been designed, a gap analysis is performed to identify in detail how design the new process into the system and phase out the old process.
Part of the project plan should include not only a design of the new process, but also identify the new skills required for the employees to perform their parts of the new process. Part of the gap analysis then includes identifying the training required to bring the employees up to the new skill sets. The new skills required should be communicated to the employees as soon as they are identified and the employees given a choice of training in the new skills or moving to a new job in the organisation.
Developing the pilot project
Because of the complexity of process improvement projects, the lack of detailed process information in most organisations, and the general lack of experience in upgrading processes, the final output of the project should not be an enterprise-wide new process that's rolled out to the entire organisation. It should be a pilot project that is tested in one part of the organisation. Performance metrics are collected, the reaction of the employees to the new process is assessed, and any shortfalls in the new process are identified. Many problems are found by doing this and the damage to the overall organisation is minimized.
These are then used to modify the new process before it is rolled out to the entire organisation. The pilot should be chosen so that it can provide not only the information needed to improve the new process, but also to show the benefits to the organisation of the new process. Showing a quick improvement to both management and employees is going to make the full organisation-wide rollout much easier.
Business process improvement projects are some of the most difficult to do. Not because of their size or technological complexity, but because they change how people work. The announcement of process change projects immediately leads to suspicion on the part of managers and employees that layoffs are coming or that their authority is going to be downgraded. Unless extraordinary care is taken to communicate the goals of the process improvements and clearly show the benefits to both managers and employees, sabotage, either covert or open, can be expected. The project manager of a process project needs to set up a part of the team dedicated to helping people deal with the impacts of the change.
Another aspect of process projects that needs to be managed carefully is specifically detailing what is included in the project and what is not. If this is not done, because of the complex interconnects among processes incorrect assumptions are likely to be made about what is being changed and what is not. This can lead to process steps or data connections being missed or to other problems that will only be caught in the pilot project.
Davenport, T, (1993) Process Innovation: Reengineering Work Through Information Technology, Ernst & Young
Harrington, H. J. (1991) Business Process Improvement, New York, McGraw-Hill
© 2006, Frank Parth
Originally published as a part of 2006 PMI Global Congress Proceedings – Madrid, Spain
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…