Step 2: Restructure


If the project is worth salvaging, you must create a revised project plan, making changes as suggested in the assessment. You may have identified multiple problems during the assessment, and if so you will need a multi-prong approach. For simplicity's sake, I'll comment on each type of problem and its recommended approach individually.

If you identified problems with people on the project team, you need to decide whether to replace individuals or to apply some motivational pressure. Replacing team members creates significant delays, as new members need to get up to speed on the project itself and also in terms of teamwork. Therefore, replacements are only worthwhile if performance management efforts are unlikely to be successful, but it's sometimes necessary.

If the problem lies within the integrator's team, consider switching integrators altogether, even if the problems exist only with certain individuals on the team. This is because the integrator should have an experienced team leader on the job, someone who should have caught and corrected the issue before it got to the point of declaring the project a failure. Having gotten to a failure point, you need to consider that the team leader is not doing his or her job. Moreover, if you made the appropriate amount of noise with the integrator's management before declaring failure, the situation should have been handled through normal processes much earlier. Professional services managers for tool vendors can all cite instances of badly -failing projects that were dumped in their lap after the original (third-party) integrator was found to be lacking and that went on to be deployed successfully and fairly uneventfully.

You may have to replace individuals on your own team, although you can and probably will want to exercise more flexibility with internal players. If the people problems are with the super-users , find replacements. The business owners cannot normally be replaced so instead see whether the executive sponsor can exercise some muscle until appropriate cooperation is shown.

If you identified process problems for the project itself, first consider whether the issues are related to people weaknesses, and in particular to the project manager. This is because a good project manager should identify process issues quickly and get them resolved before the project comes to a halt. The project manager is not the only target, however; the issues may lie with the users if they are changing the requirements mid-way through the project. Only after identifying and resolving any people issues masquerading as process problems can you have a clear picture of the pure project process issues, and you can then restart the project at the appropriate point with a new strategy. This may require going all the way back to the requirements definition if the problems started there, but going back to the last solid code deliverable should suffice if process problems affect only the latest slice of work.

If the project issues are business process issues, not project process issues, then you need to rethink the entire project. Because most of the decisions for the project are determined by the business processes being automated, you need to go all the way back to the project requirements and to revalidate the tool choice based on the new processes. There's a pretty good chance that the tool will be able to support the new processes, but if not you will have to go all the way back to selecting a new tool. Assuming that you get lucky and the tool can support the new processes, hold a new kickoff workshop. It won't be as long and involved as the initial one since the technical environment of the project should not have changed much, so only the business side needs significant work.

Address any critical tool problems with the vendor, making sure to establish clear deadlines and milestones. Put the project on hold while the issues are resolved, but keep in very close contact with the vendor to ensure that the schedule is indeed being met. I remember a project that had to wait for two months for a fix to address a critical performance issue (it was a memory leak) and that proceeded to a successful rollout, albeit significantly delayed.

As you craft a new project plan, seriously consider simplifying the project down to its critical components . Few CRM projects fail because their scope is too restricted (I can think of only one such project I worked with, and even then the failure was due more to under-involving the end-users rather than to a too-simple scope). But many CRM projects struggle because they try to do too much, too soon. Go for the essential and consider the bells and whistles for a second or third phase. If your project is in the "mildly failing" category, simply moving non-critical features to a later phase may be all it needs to be restarted and completed successfully.

You may have to deploy some inventiveness to put in place the changes that are required to continue ”or restart ”the project. Whatever you do, don't expect to successfully restart a project without making some major changes. If the project was failing, it will take some real changes, not just good intentions or just "working harder," to turn it around.



Just Enough CRM
Just Enough CRM (Just Enough Series)
ISBN: 0131010174
EAN: 2147483647
Year: 2003
Pages: 143

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net