Phase Isn’t a Four-Letter Word

If you’ve been reading the Process People blog, you might have noticed that we talk a lot about an iterative approach to deploying BPM. What we haven’t touched on as much is that the iterative approach is an element of the overarching methodology. Looking in on the methodology from the highest level you will get a view of a three-phased approach – which ultimately results in iteration. But we want to provide a big picture of how all of the different parts of our methodology tie together, and how each point of emphasis leads into or loops back to key areas of the other two phases.

I realize that in some organizations, “phase” is a four-letter word. With BPM it is a must… it is the foundational element that leads to continuous process improvement and ultimately maximum business benefit. But don’t just take our word for it, just look at the countless customers who have used this methodology and achieve enormous success because of it.

Definition Phase

The definition phase is probably the most critical portion of the entire BPM adoption lifecycle. This is where you set the expectations for the BPM project, define metrics to measure the project and create a framework so that the focus remains on delivering business value throughout all three phases.

In this phase organizations should:

• Take the broader initiative and narrow it to a specific departmental level
• Define the business milestones and associated metrics
• Develop the business case
• Ensure that there is a common thread throughout the whole project (Business value)
• Get the business to drive this phase

BPM is disruptive, and it forces you to think differently, analyze your business differently, and work with IT in a new way. So this phase is CRUCIAL to set the tone. This also sets the stage for success as you move on to the next phase.

When you define the requirements, you should only include things that deliver tangible value to the business. If someone wants something, ask them what the business value is. If they can’t answer… well, then that requirement needs to be left for one of the improvement cycles.

John Doe’s requirement to be able to do something with two clicks instead of three is a valid request. But if it takes two weeks to build that feature or function, is it really delivering value to the business? Can it wait until one of the improvement cycles?

Deploy and Deliver Phase

Every organization is familiar with the stage where you actually start executing on the plan. In the past this was considered an IT-led portion of the process. That’s the wrong way to think about this. Participation from both IT and the business community is absolutely essential here. The goal is to deliver business value, which means that the moment you unplug the business from the project, you lose sight of the ultimate goals. IT departments may have a few people who are able to straddle that divide between them and the business, but it’s not the same as having both parties at the table.

Most organizations think that everything ends after the process is deployed and delivered. But this is their biggest mistake. You’re only two thirds of the way there when you deploy. The bottom line is that you’ll never get everything right on the first try, which is the weakness of the waterfall approach.

Hoover’s Inc. is my favorite example. They gave our methodology a shot and ended up changing their entire approach to ALL projects across the organization. They now use this iterative method as a discipline for ensuring success with almost any type of project in their organization.

Improvement Phase

In this phase the business community has to perform an analyst role. This might challenge a business person who has not viewed the organization in this way before. Ultimately the point of this phase is to analyze the metrics and goals that were set forth in the definition phase and see where you missed your goals and where you reached them.

Organizations used to avoid this phase because they didn’t realize the importance of the definition phase at the start and therefore didn’t know how to improve. You cannot get better if you don’t know your weakness. Even more importantly, you can’t know your weakness unless you have something to measure your performance against! That’s what the definition phase is for: to give you something to track against throughout each phase.

Traditionally the people who developed the initial business case disengaged or were re-deployed to other work… and therefore weren’t part of the ongoing project. The project is conducted with a waterfall mentality and the resulting solution typically falls short of reaching its measurement goals and a payback analysis can’t and won’t be achieved. The end result is an organization that is stilled optimized for feature and function, not for measurability and delivering business value.

This methodology and discipline has been used by organizations of every size. When you start talking about a business process improvement program, think about what we discussed here, and decide for yourself if a waterfall approach will actually deliver value to your business.