Unraveling Complexity, Part 3, Situation 3

From Prior Posts in This Blog Series…

In parts 1 and 2, I introduced the complexity topic, provided some sample online definitions and discussed sources. I provided a case study showing several significant challenges that were the result of lack of deep planning before the project began executing.

Most recently, Part 3 discussed two situations, one about embracing change management and the other about finding mandatory administrative processes. In this final situation, I’ll discuss vendor governance and configuration. This again relates to the same case study.

SITUATION 2

Our program objective was to improve compliance with Sarbanes-Oxley (SOX) regulations for a global safety / science company through process changes and new technology. Two third-party integration partners were involved to connect the new technology solution to at least five existing, inhouse systems. I’ll call partners “A” and “B” for this discussion.

Facts and symptoms discovery inventory

The client required that we follow two project methodologies, one from IT and one for global projects. This created internally facing requirements we needed to fulfill.
Third-party A would focus on process reengineering and overall deployment.
Third-party B would implement the new technology and provide the integration components and software customization to connect to the client’s systems.
The plan was that A would manage B because A brought B and their software into the project. Theoretically, we would need to have little interaction with B.
The initial implementation plan, authored by A, was very aggressive and was agreed by the client with little detailed understanding of impact upon the organization’s business resources.
The client had not worked with either third-party before.

Start Up Activities

We all had new relationships, different cultures, and different project methods. The approach to build the team and get us working productively quickly included reviewing and negotiating how we would co-manage and set up the project. We took on these planning items at the start of the project:

Reviewed each vendor contract and walked-through the assumptions/constraints, deliverables, timelines and resources. This helped establish common understandings of expectations. Missed topics needed to be negotiated.
Reviewed and understood each partner’s communications needs, especially to satisfy their stakeholders. While we shared the delivery and go-live impacted stakeholders, each organization had a leadership team and peers, on their side, that would need status’, progress reports and other communications.
Defined the configuration and infrastructure for the project. Each third-party had their standard methodology and the client had two. It was not the best strategy to simply require all partners to follow the two methodologies of the client. Much of the client’s methodology concentrated on internally facing activities. We defined a blended approach to meet each organization’s needs. This included status reporting, project plan maintenance discipline and accountability, document storage and sharing, risk and issue management, and meeting design, to name a few.

Assessment Thoughts

Vendor governance and configuration was as much about building relationships and trust as it was setting up efficient and functional infrastructure. In a lot of ways these were administration and planning tasks. However, they were critical to avoiding conflicts and issues, and needed to be agreed and implemented as quickly as possible so not to delay the project execution. There were conflicts with the aggressive schedule expected by the vendors because it did not take this effort into account and was not fully assessed by the affected business teams.

The planning tasks were completed in the first month of the project. Adjustments were made along the way as we ran into items we did not think of initially, but in general we had a working infrastructure.

Conclusions / Wrap-Up

In retrospect, expectations of effort and scope to build vendor governance and configuration were underestimated. Additionally, the expectation that third-party B could be kept at arms-length and all interactions made through A, was unrealistic. Third-Party A did not have the expertise with the software solution yet many discussions on feature, function and capability were required throughout. We ended up interacting quite a bit with both vendors.

A pre-project planning stage environmental and impact assessment would have helped to identify these governance and configuration items. They would have allowed us to properly build-in the effort required and better set expectations with leadership. This should have been accommodated in the initial schedule.

How do you plan for and set up vendor governance on projects with multiple third-parties involved? Thoughts and comments on this post are invited and always welcome.

This is the final installment of this series but expect more future posts about complexity.

Want Tips for Unraveling Complexity?

Get a copy of our new resource:

7 Tips for Unraveling Complexity Without Tearing Your Hair Out

Please enter a few contact details and the document will be available for viewing and download.

The founder, Evan Lenhardt, holding a small blackboard with chalk writing that says "challenge".

Since 2002, I’ve focused on wrangling complexity in transformational projects in banking and other industries, while developing the Readiness Assurance© practices that help you improve preparation and planning.