Planning and managing different types of B2B projects

In my experience with planning and managing B2B projects, I've learned that different kind of B2B projects require for different approaches. In this post I'll try to explain how each type has its own attention points and pitfalls and I'll try to give some tips and tricks.

I'll discuss in short following five types of B2B projects:

  A. Point to point, custom format
  B. One provider, many consumers
  C. Many to many, not regulated
  D. Many to many, regulated, without VAN
  E. Many to many, regulated, with VAN

A. Point to point, custom format

In this type of B2B project, the two parties have to set-up a new data exchange using a new custom format. This type of project often occurs when two divisions of the same company have to exchange data.

While setting up the communication most effort will go into analysing and defining the required format.

Especially when the two divisions are located in different countries it is important that you plan for a long period for analysing the required data and defining the format. I've learned that an efficient way of achieving this is that the sending party lists all data that is available on the subject, the receiving party excludes data that is not required. Then the party that has most experience in defining formats should make a draft and propose this to the other party. This way you can avoid endless meetings and discussions. Best is to opt for a format that can be strictly validated (e.g. an XML defined by a schema is a good option, an excel file is a bad option). A format that can be strictly validated will reduce misunderstandings and will reduce testing and maintenance effort.

To resume:

• Foresee a longer period for analysis.
• Make one party responsible for defining the format.
• Be aware that the chosen format can have a big impact on planning and maintenance effort.

B. One provider, many consumers

One data provider exposes particular data in its custom format and distributes it in its own chosen format. When you have to plan this type of project you should be aware that a lot depends on the quality of documentation of the data provider and their ability to communicate. Before setting up a schedule for this project you should perform a kind of smoke test. Ask the provider for contact info of the technical and functional leads, documentation on the format and real life examples. This test can result in three different scenario's. 1) You've got a fast response and the documentation is clear: don't calculate too much overhead. This means that the total lead time can be based on the estimated effort. 2) Documentation is clear but communication is slow or not efficient: the total project duration will be a lot longer than the estimated effort, because the analysts and developers will often have to wait for answers. 3) Documentation isn't clear and communicating with the data provider is difficult: plan for a longer implementation duration and more maintenance effort after the go-live.

To resume:

• Test the documentation quality and communication efficiency with the counter party.
• Make your planning dependent of the outcome of this test.

C. Many to many, not regulated
 

In my experience this the type of project that is the hardest to plan and to maintain. The data that is exchanged is formatted according to a certain standard. The standard will often be governed and documented by a dedicated organization. Exchange of the data is set up between the different parties directly and anyone can join in the data exchange.

This type of project has a lot disadvantages which need to be considered when planing or scheduling one. Every party can interpret the standard in its own way. Especially when your dealing with a very market specific standard. This will result in a longer implementation duration and a lot of maintenance afterwards. A longer implementation, because to be sure that your implementation is correct, you'll need to perform some tests with the counter parties, but to be really sure of your implementation you should test with all counter parties. After the go live this will also often result in endless discussions and a lot of emails back and forward, so a lot of maintenance overhead. Setting up the communication with all the counter parties individually will consume a lot of time. The total set-up effort might be small (often it's just a matter of setting up master data) but the total duration can be very long.

To resume:

• Plan for a long period for setting up communication with the counter parties.
• Plan for a lot of maintenance effort.
• Avoid getting involved in this kind of project if you have the choice (which you often have not)

D. Many to many, regulated, without VAN



The only difference with the previous type of project is that this one is regulated. This makes a huge difference when it comes to planning the project. Regulation means that a party can only participate to the data exchange if they are certified to do so. This means that the party first has to prove that they have implemented the standard and data exchange correctly. This is often checked by a series of tests that have to be executed. If this certification is strict enough it has as consequence that there is no room for interpretation and that maintenance effort after the go-life is strongly reduced. Counter parties that fail to obey to the rules set in the standard can be excluded from the process by the regulator.

To resume:

• Plan for a long period for certification testing,
• Plan for a long period for setting up communication with the counter parties.
• Don't expect too much maintenance effort.

E. Many to many, regulated with VAN


Here the only difference with the previous type of project is that the regulator has set-up a VAN that is responsible for dispatching the messages to the correct counter parties. This way each counter party only has to set-up communication with one endpoint. This results in a remarkable shorter implementation lead time. Another advantage is found in the fact that the VAN often adds a certain level of logging. This can be very useful in case of production issues and can reduce maintenance effort. We would reach Utopia if the VAN would also validate the inbound messages and handle incorrect messages directly with the sending party. But I haven't seen this yet.

To resume:

• Plan for a short period for communication set-up.
• Don't expect too much maintenance effort.

One last thing in regards to these last three project types (using standardized format): the standard itself has of course also a lot of impact on the total lead time of the project. Before planning you should check what type of standard you're dealing with. Is it a globally implemented and widely adopted standard or is rather created for a small country specific market? How long is the standard used, will you be confronted with child diseases? In which language is the documentation of the standard written (market specific documentation is often not in English)?

Author: Laurenz