Last week I had the pleasure of participating in a webinar with our friends at the Pittsburg Water & Sewer Authority. We received several questions during the webinar around the adoption of a new system. How do you ensure that everyone is using the system? Were there certain groups who took longer to adopt than others? How long did it take?
It’s a topic we often get asked about, given that e-Builder Enterprise project management software is a system used for collaboration on complex projects where there may be dozens of users spread across different organizations. At the end of the day, it’s all about adoption! You can set up a system that looks great and is easy to use, and performs your business functions exactly to your specifications, but, if no one uses it, you won’t realize 1 cent of your investment.
For many of our customers, adoption seems to come naturally and end users transition to a new way of doing things without too much difficulty, but that's not always the case. And while every software project and customer is unique, we’d like to share a few ideas we’ve picked up after doing hundreds of e-Builder implementations over the past 20 years.
1. Set the vision
Leadership is the single most important aspect of any adoption initiative. The project’s executive leadership not only needs to explain the whys of moving to a new system, but is responsible for painting a picture of the “new future” that everyone can believe in. During the project kickoff, when the system is first introduced to the broad audience of future users, I like to ask the highest-level team member (the “boss” or even the “big boss” – you know who they are) to set this vision.
It’s important to give examples the team can relate to:
“….imagine if you didn’t have to go rummaging through your file cabinet every time someone asked a question about a project that closed 6 months ago.”
“….imagine if you could know exactly how much you had committed on a project without having to call someone in accounting.”
Your vision can be a single example or image, or a series of these that give a general sense to the audience. Focus on the reasons you bought the system in the first place, but make sure to state these vision points from the perspective of the end user. Most business reasons for investing in a system can be reiterated as a benefit statement for the user base.
Send the message that the initiative is important, necessary and needs to be accomplished quickly. Whatever the vision, refer back to it throughout the project as a way to keep everyone aligned to the ultimate goal.
2. Create your adoption plan, KPIs and schedule regular status meetings
For the first few months after you’ve deployed a new system, you need to meet regularly to go over its usage, even if it’s only with the “internal” users at your own organization. Ideally, this would be a stand-alone meeting, but it can be done as part of an already-scheduled weekly team meeting, provided you allow enough time.
Even for larger implementations, I would recommend no more than 4-5 main KPIs for adoption tracking. Some examples are: number of users logging in at least once per day, average number of logins per week, number of documents uploaded, number of RFIs submitted per week, or percentage of our total active projects now live in the system. The important point is that you need to be able to look at these numbers by project or by project team, so you can hold everyone accountable for meeting the goals.
It’s not uncommon for the team to miss the first couple of adoption goals. That’s okay – keep the energy levels up and don’t give up. Sometimes it helps to focus on a single objective – “next week, we want every PM to log in, review and update their project status for each project they’re on – can you commit to that?”
Adoption is all about momentum – try to build that critical mass that’s going to get most of the organization moving in the right direction. It can often feel like you’re making little headway before a big momentum swing happens.
3. Appoint a project adoption officer
Think of how a political party operates – they appoint a “chief whip” to make sure members are doing what the party wants them to. A project adoption officer can fulfill a similar function. This should be someone senior who is diplomatic, commands respect, has tenure, but NOT the boss or big boss and NOT the system administrator. A seasoned project manager, inspector or engineer who “gets” the need for a system and wants to see the organization succeed would be a good candidate.
This person reviews the agreed-upon KPIs during status meetings and follows up with individuals who are out of compliance. Often a quick word, one-on-one, is enough to bring someone around.
The project adoption officer shouldn’t be an afterthought. Make sure you create enough time for him/her to do the job successfully – it makes sense to invest in this critical phase of the project. The project adoption officer should report back on adoption status to the project stakeholders regularly.
4. Make tweaks and updates sparingly
Often our tendency – particularly in the project management world – is to “fix” things, and quickly. So, we identify problems, document them, and then come up with an action plan to resolve the issues. That’s great – the system or process may need some tweaks and you want that detailed feedback from your users. But, a word of caution – don’t make tweaks too often or too soon. Unless there’s a real show-stopper, I’d let the system operate as is for a few weeks or months and spend that time gathering ideas for possible improvements. Once it’s time, prioritize the feedback, decide what changes you want to implement, communicate why and then roll them out as a group.
Once your organization gets more comfortable with the system, you can roll updates out more quickly, but beware of deviating too much from your baseline implementation in the beginning.
5. Focus on your early adopters and promoters
Adoption meetings often focus on these “issues” that need attention. Don’t forget the positive! If an individual or project team is getting in and using the system to its fullest – praise and reward them. Have them show off what they’re doing in the system. Ask your users for creative ideas on how else the system could be used to benefit the organization. You might be surprised! You don’t have to do anything with these ideas right away, but discussing things like this is a good way to avoid getting bogged down too much during adoption meetings.
Keep an eye out during regular working hours for “wins” – stories of how someone was able to find something quickly, communicate status easily, and so on – and share these stories in your meetings.
6. Plan for additional training as needed
When it comes to training, you can rely solely on the software vendor, or go for the train-the-trainer approach and have at least some of you training skills in-house. One advantage of doing it in-house is that it’s easier to set up ad-hoc training that may come up in an adoption meeting. Make sure your users know who to call for product support. Another idea I’ve seen implemented successfully are lunch sessions (bring your own or catered) where a system administrator or e-Builder expert offers to show a specific piece of functionality (e.g. how to build reports) and hold a Q & A session.
Adoption isn’t always easy – in some cases, it can seem more challenging than designing and configuring the system in the first place. Don’t ignore it – plan for it and track its success using the tips above. You’ve invested in the system, spent time defining your requirements, signed off on documentation, tested the setup and organized training for everyone. Approach adoption as another critical phase and get the project over the goal line.
Lastly, hold your software vendor accountable! A good software implementer understands the importance of this phase to the long-term relationship between the parties and will guide you through the process.