A Tale of Two Companies - The Value of Planning and Training

It was the best of times, it was the worst of times, two completely separate companies had finally decided to abandon using desktop applications like MS Project and Excel to manage project schedules and resources. Their challenges were similar. Sharing project schedules by emailing MS Project files around was confusing and time consuming, as team members were never sure which version was the most recent one. Project managers were tired of running around asking team members for updates. They had been reduced to glorified administrators, instead of career project leaders. Executives were frustrated by not having visibility into the overall portfolio of projects.

Something had to change! However, the manner in which these two teams went about acquiring and implementing the same project management software solution (yes, Project Insight), was radically different, as was the end result.

Let's uncover the different approaches to each stage of the process by telling the stories of these two organizations.  We'll start with requirements gathering and definition.

Company A decided to gather requirements for their project management system among a few key players on the team.  While they had the blessing of the CEO, he declined to participate in the exercise.

Company B, on the other hand, decided to survey all team members impacted by the implementation of a new project management software tool. They conducted a formal survey among all stakeholders, not just executive sponsors, but also the individuals that would be asked to update the project tasks and activities.

The survey queried each project resource about his or her view of the organization's project management challenges. As the survey was anonymous, people felt free to express their opinions with candor. The team compiled the survey results and shared them with all participants.

From this initial research, both companies moved to the requirements definition stage.

The project evaluation team at Company A sat down, had a quick meeting, agreed to the basic requirements, and then started calling vendors.

Company B evaluated the feedback from the survey and created a comprehensive requirements list, ranking their requirements in priority. It was not a complicated prioritization, simply the number 1 for mission critical, 2 for important, and 3 for nice to have. They shared this list with the team again and asked for buy in, keeping in mind that one may have to give up a couple of features here and there. They developed a consensus for the requirements list.

Only then did they start calling vendors.

Company A and Company B both conducted a Google search for project management software and web-based project management software. They visited websites, did product tours, called vendors, and watched presentations. At this stage, both organizations conducted thorough research.

One key difference is that because Company A's requirements list was only informally created and verbal, they spent more time with vendors that did not really fit their needs. Company B was able to narrow the list of project management software vendors that they needed presentations from down to 3, instead of 8.

Both companies' evaluation teams trialed their short list of products. Company A and Company B both spent a fair amount of time assessing the different project software solutions. Again Company B was able to direct the trial better as they had their formal requirements list to compare the product's features against.

Since this is my story, based on two real Project Insight customers, you need to know that both organizations selected our online software. Yet, each customer had unique results.

Company A decided to assign a junior project manager to the job of conducting this important organizational initiative. The CEO had given his blessing by informing the team that, yes, they had just selected a project solution and yes, it would be implemented by their least experienced project manager. The CEO did not lead by example, so he never attended any training sessions, nor did he develop any program to incentivize the team to participate.

Company A's junior project manager attended four hours of product training and was mandated to get all existing projects into the online project software, single handedly, within a week. Miraculously, and with our help, she achieved this goal.

Company B asked us about our successful customers. What did the most successful customers do to implement the project, resource and collaboration solution? We provided them with some of our best case and worse case scenarios. Based on the size of their team and what they were trying to accomplish, we advised them on the number of days of training and outlined some homework for them to perform.

Company B opted for 5 days of onsite business process consulting and product training, to be taken in two separate visits. Before the first visit, the team was to document their business process and email the Word document to our business process consultant and implementation expert ahead of time. In this way, our resource was prepared prior to the first visit. When he arrived, he interviewed the team members and asked a lot of questions.

After two days onsite, he returned to the office and wrote up his recommendations for how this particular team should roll out the project software. As with any solution, there are multiple ways to achieve goals. Armed with the knowledge of our solution AND the customer's process, he was able to define best practices so they did not waste time figuring it out on their own.

This set of best practices and ‘how to' documents was sent back to the customer for review. They asked questions, made changes and emailed it back. By the second onsite visit, our product trainer knew exactly what features to focus on and how to train this project team.

Back at Company A, the junior project manager was trying to train people, one by one, when time permitted. Without true executive sponsorship and no consequences to the team members that did not cooperate, the implementation floundered.

Company A had no communication plan, or way to handle project team resources' issues as they arose. In short order, the junior project manager had to respond to a lot of email training questions that would have been pre-empted with a more thoughtful training roll out.

Company B communicated very clearly that this initiative was of utmost importance and that everyone needed to attend the required training sessions. What's more, the executives decided to incentivize the team by putting the successful implementation of the project management software tool into everyone's performance review objectives. A specific timeline was also provided - by year end. This created a sense of urgency that was lacking over at Company A.

Company A started to hear feedback that people did not want to click a mouse three times to enter time. The junior project manager, with no authority over these team members, had to listen to folks whine and complain. All the while, she suspected the ‘squeakiest wheels' were the project team members that were doing the least and did not want to be ‘found out.'

Back at Company B, the teams were meeting weekly to go over their questions and issues. Then they would meet with our team to go over their questions and issues. We did this over the course of the first three months of their roll out. Week after week, the list got shorter and shorter and the team settled into utilizing the software.

After six months, each project organization has had very different results. Company A, realizing that they did not have the right executive leadership on the implementation is now in the throes of a re-implementation. They are facing some big challenges with the handful of resisters. It will be more of an uphill battle than if they had invested a bit more time and energy at the outset.

Meanwhile, Company B is a ‘poster child' for a nearly perfect project management software implementation. While they spent more time initially getting up and running, their planning paid off. Also, while they spent far more on initial business process, best practices consulting, and product training, they allowed the software experts to guide their implementation and thus saved time and money in the long run.

The moral of this story - there is a lot of value in taking time to plan for any implementation as well as investing in customized training during any software implementation.

More related links:
5 Mistakes of Project Management Software Implementations
Leadership and Training