4 Comments

Summary:

When your organization moves between project management systems, there are a lot of potential hiccups that can occur. Dedicating some thought to the process can make these problems more manageable. Even if you’re moving between two compatible systems, it’s important to keep these questions in mind:

When your organization moves from one project management system to another, there are a lot of potential hiccups that can occur. If you can dedicate some time and thought to the process beforehand, though, those problems may be more manageable. Even if you’re proposing a move between two compatible systems, it’s important to keep these questions in mind:

  1. How necessary is this move? If you’ve reached the point that your organization is changing tools, it’s likely that the move is necessary, but it’s worth going over the ground one more time. There are some teams that will switch tools just to stay on the bleeding edge of technology, which can create more chaos in group projects than is absolutely necessary.
  2. Is your team trained for the new tools? Training as you go may seem like a practical option before you actually make the switch, but it will mean slowing down on all your projects as your team goes through the learning curve. Depending on the system, it is possible that something important could get lost in the shuffle. Setting up at least a minimal training schedule can make an important difference in how fast your team gets up to speed.
  3. Is it possible to phase in the new system? While moving everyone over to a new system at once avoids some problems, like having to maintain legacy systems. However, it does mean that projects that may be progressing nicely will have to stop, switch systems and then try to build up some momentum again.
  4. How will your data be transitioned? Your current data needs to be moved from one system to the other. If there isn’t a technical solution, that could mean retyping everything about a project in the new system. That can be another argument in favor of phasing out an old system, rather than making an immediate leap.
  5. How will access be set up? With the advent of web-based applications, concerns over whether a user’s computer will run a given piece of software have become less important. But the question of rolling out access should still be considered. After all, someone may need to sit down and set up accounts for an entire organization in one go. Having a plan in place for setting up access is easy to overlook.

Photo by Flickr user Karl Sinfield, licensed under CC 2.0

Related content from GigaOM Pro (sub. req.):

  1. With 5pm we found out that usually there is a person who has the plan. He/she decides the data structure on the new PM software – not all products are the same. Some things may go away, some may be done the different way. So often there is a level of data restructure. And one person, or a team, should plan it BEFORE moving any data.

    The good part is that it usually leads to reviewing old practices/structures and improving them. Usually there is never enough time for that – and moving to a new PM software is usually a perfect time for a good cleanup.

    -5pm Team http://www.5pmweb.com
    get more done by 5pm!

    Share
  2. I think the most important question is a little more subtle:

    What does your project management process look like?

    Most people start looking at systems or consider changing systems based on what they *think* the system will do for them. They don’t realize that pencil & paper or the shiniest tool out there don’t make a difference if there’s not a clear vision on how the tools will be used, a commitment to stick with it, and the willingness to grow and adapt appropriately.

    Share
  3. Related to this, there’s a post on the LiquidPlanner blog about what to avoid when implementing PM software. That can be a helpful companion to this post.

    http://www.liquidplanner.com/blog/2010/7/8/top-10-pitfalls-to-avoid-when-implementing-project-managemen.html

    Share
  4. Interesting post – and a neat, brief summary. To my mind, however, the biggest question that needs to be asked is the impact that will be had on the project management approach adopted by the business.

    Project teams who use a highly disciplined approach like PRINCE 2 may find that using a light, more agile-friendly tool might give them a nice interface, but robs them of the formality their approach requires. On the flip side, an Agile team could find systems that require a rigid set up of permissions and documents could slow them down.

    If an approach change is to come, then in addition to ensuring the team know how to use the tools a change programme would be required to help the team transition to whatever approach the tool will bring.

    Share

Comments have been disabled for this post