A best practice to avoid such problems is to assign project staff according to clearly defined roles. Basing your staffing plan on a comprehensive list of project roles and responsibilities ensures that potential staffing issues are identified up-front, so they can be addressed before they put your project in jeopardy.
Some modernization project roles, like Project Lead, Business Analyst / Planner, and Builder, are almost always required, with Builders assigned later. Others, like Architect, Specifications Gatherer, and Trainer, can be important roles in larger projects, but assigned as minor, part-time duties, in smaller ones. Assigning more than one role to the same person is the norm, in most EDI modernization projects.
The precise set of roles and responsibilities needed for a given project depends on project scope, solution characteristics, methodology, and other factors. Ask your solution provider or (for outsourced projects) integration consultancy to recommend a project staffing model, then adjust to suit your project needs.
One of the first and most important tasks in a modernization project is to populate the project repository with an inventory of existing EDI system assets, including:
Replacing a legacy EDI solution affects the way you organize, implement, operate, and maintain EDI integrations. And modern EDI systems can be complex, exerting impacts in unexpected places. So before you choose a replacement solution, examine the differences between your current solution and candidate replacement solutions. Then consider potential change impacts at four levels:
Use a life cycle activity model to analyze the impacts of different candidate solutions. Focus special attention on activities that are complex, time-consuming, or potential sources of errors or exceptions.
The Migration phase of an EDI modernization project typically targets a combination of legacy migration and new integration objectives. New integrations that require modern EDI features (such as XML transformations or near real-time response) are frequently modernization drivers, and given top delivery priority. The subsequent migration of assets from the legacy EDI system is usually staged using a series of implementation sprints.
Migration of legacy EDI assets occurs using a combination of metadata-driven conversion, object reuse, and automation-assisted implementation. Direct, one-to-one asset migration is rarely feasible, because of integration model features that are not found in classic EDI systems, vendor-specific implementation differences, and intellectual property protections.