Collaborate from the start

Having witnessed and lived through several B2B customer onboarding projects over the past years, it never ceases to amaze me how little collaboration takes place during the planning phase of the project. As the customer you may be driving the requirements but the success of your project will only go as far as your partners (contract manufacturer, B2B technology provider, etc.) can support you.

Photo by Kaleidico

Develop the timeline together

Your vendors/partners have resource constraints and conflicting projects just like you do. These constraints and conflicts can easily be planned around if known in advance but become huge obstacles if not accounted for early. Additionally, many companies have freeze periods at the end of a quarter during which no system changes can be implemented. These freeze periods are oftentimes in place to help make sure their resources are focused on handling their heaviest production or shipping periods, and not distracted by a new EDI connection. Once again, find these sorts of things out ahead of time and plan for them.


Agree on an approach

If your key partner happens to also be a very large organization, they likely have a defined implementation methodology and standards just like your own company. These standards are in place to ensure a consistent, high-quality of delivery and shouldn’t be avoided. Have these discussions in the earliest stages of the project in order to understand how your own methodology supports or conflicts with theirs and account for those deliverables, milestones, and sign-offs in the plan. Additionally, there’s a chance that your partner has more experience with these sorts of projects than you do, so leverage their expertise in

terms of what has and hasn’t worked in the past.


Memorialize your agreements

Two-months into a project, team members aren’t going to remember a conversation or email exchange that may have taken place on Day-1 of the project. With project team members extremely busy, likely not co-located, and perhaps even with various preferred languages, there needs to be a very clear audit trail of key decisions and changes throughout a project. Every project has gone through it: the requirements specification is the “official” document until such time that people perceive themselves to be too busy to keep it updated at which point old emails or conference calls become the official statement of record. The investment of time required to update a specification or publish meeting minutes is far less than the

time lost down the road debating what was agreed to, as well as the tension such discussions create across teams. Furthermore, you know at some point the documents will get updated (in most cases long after the project was actually completed) so why not make those updates while the topics are fresh and everyone understands why particular changes were made.


Project success more often than not comes down to the basics. If you tackle them early with your partners, your project will benefit tremendously. Fail to collaboratively approach your project and you’ll be behind before you even start.