In this new video we discuss project management software adoption practices, trying to find patterns of success and failure, drawn from our experience.
I’ve been helping companies adopting project management software for almost 10 years, both online and by on site consulting. Sometimes the adoption process succeeded, sometimes it didn’t, and in time I’ve been noticing patterns, which I’ll try to share.
While I’ve been proposing a specific software tool, most of the time success or failure does not depend crucially on the tool, but on people’s attitudes. Many of these observations could work for a group that decides to use a shared Excel file or a physical board, the simplest possible project management solutions.
All my points are about how to introduce a tool in such a way to get people to have working objectives more in order. Often tool introduction generate instead a yet-more-control with less recognition feeling.
Now I’ll present some failure patterns, then some success patterns, and we’ll end with a list of short tips. We’ll be visually helped by an infographic which you can view online and download.
“Users don’t use it.”
In my experience the first cause of project management software adoption failure is not the discovery that the solution chosen does not do this or that, but is the fact that “users don’t use it”. Managers have to acknowledge that: “after a while people simply don’t use the solution”.
This is danger number one. How to avoid this? The best way is to ask from the start: “Is it realistic that everyone I want to use the solution will actually use this solution? Is it simple enough? Is it fast enough? Are there visible advantages?”.
“We’ll start when everything is in place.”
“Users don’t use it” is a posteriori failure, but sometimes failure starts before the solution is adopted, when the idea is: “We’ll start when everything is in place”, which most often means “We’ll never start.”.
“Partial data is useless.”
“We need everyone, always to use this. Partial data is useless”. It’s a case of superstitious belief in complete data coverage, which is a debatable concept. But actually partial data is way better than no data.
“Software replaces management.”
“It will be the software doing the monitoring for us”; this is the belief that software replaces management.
“Let’s migrate current methods to the new system.”
“Let’s insert all of [MS project files data] [Excel data] [put here any other tool] data in the new tool and start from that”, which implies that bad habits forced by in time by old tools get projected on the new system, which will be surely “unsatisfactory”. Here the greatest opportunity is missed, the one for reform. Introducing new tools is an opportunity for reform. This reaction is a combination of “fear of changes” and “not ready now” syndrome.
Another mistake is to think about what the new tool may do for the company before thinking about “How much can I ask my fellow workers? How not to make it feel as a burden?”. Start small, start simple, pick a leading team, and then again and again I’ve seen the users come to the guy who introduced the tool and ask for more.
Present the new tool differently to different people
Present the centralized formalization of working practices differently to different groups. The way you present the software to IT is different from how you present it to agents. Ask different things and present different advantages to different people. You need information from everyone, how you get is not that important.
A moment of change
Introducing new solutions is an opportunity for discussions and not for impositions. It is an opportunity for reforming practices where it is possible. Not being asked for opinions is one of the main causes of dissatisfaction at work.
Quality helps everyone
Make it clear that improving quality of work will help everyone, in different ways.
How Project management was smoothly adopted in a bank: smile and say yes
In cases where the introduction of new IT services is complex, and has to go through committees, I’ve seen more subtle tactics be used, for example in banks. In one case when the adoption committee met, the manager responsible for the project management solution adoption actually said yes to the requirements of all departments, which were complex and even conflicting.
But actually he didn’t enter in any of the micro management requirements, and introduced an overall simplified project management practice that was lead by a small group that started immediately, which was then joined by other and finally by all groups across the bank, and in the end this was a great success.
After a few months, we integrated the solution with more features, and after a year yet more.
How a solution was smoothly adopted in another bank: don’t integrate
Another bank manager, again a committee with loads of requirements, he just used an online service, didn’t get in any integration mess, lead a small motivated group, again a cross company success.
Get IT on your side when they are in
Try to get the IT guys on your side: they appreciate new solutions, even though it may not look so.
1. Start with a small group.
2. Start simple.
3. Put good data from the start.
4. Some information is better than no information.
5. Complete system integration may never happen.
6. Don’t delay waiting for [any requirement here].
7. Reject bizarre ideas from a single user / be practical.
P.S. If it’s the CEO (as most often is) say yes but on further enquiry its “yes but not just now”.
8. Don’t be mislead by developers / technical details.
9. Listen to women.
Tip. Its way more unlikely for women to be mislead by technology / wild unfeasible dreams: they seem to have “built in” a more realistic picture of human beings.
10. It’s more a question of people than a question of technology.
Tip. You could start very very simple, like use a physical space to model your ideas.