4 Questions to Answer Before Presenting Project Management Software
We have covered a lot of ground in this blog about how to implement software, best practices, even how to select it. One thing that we have not covered much is how to get buy-in from other people to implement project management software tools. This can be hard to do for several reasons:
- People do not like to change.
- No one wants to take on another effort.
- People are too busy fighting fires, much less trying to address the root causes of the fires.
- People think what they are doing is just fine.
Just this morning I read a blog post by Ted Hardy at the Better Projects blog. In his post, Ted walked through how he brought an idea to his team and achieved their quick buy-in. I want to expand on Ted's post and give you four questions that you need to answer before presenting project management software to your organization.
What's the problem?
If you are going to implement project management software because it sounds like a good idea, don't bother. It has to be tied to a problem. What problem will it solve? How will it provide value? Ted's value proposition was that his idea would provide data that they didn't have today in order to solve quality problems. The problem should be your focus and will drive how you present it as well as how it is implemented. Perhaps you have projects that are continuously late and no one knows why. Perhaps you are making promises to your customers that cannot be kept, because no one has the data to say when something will actually get done. Perhaps you know you have resource bottlenecks but have no data to prove it or to show where, how, and why the bottle-necks are occurring. Perhaps you have documents or other information strung all over the place in spreadsheets, whiteboards, files, and post-it notes so no one can find key information when they need it most. These would be examples of real, definable problems on which you can focus your "pitch". If you have a solution that can solve a real problem, that is a real value-add. And that is much easier to present than a vague benefit.
What's the process?
Do not focus on the project management software tool itself and its "cool features". Focus on your process. The software is simply a tool to implement, run, analyze, and improve your process. When you present this, you don't even need to focus on "implementing a project management software tool". You can focus on implementing a process (and using a tool to help you do that). The software can and should take a backstage approach. If there is too much focus on the software tool itself, than there is not enough focus on the process and the underlying problem. So what is the process that can be implemented (or changed) to fix problem x (defined above)?
What's in it for them?
Why should people do this? What will they personally get out of it? Perhaps it is some key reporting to save them from doing hours of manual data manipulation. Perhaps it is to remove a headache that plagues them day in and day out. Put yourself in their shoes and be sure you understand and can articulate how they will specifically benefit. You could mock up some sample reports to show people (be sure they will realistically be available), and even quietly get feedback on them before even expressing your idea ("do you think it would be helpful if you could get information like this?"). Go to lunch with people and explore what problems they have and what would be a real benefit to them.
How will you implement?
Do you know what steps you will take? Will you phase it in or try and do everything at once (phasing it in is highly recommended)? Will you have a pilot group? Who will be in that group? What processes will you implement at first? What will they look like? What problem will they solve immediately? What will people be able to get out of the tool right away that will help them? How long will it take? How much time will it take from people's day? These are all questions that you need to answer before making your presentation.
The bottom line? Be prepared. In Ted's post, he had an idea for something that would really help the team and the organization. He did his homework and explored the idea and what it would take. But even then he didn't present it. He let it ruminate for a while which gave him time to think it through and thoroughly understand his approach before presenting it to the team. It worked and unless you are dealing with a dire situation that requires an immediate solution, it's a good approach.