|
CRM implementations are challenging projects to manage because of their scope and complexity. This article focuses on two project management aspects, milestones and status reports, and a softer, but critical point: keeping in touch with the tool vendor.
Milestones
A key principle of project management is to use milestones rather than a linear schedule to manage projects. Milestones should be associated with deliverables so there is no ambiguity about whether they were met or not. Ask the technical staffers to ensure that any particularly difficult or risky subtask gets done early so that any obstacles can be worked around.
Following the precepts of rapid development, make each milestone a self-contained, working system, so that it can be touched, experienced, and tested by the user community. Having a working system at each step is an effective morale booster. It also allows catching and correcting problems early rather than waiting weeks and months for the opportunity to perform any testing. This limits risk.
Using tangible milestones has two more positive consequences. One is that they make schedule slips obvious. The other is that, being self-contained, they make it much easier to modify the project plan when needed. So if you know that you will miss the target date for milestone #4, you have a choice of either extending the deadline or simply making do with milestone #3 as the "final" deliverable. In other words, you have a modular system that gives you more flexibility.
Many project managers choose to use formal signoffs from the business owners on each project milestone. I have mixed feelings about it, since for me signatures can never replace trust and commitment. However, signoffs do clarify when agreement is reached and if they are a part of the organizational culture they should be used. Just don't expect signoffs to take the place of good lobbying and communication by the project manager.
Status Reports
Traditional weekly written status reports are helpful, but they usually fall short of presenting a complete and timely picture of what's really going on with the project. Putting it bluntly, a week is a very long time to wait if there is a problem (or a breakthrough). Written reports also tend to use non-committal language that obscures what's really going on while leaving out all the subtleties of face-to-face communication.
Therefore, I much prefer using short, daily status checks with representation from all the active teams (so the database guy doesn't need to attend if there's no database work being done at this moment, but the technical lead should attend and should know when to pull him in). Anyone who is able to attend in person should do so, and remote participants can participate on a conference call. Status checks are mandatory for all key team members. The project manager can prepare a short written summary for the team based on the daily check, but it's very important to keep that daily direct contact with the key team members. A regular time and venue for the meeting is best to ensure participation.
Short means that the status meetings should take less than an hour, and probably less than 30 minutes, at least if no large issue has emerged. Each team should present a quick highlight of what was accomplished today, an estimate of how they are doing compared to the planned schedule, and any significant issue encountered that day (or resolved that day!). It's critical that team members provide very frank reports on issues they encounter, as many failed projects are victims not so much of the technical and political issues that they encounter but rather of the lack of timely knowledge that decision makers have about the issues. By the time the decision makers realize what the problems are and have a chance to design a solution, so much time has passed that it's very difficult to avoid a negative outcome. Make sure that all news, especially bad news, travels fast.
The daily status checks are not designed to resolve all the issues they raise (although that's always nice if it's possible!) or even to get details on each subproject, but rather to spread information quickly and to keep everyone on their toes. In addition to the daily status meetings, the project manager must also proactively perform detailed status checks with each subteam and ensure that issues are appropriately handled.
There are "quiet" times in a project where daily meetings would be too much, for instance during the coding period. The project manager should feel free to decrease the frequency of status meetings during those times. But daily meetings are required as you get closer to deployment.
In addition to the daily checks, longer, more detailed status meetings should be held as each milestone is reached. Here again I prefer a meeting format to a written status report so you can get more information (and you can always write minutes if you like the formality of written reports). Face-to-face milestone meetings are much more effective than conference calls so try to get at least the key players to be physically present together.
Keeping the Tool Vendor in the Loop
If the tool vendor is serving as the integrator, you will naturally keep in close touch with the vendor through the implementation team, so this is really an issue only if you are using a third-party integrator.
It's very wise to keep the vendor in the loop during the implementation. You may well need specific assistance to fix bugs, resolve problems that are beyond the scope of the integrator, or provide audit services when you want to double-check advice or an opinion given by the integrator. The project manager should provide regular status reports to the vendor regardless of what's happening, good or bad, on the project. In addition, invite the sales person (or the technical sales specialist) and the regional services director to milestone meetings.
It's also useful to start establishing good relationships with the support organization as bugs are reported. It's much easier to get prompt and cheerful assistance in a crisis if a solid relationship has been established in happier times. | 
Disclaimer
