"How do we know when to improve a process or reengineer it?

This is a frequent question, usually about a specific process, especially from project and team leaders on their way to project management roles. As people start to view project processes as a critical success factor for projects, they naturally want to improve their processes to better fit their custom projects.

Project management encompasses process management for not only the main work of the project, but for the project processes. If project management does NOT include process management in your organization, perhaps it should…

When starting new projects for my clients and also when called in to ‘fix’ projects, examining project processes is at the top of my list. Many times quite a lot of the discord within a project team and between a team and management or other organizations can be traced to project process inadequacies.

Here are factors to mull over when deciding how to handle a process change: the size of the change, the number of and specific people involved, your organization culture, single or multiple organization involvement, complexity of the current process, if technology can be applied, the impact of the results you seek, if the process will affect multiple projects, and whether or not you will have management backing for your project.

Let’s take a quick look at three different tactics to consider when one of your processes needs updating: Tweaking, or normal continuous improvement changes; Redesign, for those processes needing significant changes; and Reengineering, when you are in trouble or need a ‘big hit’ productivity improvement.

If most of the factors above are low, then gently improving your process is the way to go. Without a lot to gain, there are other areas where your efforts will be better spent. Minor, controlled changes can be planned and adapted to optimize or to address small process problems. An example would be switching your change control meeting day from Thursday to Wednesday to make a weekly document update schedule for your public internet pages. This type of change generally requires input and action from those whose work is affected by the change. Management may want to be informed, however will not be concerned. Tweaking of this nature can be successful without using many change agent tactics. Tweak at your whim!

If many of the factors above show above the minimum, and the change required is not too complex nor does it involve many organizations, redesign may be your best option. Significant problems or bottlenecks in several areas can also lead to process redesign. An example would be to reform your change control team around the Marketing and Customer Support functions rather than software maintenance.

Perhaps prior, your change control function was driven by production MIS or in-house users. Now management needs different responses as the product may be farther along the product life cycle or for other reasons. Redesign may point you to delete or add a step or two in the process and tweak many of your steps. Redesign normally keeps many of the same process steps, and in this case perhaps changing only the priority setting functions and the major players. Your effort expended during redesign working the people side of the change equation will not be wasted. Redesign anytime you see gross inefficiency, when technology in common use in your organization can be leveraged, or when business goals or climate change.

Market changes or at least one significant factor that is clearly in need can be enough to trigger a process reengineering effort. More normally, higher rankings in multiple factors may lead you to attempt to reengineer one of your project (or feeding!) processes. Make sure up front that you are not changing for change sake, and that you will have enough allies and management support to finish what you start. Reengineering is definitely riskier, defining risk here as the chance to gain higher rewards or to lose your investment, in this case your clout, time, and effort. Sometimes the downside to a failed reengineering effort is that NO changes will then be addressed for a long period of time.

Reengineering a process requires a thorough ‘as-is’ process review, setting your goals, and a complete recharting of all the tasks and responsibilities that are now deemed worth doing. Today, technology almost always plays a critical role in our capabilities. Many techniques we now use, or at least are familiar with, may not have been available when your process was first laid out, or even as it evolved.

Questioning each step of your process, really getting down to whether or not each step adds value to the overall process, is a painstaking process in itself. Ask yourself when deciding to reengineer, whether your team has the knowledge, the time, and the patience to walk through all the steps one by one, probably with multiple groups multiple times. While your group may have something to gain, another group may end up feeling like they lost, whether it be people or control. Remember, just because you have an AH HA moment and realize where great savings can be had, your associates may well take some hard convincing, over a period of time. Reengineer (at your peril…) when you see huge gains from cutting or crafting many steps, when your change may make the difference between success and failure, or when adopting a new technology will allow you to leapfrog your current, out of date, processes.