When IT projects fail, it may be because the business community is reluctant to embrace change.
Many it projects fail not because the solution is not functioning, but simply because the business community does not use the solution as expected. Managing the users' attitudes toward change is often the missing link and the reason the anticipated ROI is not realized. Change management to address user adoption should be an important part of any project, especially when implementing new types of applications such as BI and CRM.
By year-end 1998, guided analysis functionality will become common for most BI applications (0.7 probability).
BI tools and components will be inexpensive, sold predominately through resellers, distributors and via "self service" over the Web. Vendors will likely offer only limited support and will rarely have a direct relationship with their customers. The BI mass market will emerge by 2000, with a majority of vendors failing due to lack of strong indirect distribution and an inability to sell in high volumes at low margins (0.6 probability).
These statements made sense to many business users and IT professionals when they were first made. The promises of the new business intelligence (BI) tools and the predictions about their future repercussions in daily business were certainly seducing, especially to IT users who struggled to obtain accurate reports in a timely manner. In those days, one company spent 32 man-days creating monthly reports that were sent to management. Luckily, they had a number of people working on these reports, albeit at high costs, or they would have been perpetually late to act on their information.
However, most forecasts about BI, just as the more recent ones about the predicted immediate impact of e-business and the death of the "old" economy, have not materialized. Guided analysis functionality is certainly up and coming, but not yet to the extent forecasted in the quotes at the beginning of this article. Most major BI providers today certainly sell via value-added resellers (VARs) and original equipment manufacturers (OEMs); however, these BI providers still tend to try to keep a strict control over their customer relationships. Also, because the technology still advances all the time, they can keep their margins high as there is no one type of BI that has become a commodity today.
Even though the technology may be mature enough, good or sometimes brilliant, the implemented solutions may - and do - nevertheless often fail in giving the expected return on investment (ROI). All the technical hurdles may have been overcome, including aspects such as database performance, complex user group administration, data quality issues and data security. The user demands, it is believed, have also been taken into account. The solution is launched and the project team expects success to follow.
To the big surprise of the project team, the business users complain - or, in the best of cases, they simply say nothing. It is concluded that they do not use the application to the expected extent. This is even more so the case for BI solutions than for IT systems supporting the operational activities.
What has been underestimated all too often is the change management aspect of the project planning. Change management is the aspect that will assure user acceptance of the new application and therefore is the first and imperative step to a positive ROI. It can be split in two integral parts:
- Business understanding that aims to understand the business users' needs, which is then fed back to the technical IT maintenance.
- The technical maintenance, which consists of the resources and actions needed to keep the system alive and is constantly adapted to the business users' needs.
The technical maintenance has been further described in my article, "The Vital BI Maintenance Process," published in the July 2004 issue of DM Review. The responsibility for the technical maintenance usually rests with the IT side, whereas the change manager needs to have the confidence of the business side while at the same time be able to communicate the business needs to the IT side. He or she must also be able to influence IT to plan so that that they are responsive to the change demands coming from the users. The change manager must also be able to convince the business users to use the new solution, preferably by showing that the changes stemming from the new system are beneficial to them.
The Change Manager's Position
What matters to the business users when they are deciding whether or not they are going to accept a solution basically depends on the benefits of working with it or the disadvantages of not working with it. A benefit may be that they become more productive, which may, as a consequence, increase their salary or bonus, or it may save them time and thereby allow them to do other things. A disadvantage may be that business users lose productivity compared to their colleagues who do use the new solution. For the change manager, the incentive is either the carrot or the stick, where obviously the carrot is strongly preferred.
In order to execute the change management, the change manager must be at the top of the project chart, next to the project manager. He must have the authority to influence the necessary changes demanded by the business community. The key to successful collaboration between the business user and the change manager, and therefore successful implementation, is to let the users drive the project. Therefore, their demands for improvements need to be taken seriously within a reasonable time frame. They are, after all, the ones that will use the solution. They are the key to a positive ROI.
Practically speaking, the change manager must have the authority to, for example, delay the launch of a solution if major data quality problems surface - a typical problem when implementing BI solutions. It is often difficult to regain the business users' confidence if the first version of an application contains too many problems. It may, therefore, be better to delay the launch in order to correct these faults.
As communication is an important part of any project implementation, including communication to all the potential business users, the change manager may also need to work closely with the company's communications division. Depending on the organization's routines, there may already be a standardized procedure for this kind of communication.
The Change Manager's Work
Change management starts when determining whether or not a new solution should be implemented. When discussing a new project, all the questions/answers should be communicated to all the future business users. The users should provide their input on whether they think it is necessary to take the resources needed for a new project. Some users should also be involved in the evaluation of new solutions.
Here, it is of major importance that the business users testing new solutions represent a cross-section of the average business users from different functional divisions. It is very dangerous to let only the power users evaluate new solutions, as they usually only represent a minority of the business community. Unfortunately, this is often the case as power users are considered "easy" users by project management (i.e., they understand quickly and will rarely have an overly negative attitude toward new technology). The very fact that they are power users indicates that they are positive to technology, having taken the time to learn it. If the business users considered as more "difficult" are involved from the start, there may be more work in the beginning in listening, understanding and convincing them, but there will be fewer change management hurdles to overcome once the solution has been launched.
Once the actual implementation starts, the business users (including some "difficult" ones as well) should be participating in different kinds of tests, such as performance (often a major topic for BI solutions containing ad hoc reporting), quality of the output (exactitude of the information) and usability (i.e., whether or not the user interface is comprehensible). Here, they will give their input on how they feel about the results. Explanations communicated via the change manager on why some test results may be difficult to improve are often necessary. Response times of 10 seconds for certain ad hoc queries, for example, may be acceptable to most users if clearly explained, even though their first instinct is usually to want response times of less than a second.
During these phases, all concerned users should be continually informed as to the progress. No user should feel that he or she has not been properly informed about the new solution once it is implemented. Any questions or hesitations from the user community must be addressed as quickly as possible.
Once the application has been launched, much work still remains to be done. Even if the new solution is, on paper, superior to what was before, the only thing that matters in the end is whether or not it is used. A positive ROI can only be derived from solutions that are used. The change manager should be involved directly with the users, see how they work and note all positive and negative reactions. Negative points should be discussed, and positive points should be further developed. These meetings between the business users and the change manager will also give useful feedback on further business needs. Workshops and seminars are also useful tools to determine how the business community feels about the new solution. It is important to note that the user community will only participate if they trust the change manager and feel that he or she listens to them by acting and following up on their comments. Also, many business users often need a gentle push to participate, as they may not automatically raise their concerns, even if they have something to say. Instead, they may simply go on working in different ways, often with what they had before.
It is often this follow up, after the implementation, that will make the difference between a successful application that provides a positive ROI and one that does not. This job is a combination of the change manager working with the business users to make sure that their reasonable demands are met by IT.
Change Management or Project Management - What's the Difference?
As much as we pretend to live in an ever-faster changing world, many people are still rather resistant to change. People are simply not very different today than they were 10, 20 or 30 years ago. The business users still do not want a complicated life. This certainly has even more of an impact when implementing new solutions such as BI and CRM than for most operational systems. As the number of power users is often quite limited compared to the total number of people that have a need for new applications, these solutions must have a clear business purpose and be easy to use.
As has been noted, early statements about BI, as is the case with many other new technologies, were often optimistic - even though they seemed believable at the time they were made. The implementation of many solutions is, however, rendered difficult because of a failure to convince the business community to use these applications efficiently. This is where change management comes in, aiming to ensure that the new solution is used and therefore fulfilling the minimum key demand toward a positive ROI.
The responsibility of the change manager may seem to be the same as that of the project manager to some extent. However, whereas the project manager has the overall responsibility for the project, including anything from funding to technical aspects, the aim for the change manager is to ensure that the implemented solution is actually used. This is a key to a positive ROI and thereby a justification for the project itself. In smaller projects, it may not be necessary to have a specifically designated change manager, as this could be an additional role for the project manager.
Today, many forecasts about BI revolve around having real-time BI in the very near future. Given that most companies with BI solutions are still stabilizing these systems in order to reach a more mature usage, these forecasts seem far too optimistic. Also, it should be asked where real-time BI is needed, as it may not be needed in all industries. On a strategic level, the notion of real-time BI may be very extraneous, as it will often not give any added value. Once again, if the technical hurdles are overcome for implementing real-time BI, as they will be, it should be asked why the business users should work with it. If this question is answered convincingly, only then can it succeed, given that the change management aspect is not underestimated before, during and after implementation. Simply put, regardless of the solution, change management is about convincing the users to use the solution, and the basis for positive change management is to make sure that the solution corresponds to users' needs.
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
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access