Make the Solution Fit Into the Organization

You know the story.  The organization has an issue or need and they want a solution.  That is all well and good, but in the end it also has to fit into the flow of the business.  Few processes, functions, and end solutions are standalone.  Most – nearly all, I might say – must fit into the business and acquire data or tasks from somewhere and flow data or tasks to somewhere.  There is usually input and output.

 

We always must be considering things like existing interfaces, new interfaces, and obsolete interfaces.  And don’t forget that end user acceptance, full company adoption, and upper management buy-in all play a part in the successful role out of a solution that integrates heavily into the existing business infrastructure.  It is just part of how businesses work.

 

The key is…do not underestimate the time and effort needed to integrate a new system into the existing business and interface it to existing systems.  Planning is critical and ensuring that all tie-ins are captured in your project schedule as necessary tasks in the overall project plan.  It is extremely important to create an understanding of the timeframe needed to guarantee the integrations are handled properly.

 

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. Some specific things to take into consideration when incorporating integration concerns and tasks into the project plan include:

  • Define the communication between all interested parties
  • Review interfaces used on other projects that may influence this project
  • Define all project interface requirements carefully
  • Identify all possible risks and issues in a risk management plan
  • Define the output for each project deliverables
  • Document any necessary data conversion processes and who is going to be responsible for what
  • Always establish a change control procedure
  • Establish a detailed plan for integration testing
  • Ensure that a contingency plan takes effect in the event of system failure

 

Summary

Very few projects actually stand-alone.  At least not the big ones.  The enterprise ones never do…in fact they usually touch most facets of the business to some extent.  Most, but not all, integrate to some degree into existing systems and processes within an organization. If we miss those interfaces and integrations during requirements planning and definition, we are asking for a lot of rework that will trash the budget and the schedule.  Failing to plan for how those integrations will be handled will cause delays, they may cause resistance to adoption of the new solution by end users, and they most certainly will cause failure - to some degree - of the deployment overall. 

 

I realize everyone wants to get started on the meat of the project and customers and senior leadership can get pushy when they think we are spending too much time planning on those highly visible projects and not enough time configuring and creating. But it is necessary we spend enough time planning upfront and identify all potential integrations to ensure all bases are covered.  The customer wants a successful end solution – it is our job to help them ensure we have properly documented all requirements – especially how the end solution will fit into the business at deployment in order to help ensure the success of the engagement.

 

 

 

 

Add comment