We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Lack of Project Planning Can Limit Performance Management Success

Originally published August 17, 2010

Everyone knows there's a right way to do a project and a quicker way that involves cutting corners. Unfortunately, many of the business performance management (BPM) projects we've seen fall into the latter category, and organizations are unknowingly increasing the risk of their projects – with potentially disastrous results. We understand the reasons for sometimes cutting corners, but I’d like to suggest a better way.

While any project can benefit from a solid plan and road map developed at project inception, this is even more important for performance management projects. BPM projects can be large, multi-year implementations of several major modules, similar to large-scale enterprise resource planning (ERP) projects. The difference though is that unlike ERP, most managers in the company will be directly impacted by this system. In addition, with BPM there are more module and priority options to consider. Don't forget this will be a major, high-visibility investment with the most senior management in the company as potential users of the system, or at least the information it produces. Why would anyone risk achieving less than stellar results?

The reason many companies skip or shortcut the planning phase is because they are using BPM to put out a fire. The fire typically comes in one of two varieties. For the finance group, it is often a budgeting “system” that has outgrown its spreadsheet roots and is no longer up to the task of reliably managing the company's detailed twelve-month financial plan. For IT, the issue is usually being overwhelmed by requests for access to information from managers throughout the company. BPM can easily, and relatively quickly, address both of these areas. As companies jump into BPM with a laser sharp focus on the primary issue at hand, they often miss the bigger picture and full potential of business performance management.

Three Main Problems

There are three main problems when jumping into BPM without a detailed road map and plan. The first is the most obvious – no plan. When you are done with whatever you were initially focused on, how do you determine where to take your BPM system next? A fully realized performance management system contains plan data for all major areas of the business, imported actual data from relevant transactional systems, and performance reporting utilizing that data tied back to the company's strategy. More specifically, the elements of a BPM system can include: budgeting, planning, forecasting, consolidation, financial reporting, dashboards/scorecards, operational analytics (i.e., sales performance management) and profitability optimization as well as governance, risk, and compliance. Once you have addressed your most pressing needs, your BPM system will probably stall if there is not a plan in place identifying priorities and timing for the next phases. Trying to create a plan after the fact is difficult. Just pulling the key stakeholders together again is a challenge; and at the end of a lengthy implementation, everyone is ready for a breather. Momentum is lost. So, in this case, no plan probably means that your BPM system will never reach its full potential.

The second problem of proceeding without a well-documented plan revolves around expectation setting. Even for just the first phase, how will people know what is coming and when? With BPM typically having a high-powered (not to mention demanding) group of end users, you need to protect yourself. A plan is a good way to communicate goals and timeframes, and also to set realistic expectations about what will actually be delivered. You can also use the planning process as a way to get input and buy-in from all the key stakeholders. Requests for capabilities that are not going to be in the initial phases can be added to the future-phases section of the plan as a way to demonstrate that everyone's needs are being heard and will eventually be addressed. The group can collaboratively set priorities. Not having a plan in this scenario can lead to a group of disgruntled users, lack of buy-in, and ultimately under utilization of the system.

Problem number three for those without a plan really is about time and money. Let's say you purchase and implement software to address your urgent budgeting needs. Suppose a month later the CFO comes along and says that the monthly close cycle has to be shortened by a couple of days. Well, BPM's consolidation capabilities can do that. However, what if the vendor you bought your BPM budgeting from does not provide the consolidation functionality you require? Do you scrap the system and buy a new one that does both budgeting and consolidation? Do you look for a stand-alone consolidation module that you can spend months integrating with your budgeting solution? No easy answers, but this is a very real problem we have observed firsthand in the field numerous times. If you had put together a plan for BPM up front, the CFO's desire to eventually shorten the closing cycle might have come up then. Even though it might have been slated for a later phase, you would have been aware of the need when you evaluated solutions. You could have bought a product to address current needs but with the ability to expand to satisfy other aspects of your long-term BPM road map as well. Without a well thought-out plan, it is likely you will end up spending more on implementation and technology than necessary.

Start with Road Map and Plan

Clearly, the answer is to develop a BPM road map and plan before you start developing detailed requirements and evaluating solutions. In addition to the reasons already mentioned above, companies often skip this phase because it is assumed to be expensive and time-consuming. Also, because things are always changing, some even question whether a plan will be valid a year from now. While there are certainly consulting firms out there that will spend weeks, or months, working with you on this plan, we believe that is overkill. The BPM road map development workshops we participate in typically run from 2 to 7 days based on the complexity of the business and size of the key stakeholder group. The key is having the right people in the room. If senior management is present to set the tone and define the company's BPM vision in no uncertain terms, things can progress fairly rapidly. It is also essential to have an outside BPM expert facilitating and documenting the discussion. Politics and territoriality can interfere with the road map development process. An independent third-party can avoid getting caught up in this. In addition, they can make sure the right questions are being asked and that the session is grounded in BPM realities. Of course, the road map will be most detailed as it relates to the earliest phases and higher level for the later stages. Things can and will change, but having the overall vision –  that everyone has bought into – laid out in one place is invaluable. As a matter of fact, it's critical to getting the most out of your business performance management investment.

While it's best to create a road map up front, it's never too late. Later phases can still benefit from the process. So how do you get started? The best way is to hire someone on your team who has already gone through this same process for BPM (different from a standard software rollout) or find an experienced BPM consultant to facilitate the process. If you're not ready for that, we have created a free online BPM project planning audit tool to help you get started. Minimally, it will get you thinking about the right questions. It can be accessed here.

  • Craig SchiffCraig Schiff

    Craig, President and CEO of BPM Partners, is a pioneer in business performance management (BPM). Craig helped create and define the field as it evolved from business intelligence and analytic applications into BPM. He has worked with BPM and related technologies for more than 20 years, first as a founding member at IMRS/Hyperion Software (now Hyperion Solutions) and later cofounded OutlookSoft where he was President and CEO.

    Craig is a frequent author on BPM topics and monthly columnist for the BeyeNETWORK. He has led several jointly produced webcasts with Business Finance Magazine including "Beyond the Hype: The Truth about BPM Vendors," the three-part vendor review entitled "BPM Xpo" and "BPM 101: Navigating the Treacherous Waters of Business Performance Management." He is a recipient of the prestigious Ernst & Young Entrepreneur of the Year award. BPM Partners is a vendor-independent professional services firm focused exclusively on BPM, providing expertise that helps companies successfully evaluate and deploy BPM systems. Craig can be reached at cschiff@bpmpartners.com.

    Editor's Note: More articles and resources are available in Craig's BeyeNETWORK Expert Channel. Be sure to visit today!

Recent articles by Craig Schiff



Want to post a comment? Login or become a member today!

Posted August 17, 2010 by



First off, Craig, I love your articles.  Keep up the good work.

Every couple of months one publication or another posts an article just like this one, talking about the importance of project planning to the success of a BPM/BI/BA/CPM project.  Sound advice, but impossible to follow.

Apart from some basic periodical KPIs, there is no way for anyone to know in advance what future requirements will be.  You can only know what the requirements are now, and that is hardly a guarantee for those requirements to still be applicable six months later.  At the very least, after you've collected your requirements, dozens of new ones come along pretty quickly and the entire implementation cycle is redone. Businesses change, processes change, regulations change and new ideas come up all the time.  Every business is different and every person is different. That's life.

Traditional BI is not well known for its flexibility, particularly after the system has gone live so it is only reasonable that traditional BI philosophy preaches for careful project planning.  But in reality, this best-practice you are advocating is impossible to follow using the traditional technology/tools out there.  Even if you consult the most experienced consultant.

In my opinion, the customers would be much better off if instead of focusing on the importance of project planning, more focus is given to coming up with a different paradigm that is more reasonably demanding in its planning requirements.  This is the only way to increase project success ratios which are very poor at the moment (at least for traditional vendors!).  If you keep repeating the same mantras, you are just propagating the reality where a customer is placed in an impossible situation on which everything depends, and then blamed when things don't end up as they should have.

Incidentally, I've recently written about this if you're interested.






Is this comment inappropriate? Click here to flag this comment.