How to Manage Business User Expectations and Lack of Knowledge During a New System Implementation

Managing User Expectations while implementing a new system is a key challenge for a successful project implementation.

Have you been at a client where they have purchased a new system or application and do not have the expertise or knowledge to implement it?  Or there are very few people who truly appreciate the nuances and the functionality of the system?  For such a client to be fully comfortable with using the system, they need to understand not only what it does but how it does it.

It is a whole different game when the system has been developed in-house and there is a complete body of knowledge of how it was done and why.  The very exercise of going through the requirements analysis, design and development would have created in-house experts.  Since the business users have given the specifications, and the product has been customized, they know what the system does.
How to Manage Business User Expectations and Lack of Knowledge During a New System Implementation Click To Tweet However, when the system is a purchased one and has to be implemented, then the whole scenario is different.  There is surely savings from the money and time saved in developing while getting the best-of-breed software, but there is a learning curve as well for both IT and business.

This creates a whole debate about how much of Customization should be done on any system that has been purchased off-the-shelf.  After all, if you customize it a bit too much, then when upgrades come in there will be massive issues.  Unless you are the vendors top three or five customers, they will not cater to your particular needs.

In such a scenario, it is tricky to work with the business users and ensure that they are on board with the implementation.  For this, they need to know what is being done and why.

The knowledge gap between the project team and the business users can create major issues in the delivery of the project as a whole.  Here are some of the issues that one should anticipate:

Issues due to Project team and Business users knowledge gap

1. Without going through detailed requirements and specification sessions, it is difficult for business users to accept that their requirements will be or have been met.
2. It is difficult to achieve a meaningful “sign off” on requirements without the type of full and detailed requirements document we produce for homegrown or customized systems.
3. Business users are uncomfortable with “not knowing how it works”. This can evolve into lack of confidence that system will work.
4. Business users’ discomfort with their knowledge of the system can lead to heavy time demands on the project team for information on “how does the system do this”. This can impact development process – the project team spends time researching questions on delivered functionality rather than focusing on configuration, testing, interfaces, environmental issues, and other project development tasks.
5. It is very difficult for users to anticipate and communicate the potential change management impacts to the enterprise clients when they do not themselves have a detailed and in-depth understanding of all aspects of the new system.
6. When learning how the system works is delayed too long, there is a detrimental impact on other project tasks. During User Acceptance Testing should include: 1) learn the system thoroughly; and 2) test the system.
7. With a purchased package, there will always be delivered functionality that is not applicable to your use of the system – without a good understanding of the system, it is hard to know what functionality/data/information is needed for and what doesn’t apply.
8. Potentially steps taken to address this challenge might erode the dollar savings provided by using third-party packages.

The ways to mitigate these issues that occur from the knowledge gap include:

Possible Mitigations:

Conference Room Pilots (CRPs) – In an attempt to mitigate this issue for this project, conference room pilots can be conducted to allow the users to see different scenarios within the 3rd party software.

it is imperative that these CRP demos are not mere stand-up demos but also have some hands-on “get to know” the system sessions for the users to get a better understanding of the system. Of course, the demo touches upon the high-level scenarios and not some detailed functionality.

Formal Documentation of all Systems Requirements with Sign-off – During the analysis phase, the project team needs to align the package functionality with business requirements, translate that into technical specs and design documents and present them to the users for their sign-off.

Provided Package Training for Business Users and Super-Users – When the software is new and not enough knowledge is available in-house within the business teams, it is important to provide them training.  Most of the business users can be trained by the project IT team and some – who will be designated Super Users – will need extensive and in-depth training.

Utilize Vendor Supplied Online Learning Resources – There are a lot of options when it comes to training for packages.  There is official training and also training in specific areas by some boutique firms and consulting companies.  The team should look at the best options available and use them.

Use the Dedicated Project Room approach (Colocation) – Put the business users and IT project team members in a project room together for training/familiarization with the system. This could foster more questions/answers and hands-on learning. In addition, users from each of the areas could be introduced to processes done by other areas and gain a better understanding of the overall process. You could even go so far as to switch roles between the different areas, The project room approach can be taken even beyond training and can be used for more, most or even all of the duration of the project. Difficulties include space availability and non-project responsibilities of the team members. However, where it has been possible to use this approach it has often been very useful.

Make Configured System Available to End Clients Earlier – Another approach to developing better systems understanding might be to release the system to users as a sandbox after the basic configuration changes are complete but prior to wrapping up the full requirements stage. The clients should be allowed ample time to experiment with various scenarios. With the training, time on sand-box helps the users get a better handle on the articulation of their requirements.

Managing the expectations and requirements of the business users while delivering the project is always challenging.  Change Management and proper IT knowledge transfer mechanisms are necessary, despite all that has been done to involve the business users in the implementation.