Rolling out a new solution for a project client requires extreme planning, effort, and coordination throughout the engagement. No project manager or project team member would tell you anything different. Indeed, I would venture to say that most project customers would say this as well, no matter how engaged they are throughout the project.

While planning for the actual deployment and hand-off to support of the final solution, the project manager and team must never underestimate the time and effort needed to actually integrate a new system into the existing business and interface it to existing systems, if that is going to be the case. This should already have been taken into consideration during the upfront planning process and shared with the team and customer - if appropriate - using a collaborative viewing tool such as Seavus Project Viewer, but it never fails to become a bigger task than originally planned - at least from my personal project management experience.

Project managers need to be sure that the plan allows some contingency for slippage and that they are informed whenever staff encounters this. Project managers must plan for any integration tasks from the start of the overall project, not leave them until the end. Leaving this type of integration to the end of the project and not planning enough effort for it as well as not including it as part of user acceptance testing (UAT) can be a recipe for disaster. The following are some key considerations:

1. Review existing interfaces

Review those interfaces used on other projects that may influence this project. It's so easy to overlook interfaces with existing systems or that interact with other projects. Ensure that all bases are covered when planning and when performing testing ... and definitely when rolling out the solution.

2. Define all interface requirements

Define all project interface requirements in detail up front ... and this will help with the first consideration above as well. This activity must be part of the detailed requirements planning for the project, but it can sometimes be overlooked or considered in less detail than is necessary for the project.

3. Consolidate integration plans

Be certain that there are not too many third-party contractors all working on separate integration plans. A single, coordinated effort is more desirable.

4. Identify and manage risks

Identify all possible risks and issues in a risk management plan. Skipping over risk planning is one of the biggest mistakes a project manager and project team can make. Conduct detailed risk identification and planning, and proceed with risk avoidance and mitigation planning and make that part of your management strategy throughout the rest of the engagement.

5. Define communication points

Define the communication between all interested parties. Putting together a detailed communication plan at the outset of the project may seem like overkill, but it allows you to layout the project communication process upfront and remove any question marks as to who is responsible for what. It has definitely been a plus on every project I've managed where I've had the time and budget to put one into place.

6. Define the outputs

Define the output for each of the project deliverables. It's critical that you and your team - along with the customer - do a thorough job of defining the outputs for each project deliverable. Poorly defined outputs lead to a poorly tested, poorly integrated, and poorly rolled-out solution that may not meet the end users' needs.

7. Plan for data conversion

Document the data conversion process. Know the details and prepare your team. The customer and the customer subject matter experts (SMEs) are going to be your best friends in truly understanding the date, their data needs, and how the data needs to be converted and integrated into the new solution. They are all part of the team - use them wisely. Assign them tasks and give them access to your collaborative project-scheduling tool like Seavus Project Viewer.

8. Setup a change process

Establish a change control procedure. Every project needs change control. Requirements change to some degree on nearly every single project - if not on every single project. The formality of the process may depend on the size of the project and the size of the budget, but discuss this with the customer and come up with a change process that makes sense for the project.

9. Perform integration testing

Be certain that there is a plan for integration testing. This may seem obvious, but it's almost funny how many times this process is either overlooked or very little thought is put into it. You can test the integration points, yes, but if you don't really do it with real data in a real test environment you're not really performing a thorough enough test to ensure it will all work at rollout time.