The user requirements are in; the specification and designs signed off; development ready to begin; then you realise you have no idea what the implementation looks like!
With a major programme such as CRM to run, a phased implementation plan, scheduling delivery of slices of functionality, over the life of the project, would be a good approach. We're aiming to get the foundation components in place - the database schema, frameworks, server infrastructure, then, while detailed design and development continues, identify some quick wins to provide business benefit early on.
There's no point waiting for a monolithic development to complete if everyone has retired or died in the interim...
It doesn't matter if the scope and requirements across the latter stages are only vaguely outlined in a one-page plan, so long as your scope and base design acknowledge the features to come. I'm seldom lucky enough to have a multi-year plan with full specifications for all phases.
What I have to instil in the organisation is that CRM is not just a technology project. The plan has to pull the staff, processes, procedures and training along with the software delivery, and not just in the departmental silos (more on that later). The plan has to align with the organisation objectives and include some metrics to measure how well the project delivers to those objectives.
The 'people' part of the project has to ensure that staff and associates receive effective communications; change is scary, so engagement and involvement need to be built into the delivery plan. Fear, uncertainty and doubt can destroy motivation fast when left unchecked.
Appropriate initial training should be accompanied by ongoing reinforcement training over the life of the project, to encourage consistent use of the essential areas of the system, but also recognise the best practice that will emerge as things bed in.
What you're likely to get in a large-scale implementation is a combination of phased roll-out of new features, with key Big Bang change-overs to the new way of doing things. Will you be running old and live systems in parallel for a hand-over period? Is that desirable or even possible? We used to do this with financial systems to prove the old and new systems agreed with each other; but when they didn't, which one was at fault? Far better to know through extensive testing that the new system is accurate than run an expensive double-counting exercise.
Make a new plan, Stan
The technology side of the project will require a more or less formal plan including:
- Data migration and verification
- Graphic design and theming
- Workflow processing
- Deployment through Development, Staging and Live
- Verification - user acceptance and sign-off - of the new system at each significant stage
Image credit: Blueprints photo by Wolfram Burner via PhotoRee