The process of systems integration in Information Technology (IT) space varies in complexity depending on organizations and projects. Majority of enterprises use at least few different types of IT systems and, of course, these systems are somehow “Integrated”. Integration projects are caused by organizational changes and changes in supporting IT infrastructure such as migrations, upgrades, acquisitions, decommissioning, org restructuring, regulations changes and other.
Enterprise System Integration is not some simple single system upgrade or code development! Many experienced Project Managers (PM) know this well and think twice before accepting such projects!
Assuming that your project is a system integration project then, most likely, your client is a large enterprise. No doubt, small and medium size enterprises integrate their systems too, but the level of complexity and the scope cannot often justify significant capital investments.
Project Manager may be called in at different phases such as initiation, planning or design. PM may need to prepare or review and accept previously prepared project plan, scope or charter and overall project governance and alignment with PMO. Modern methodologies purists should excuse me here, but these phases are usually necessary for large enterprises just to get a project rolling, get necessary approvals and to secure the budget and your own compensation.
Part 1. Scope: Start with “What”.
I always suggest to start with defining “What”.
The scope statement may be your good starting point. It actually helps to have scope defined listing the in-scope and out of scope, assumptions, work and deliverables. “Who” “When” “How” and even “Why” can be defined later. If the organization issued the Statement of Work (SOW) make sure that your draft is aligned with it. My scope statement title draft would include the name of the project, organization and the system(s) names to be modified (changed, integrated, migrated, decommissioned …).
Integration means that your project will work with at least 2 systems. It is crucial to define what exactly is new, what is existing and what is expected “to-be” after your project is closed.
If you can write short answers to few questions below then your scope is well defined.
- What is the goal of this integration? Take it from the business case, if any, or other justifying the project doc.
- What is the end state for this enterprise after this project is complete?
- Is this project part of some larger program or portfolio?
- What equipment and software the project team will use — who will provision and what budget will pay for it?
Systems to integrate:
- Are they existing? If no — why is listed as existing? What are these systems are used for?
- Shall existing system be modified? If yes what part of the system will be changed? Is this change part of your project scope?
- Were they deployed? If yes then when and are they used in operations now? Are you responsible for their deployment, if no?
- Is this project establishing connectivity among systems? Most likely… then think about corp. security approvals.
Methodology
- Is there any specific methodology this enterprise is following? If yes keep in mind that you will need to align and, most likely, changing it is not your scope! For example, your sponsor and business stakeholder is insisting on agile and scrum approach when the rest of the organization is following the traditional or waterfall. How will you be delivering and submitting documentation and blueprinting required by other teams such as security, network administration, HR and others? Make sure you have it in writing and confirmed.
Testing and acceptance
- Testing and Quality: Besides connectivity and your system what else is expected? Is there any defects tracking system that can be utilized? Are you planning to reconcile the results? What about sustainability? What test or defect tracking system shall be used or procured? Shall this project include and pay for testing and UAT?
- Acceptance criteria: Define what is “sign-off” and method of acceptance (definition of Done/Ready if you want). Include the quality statement and list tolerance levels for defects severity (details can be defined later).
Training, Data, Security, Compliance and other
- Training: Are you responsible for the training? If yes what is expected? What about change management and is this enterprise ready for this change? I would try to keep this out of scope and leave it to the enterprise to solve its org readiness, training and change management challenges.
- Are you moving the data? Is there any restriction? Privacy? Sensitivity? Encryption? By the way, is this enterprise expects you to cleanse their data?
- What about Security, Reporting, Compliance to policies and regulations and other? Are you responsible for compliance delivery or confirmation?
- While you are collecting scope and systems details such as use, location/hosting/cloud, versions, platforms, interfaces and other you may also capture what skill and knowledge will be required (see “Who?” part). I also usually ask few simple questions: If the system is existing? Is this standard or in-house developed/customized solution? Who is the owner and who supporting it (admin)?
Uncertainties
If you learn that one of the systems cannot be modified then you have uncertainty in your hands and an obvious incompatibility. Why? If your system is not flexible enough to adapt to that other existing “frozen” system then you will need to perform additional research and analysis of using additional adapters or intermediate applications. It may be cost prohibitive to change that system or the system is no longer supported by the vendor or the system was developed in house and cannot be modified anymore. For example financial mainframe based application or compiled mission critical application on pre-packaged infrastructure. PM may still propose to make changes to such system as an option but make sure that decisions are driven by the review of the options and impacts analysis and recommended approach is well documented and accepted. These are the good candidates for assumptions and constraints parts of the scope draft.
As you can see the scope of the integration project is mostly dependent on multiple internal to the enterprise resources, external service providers and software vendors.
