Project Kickoff: Look Internally First
Maximize Business Performance
Information Management Magazine, February 2004
In my January column, I wrote about the overall life cycle of a business performance management (BPM) project. Now it's time to drill into the first phase where you evaluate the need for BPM, define the goals and ultimately specify the requirements necessary to generate a request for proposal (RFP). Within this kickoff phase, there's a logical sequence of steps that is a prerequisite for success. The company needs to set strategic goals for the project and decide what it is willing to spend to reach them. Then, the stakeholders are interviewed to determine what BPM metrics are needed to support the overall goals and in what form those measurements should be delivered.
Next, take a careful look at what systems are already in place and which of your chosen BPM measures and processes those systems can reasonably support. The gaps - what your company needs but current systems are incapable of providing - will in large part define the new BPM functionality you need to acquire. Along the way, the senior team must prioritize which processes and departments to include in the scope of the BPM project. Almost certainly, they will look at whether the business processes involved are already optimal; some best practice analysis may be needed before you automate those processes.
Many companies start by researching BPM vendors on the Internet to see what their products do. Don't confuse that with your first phase. Look inside your company first, and perform a thorough needs assessment before you get pulled deep into vendor evaluation.
Advertisement
Strategic Goals
To set the overarching goals, get the viewpoints of the senior stakeholders. Be careful when selecting participants for this step. Err on the side of inclusiveness. Should the chief financial officer (CFO) participate? It's quite likely. The head of customer service? That depends on your type of business. Every director involved in budgeting? Not at this early stage. What about the chief executive officer (CEO) or the chief operating officer (COO)? Yes, almost always. The project needs a committed executive sponsor, and the higher the level, the better.
An oft-cited BPM goal is to enable the identification of revenue opportunities and cost savings. Another goal for many companies is to raise the speed and accuracy of collecting and delivering information in order to boost ownership of results and move the company closer to a real-time footing. Don't get too specific at this point. Giving the CEO a colorful dashboard is not a strategic goal. Stay at a high level.
Once strategic goals are established, you can put a value on them by deciding what to spend on the BPM initiative. That budget, in turn, dictates the breadth and scope of the project and whether you can include all the processes and departments that could potentially benefit.
Once the strategic goals are endorsed by senior management, it is time to interview a broader group of stakeholders and determine what it will take to support those strategic goals. You may include mid-level interviewees from the departments that will be affected. Open-ended conversations can be interesting at this phase, but a structured needs audit will go a long way toward ensuring the right questions are asked, the answers are remembered and appropriate weights are given to all responses. Correctly prepared, the needs audit will make evident which business processes, departments and systems should be included in the scope of this project.
What to Measure and Why
At this point, you are not working alone - you will have selected a task force that probably includes mid-level people from finance and information technology (IT). You need them to specify what will be measured and how it will be measured. Key business drivers define the choice of metrics. If your business depends on customer satisfaction, you will probably want to measure product returns, churn rates, complaints and, on the positive side, repeat purchases. If your company's mission is to deliver high- reliability software, you'll measure defects per thousand lines of code or customer satisfaction with implementation.
One word of advice: When anyone asks for a particular metric, test the proposal by asking, "How will that measure be used?" Typically, the response will be that it is to ensure performance stays within an acceptable range. Your follow-up question is, "And if we're out of range, what action will be taken to correct that variance?" This action plan is very important. Measurement without action provides little value. It is pointless and embarrassing if company meetings take place around dashboards where most of the dials show variances in blazing red, but are shrugged off or ignored. If that happens, then you've missed the real business drivers - or the people in that room don't feel ownership or control of these measures. It is a sign that no action plan was devised when the metrics were chosen.
If you've been surfing vendor Web sites on the side, you have probably picked up some sense of the functionality they offer, and that will help your team determine which components and specific features of BPM will be most valuable. You'll start to get a picture of whether you should have dashboards that support balanced scorecards, budget systems that support rolling forecasts and active alerting capabilities for quick reactions. It may be valuable to involve an experienced BPM consultant to match your preferences against the reality of what vendors can deliver today because feature descriptions on Web sites can be overly optimistic.
Systems Audit
You are almost ready to create the RFP. You still need to make a fresh assessment of what your current systems can contribute to reaching the project goals. What systems are in place? Does the company want to continue supporting them? What are these systems used for today, and is there unused functionality you could use tomorrow? What do people like and dislike about these systems? What are they missing? Again, we recommend a structured approach, using a systems audit tailored to BPM issues. It is likely that existing systems will fall short, and the functionality they can't deliver is a close indication of the functionality you need in a new BPM system. Also, keep in mind that the new system will probably still need to interface with the existing ones.
Challenges
Page 1 of 2.
