During a recent conference, I had the chance to speak with a potential client about the impending failure of a large-scale, high-dollar business intelligence (BI) project his organization had spent nine months developing. As we talked, it became clear that the looming collapse of the project was not due to architectural issues, nor was it due to a failure to capture proper business requirements. The new BI system had only one problem: the user community hated ­– I mean hated – it.

How can a multimillion-dollar BI project, which so obviously – on paper – meets the needs of potential users, fail? Simple. No one on the technical or business teams addressed the changes that would take place in the organization as a result of the system. The user community was simply given the system and told, "Here it is, go do a better job now." In short, the failure of this organization's project was largely due to a single cause: failure to manage change.

To that end, I'd like to lay out the basics of a change-management methodology. I can't guarantee that your BI project won't fail if you follow this methodology. However, I can tell you that a commitment on your part to recognize and manage change throughout the project – by whatever methodology – will ensure that lack of user acceptance won't catch you totally unaware at rollout time, and it will go a long way toward ensuring the success of your project.

The first step in any change- management methodology is to conduct an organizational-risk assessment. First, determine key organizational and people-related risks. Some key indicators that the project may be starting out on rocky footing include:

  • Confusion about goals, roles and responsibilities.
  • No clear means to solve problems and resolve conflicts.
  • Insufficient or weak communications.
  • Leadership perceived as not leading/being out of touch.
  • Ill-prepared and ill-equipped workforce for new operating environment.

Constant monitoring of potential risks and pitfalls must continue throughout the project life cycle. Typical risks encountered during a project's design and build stages include: organizational consolidations creating retention and morale problems; simultaneous rollout of multiple major initiatives; interruptions of day-to-day operations; and pressure to overcustomize systems and processes to fit current stovepipes.
The second step in managing organizational change is to mobilize and align the executive team and other management with the goal of creating a guiding coalition of leaders with a common vision. The leadership coalition must build foundational agreements on issues such as workforce alignment, reorganization and business direction that are critical to the project's success. The leadership must also act as champions for the project and articulate a case for change throughout the organization. Finally, the management team must actively enlist the help of project stakeholders in supporting the system from the start.

Speaking of engaging the project stakeholders, the next step (actually this should be done concurrently with step two) is to enlist the aid of stakeholders in championing and implementing the changes the new system will bring to the organization. To start, work with the user community to create the core message that change is necessary and beneficial. Try to build confidence, from the get-go, in the successful implementation and quality of the solution. Also, create feedback mechanisms that take the pulse of stakeholders concerning any issues that arise during implementation.

Part of engaging the stakeholder community includes preparing and equipping the workforce to handle the anticipated changes. This includes: identifying impacts to employees' roles; designing jobs for the new environment and determining organization changes; matching employees to new jobs and developing transition plans; equipping managers with tools to orient employees; and designing and delivering "just-in-time" training that really meets employee needs.

Finally, implement the changes. The implementation process begins by creating, merging or realigning organizational units based on new system requirements. Be especially careful during this phase to gain consensus on the realignment. Next, clearly articulate unit roles and responsibilities to both management and users. This includes defining accountabilities, interfaces and interdependencies, as well as actual positions and staffing levels. The final step, concurrent with system rollout, is to assign workers to their new responsibilities and train them appropriately – performing cross-training where feasible.

I cannot overemphasize how important it is to manage the organizational change that will take place – whether you want it to or not – with the implementation of a new IT system. How much, or simply how, you manage those changes will play a large part in determining the success or failure of your project. So, while you're refining your business requirements and your technical architecture, build and refine your change-management plan as well.

All information provided is of a general nature and is not intended to address the circumstances of any particular individual or entity. Although we endeavor to provide accurate and timely information, there can be no guarantee that such information is accurate as of the date it is received or that it will continue to be accurate in the future. No one should act upon such information without appropriate professional advice after a thorough examination of the particular situation. The views and opinions are those of the author and do not necessarily represent the views and opinions of BearingPoint, Inc.

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