During my time at TECHNIA (previously TechniaTranscat) I have been involved in a lot of different projects, from small technical upgrades to huge multi-million Euro projects. I have worked both in projects where we on Go Live-day left the office early because no one called the helpdesk, to projects where … well, let’s just say we stayed a bit longer.
Every project is unique. But what are the differences in projects where we could take an early dinner at a nice restaurant to celebrate and the ones including greasy take away pizza in front of a computer screen? Here are some of my thoughts collected during the years.
1. User Involvement
You cannot involve real users too often. The more real users (which are our actual customers) see their product and get to know it, the better ambassadors they will be. Try to set up user tests at least once per quarter – and make sure that some of the feedback received at these sessions are addressed and shown on the next user test.
2. Sprint Demos
Is your project using SCRUM or any other Agile method? Do you conduct Sprint Demos? Make sure as many as possible from the user community joins. It will make their (and your) work easier if they have seen all features and functions before they actually start using the system. Record the sprint demos (it isn’t that difficult, especially if you are using Webex) and distribute to the whole community.
3. Start Immediately
As soon as you have something to show, show it to real users and not only to the project team and stakeholders. The sooner you get feedback, the bigger the chances are that you will find time to do adjustments.
Are all users going to do the exact same work or do you have different users in the system? Make sure that all different user categories are invited to the user reference tests.
5. Classroom Training for Everyone?
How will you train the users? If the user community is really huge, classroom training might not be a realistic idea. Classroom training for some key users at each department and lectures for the rest might be a better idea. But from my experience, hands-on training is far more effective if you want to have satisfied and well-trained users.
E-learning can be a powerful way to teach many users for a small cost per user. Make sure you use a tool where you can do follow up on usage and conduct tests.
7. On D-day, Be Prepared
You have planned the release for months, make sure you plan for some extra resources during the first week(s) after deployment. If the users don’t get attention as soon as possible in the beginning, there is a risk that they will start complaining to their co-workers. Sooner than you think your project will be trash-talked in the corridors, just because you didn’t have an extra couple of resources helping the users on their first day with their new application.
Hopefully you will, if you follow my advice, have time to eat a decent dinner instead of pizza at the office on the day of the rollout. If you have come as far as the rollout, you definitely deserve something other than unappetizing fast food!
Do you agree with Adam? What are your experiences from your PLM implementation projects? Please leave a comment or share this blog post with colleagues and friends!