Continue in 2 seconds

Project Kickoff: Look Internally First

  • February 01 2004, 1:00am EST
More in

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.

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.


You will confront several practical issues. Your team must navigate a complex set of tradeoffs to pinpoint the ideal breadth and depth of the overall project. Some stakeholders could feel left out. The budget that wins approval may not cover the necessary software, implementation, process changes and training.

A BPM project is not a clone of other software initiatives. BPM is an emerging art and science, and best practices ­- including which metrics deliver the greatest value -­ are not yet universally agreed on. There is still a dearth of experience available in this area.

Your BPM project ­- and its strategic goals ­- may dictate the adoption of a unified chart of accounts across your multinational company. This may require a lot of persuasion and shuttle diplomacy. The outcome may well depend on the clout of the project sponsors.

To create an effective RFP, you need to maintain perspective throughout the process -­ or, more precisely, you need three perspectives. The first is internal: an intimate knowledge of your company and its systems. The other two are external: cross-company comparisons and vendor knowledge. It is very useful to get a clear understanding of how companies similar to your own have implemented performance management systems and maximized their payback. You will also want to gradually build or hire up- to-date knowledge of the many software solutions and vendors.


What are the risks in this early phase of BPM? One is getting the project budget wrong. One form of insurance is to involve people who have experience with BPM implementations. You may have them on staff if you're fortunate, or you can look outside your company for that knowledge.

Another risk is overlooking some of the potential benefits. If you finish the evaluation and the focus is still limited to budgeting, you have probably missed some of the value of BPM. End-user surveys and knowledge of other companies' experiences will highlight the key benefits that are possible and help you approximate their cost.

Conflicts are likely to emerge. Often they are between the project owner and other stakeholders who may feel their unique needs aren't addressed. Interdepartmental arguments between finance and IT are not uncommon. Because attempts to satisfy all the combatants can lead to scope creep, which threatens both the budget and the outcome, having an objective arbitrator can be very helpful.

Throughout this phase, you have been talking to key stakeholders, but you mustn't overlook the end users who will live with the new software and processes. Even an excellent BPM system can meet a poor reception after rollout and be ignored if the ultimate users are not brought into the requirements definition process.

Losing sight of the original strategic goals is certainly a project risk. Prior experience and knowing common points where companies forget the overall purpose will mitigate this risk. Again, talk with people who have traveled the road before you.

Finally, plan ahead for system integration challenges, which are frequently underestimated. The system audit will be a considerable help here.

Next month, we'll talk about creating the RFP and a structured approach to cutting through vendor hype that lets you match their product functionality and suitability to your needs and ultimately make the right system choice.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access