My colleague, Duncan Klett, recently wrote the blog titled “Six lessons learned from six failed software implementations.” I completely agree with his lessons learned and recommendations, but I have many of my own!  I want to outline two lessons learned from many software implementations that are currently near and dear to my heart.

Reporting…

So many times I work with clients who are scoping out implementation projects and begin asking users what they think they need for reports from the system. The more people who are asked, the more reports make it on the list. Those reports then begin to take on a life of their own. They become a huge wish list of everything users have always wanted.  When it comes time to prototype the reports more light bulbs come on about all the possible reporting capabilities.  This is very exciting! (Unless of course you want your project to be completed on-time or on-budget). Even if the project does end up going live with all the great reports (that will solve world hunger and allow users not to actually have to do any work) low and behold the users determine shortly after go live they want to change all the reports. Why would they want to change all the reports, you ask? Well, because they now actually understand how the system really works and they see the actual production data in the reports so they understand it better; then comes the enhancement phase of the project.  The enhancement list becomes very long and sometimes costly.

Recommendation: I typically try to encourage clients to keep the list of reports to almost nothing, just regulatory, or reports that are required to run business. And even then, don’t involve a wide group of users, but rather stick with true decision makers. Once the system goes live, do a true reporting project to capture and identify all reports. Have a reporting strategy for the life of the system which allows for users to request new reports or enhancements to existing ones. Have a review board to ensure the requests are valid. Review the reports annually or bi-annually to determine usage of reports and anything not used in the last six months get rid of it.  This may seem like basic advice, but why don’t we all follow it? How do you handle reporting during a project?  Do you have any other advice to share?

Super Users…

We’ve all heard the term Superuser.  Wikipedia defines the term as: “The ‘Superuser’ in enterprise programs (SAP, Oracle) often refers to an individual who is an expert in a module or process within the enterprise system.” I think that is a pretty good definition – Each client I work with discusses having Superusers, however not all client’s actually put a name(s) to that title before a project begins. This could mean failure! If the company cannot define who the Superuser will be in particular business process areas during the implementation then who will actually help define what needs to be implemented, and better yet know what is actually implemented at go live? Post go-live is a nightmare of support because no one actually knows how to use the system and client is reliant upon consultants to teach them; which is both costly and inefficient.

Recommendation: Encourage clients to assign a Superuser(s) to a project before the project starts. That Superuser(s) works hand in hand with the consultants and is preferably dedicated to the project. The Superuser would even do some of the development of the system while the consultant oversees. How better to truly learn and adopt the system that “doing it yourself”? That person should also be the ultimate decision maker as it relates to scope and design of system or be the ONE conduit to that ultimate decision maker. By doing this the client should feel ownership of the system and feel it is “theirs” as there is at least one person who lives and breathes the system.  What experience have you had with Super Users on projects, either positive or negative?  Do you have any other advice to share?

TrackBack • Digg This • Add to del.icio.us
Tags: deployment time, Implementation, SCM, Supply chain management
Posted in Best practices
You can leave a response, or trackback from your own site.