When is a development a development?
In my blog entitled https://www.southwestdataintegration.co.uk/post/an-edi-development-could-impact-many-teams-within-the-business I considered the various departments/teams that might be impacted by an EDI development.
I now want to discuss when an EDI development needs to be considered within a Project Management Office (PMO) portfolio and managed by a Project Manager (PM).
I appreciate that this could be a little contentious to the PM world but I want to highlight why an EDI development should not sit within a PMO or a PM. Bear with me.
The Project Management Office
Please do not get me wrong as I understand the importance of managing change and I am not advocating that this process should be bypassed if a proposal fundamentally changes the way a business works.
Change should happen as the business grows and systems, processes or departments/teams change or adapt. Change will impact the wider business and therefore will need to be planned and scheduled to ensure that the change is successful and accepted by the wider business.
EDI Strategy
If the business has deployed the solutions to support how the business works with their external systems there should be no need for change. I pick up on this aspect in respect of strategies here: https://www.southwestdataintegration.co.uk/blog/categories/data-integration-strategies
EDI Developments
If the business has developed solutions and processes to support EDI (known transactions and file formats in and out of the ERP systems) then there should only be configuration required to support the EDI development.
Therefore an EDI development should not impact the business other than configuration and automation.
Operational change
If an EDI development is plugging into an existing process there should be no impact on the operational teams other than the data flow for the various transactions that will be automated.
Aspects to consider when deploying an operation change is who is interested in the change and who is responsible for what within the business process. The wider teams within the business need to be made aware of any EDI development work that is going live just to ensure that they are onboard with the change and everything is working as expected.
Systematic change
As previously mentioned if the systems in use within the business are able to support EDI then all that should be required is configuration.
There is no reason why a generic process can not be in place to support the required route to market:
Wholesale - business to business
Drop Ship Vendor - business to business
Marketplaces - direct to consumer
Website - direct to consumer
However, does the proposed EDI development require change rather than configuration to any of the systems? If a change is required then the change needs to be managed through a PMO and change control process to ensure there are no unexpected outcomes.
PMs and the PMO
Timelines, Gantt charts and working with various third parties sometimes does not quite work with an EDI development. I have found that timelines that the business will be working to could be out of sync with the timelines of the third party that you are connecting with.
Although an EDI development should be seen as important; invariably the support required to work through the development could be reprioritised by the third party or EDI is just one part of the role and that department or team and the development is not deemed a priority. Within an EDI development you could be working with a number of businesses:
The EDI MSP used by the business
Any Software As A Solution (SAAS) used by the business
The third parties EDI MSP
The third party business you are connecting to
I would suggest that a process to roll out EDI does not require any dedicated time for a PM or the PMO, if there is a PMO in place.
As a further issue to be considered a project needs to consider the return on investment and therefore needs to be justified. An EDI development could be a small piece of work and therefore might not stand out against the other projects being discussed and agreed within the management team within the business.
Managing a rollout of EDI developments
I am not advocating that EDI developments are not managed. What I am advocating is that EDI developments need to be fluid and flexible so that should one development stall another can be developed.
I would advocate these developments are managed by a team so that there is consistency, understand and internal knowledge of the businesses priorities.
Reporting EDI development activity
By it's very nature EDI is hidden away and the wider business can lose touch with development progress. I have used tools such as SharePoint to report development activity. I have built reports to record the activity by a set period such as a month or year.
I agree that developing an EDI strategy has cost money and the business needs to understand the return on investment. Hopefully a format of reporting will demonstrate the value of the strategy.
Conclusion
The PM's and PMO should manage change in the business.
Rolling out EDI developments should be managed by the EDI team.
If there is a known and agreed EDI strategy, the systems in place do not require any development and there is an agreed method of reporting then the EDI team should be able to work autonomously.
Allow the EDI team to manage the EDI relationships with the retailers and or distributors. This, I believe, provides a far more professional approach when discussing all things EDI with the retailers, distributors or EDI MSP.
These considerations might not apply to a smaller business as they might not have a PM or a PMO. Having EDI knowledge within the business could be of great use. From my experience I know that having internal knowledge of EDI processes provides confidence with the retailer.