ProjectDirectors-Multi-Vendor-Projects
Photo: ”Datagedreven sturing, Gemeente Utrecht / SETUP” by Sebastiaan ter Burg / CC BY. Adapted from original.

Introduction

In typical multivendor IT purchasing where different vendors deliver parts of a system, especially systems that require hardware, server or cloud integration, UI/UX creations, software development and UAT testing, it is common to use a traditional project management methodology to manage the delivery. One of the challenges of using these traditional methodologies, particularly with multi-vendors, is that the project invariably becomes waterfall in nature with discrete near boundaries between vendors or functions. There are documented challenges with the waterfall IT service delivery model, with multi-vendors, these challenges could be exacerbated by the different delivery cultures, misunderstandings around accountability or simply delivery items could be missed or misunderstood due to the degrees of freedom inherent in such projects.

One method of managing some these challenges is to incorporate some of the benefits of the Agile framework into a traditional process, especially around the design-build-integrate-test phase or gate of the project.

Infusing Agility into a traditional Multi-Vendor Project Framework

Firstly, building strong relationships with the vendors is one of the most important factors for success in a multi-vendor project. The suggested approach is to bring all the vendors together to form a project team with its own culture, team spirit and group objectives. This can be challenging essentially due to the fact that the different vendors have naturally come from different delivery cultures within their organisations. Achieving this sense of group should be a key objective of the customer management team. The customer management team should foster an environment for this bond to form, encourage collaboration, infuse a sense of ownership and act as the primary facilitator for the group.

The RFP/ RFQ process for the project should establish the intention of using an Agile framework. Subsequently the contracts and SOWs should be structured for time-boxed incremental deliveries aligned with features so that all the vendors are focussed on the same features, albeit different aspects, at each increment. In practice, this may not always be possible, but the objective should be to align as best as reasonably possible.

The SOWs, from a purely Agile perspective, could be denominate in Story Points. However, coming to an agreement about the definition of a Story Point with all the vendors can prove challenging. In practice these contracts are denominated in Man/hrs or Days. See below for a simplified version:

Date 1 Date 2 Date x
Resource Increment 1 Increment 2 Increment x
A  ($/Day) Feature 1 Feature 4 Feature 7
B  ($/Day) Feature 2 Feature 5 Feature 8
C  ($?Day) Feature 3 Feature 6 Feature x
Man Days Man Days Man Days

 

Taking advantage of the principles underpinning Continuous Delivery in which features are designed, built and tested to production ready quality at the end of each increment. Working in this way involves sliding the testing and UAT to complement development.

Structuring the testing/UAT around the development activity is a key consideration. The test estimates provided by the vendor should be disaggregated to align to feature delivery with the ability to flex the test/UAT units (Man/hrs, Days etc) to support the Continuous Delivery approach. It should also be taken into consideration that the testing effort may increase due to need to support regression testing at the end of each increment.

ProjectDirectors-Multi-Vendor-Projects_v2

Project Management

The supporting project management activities naturally depend on how structured the process is for the purchasing company. Apart from the contracts and SOWs, a few key documents are required to establish formality around the delivery of the projects with multiple vendors.

A Delivery Strategy document, this could be part of a TOR or a Project Definition Document, agreed by all parties should include the fine details of the agreed Agile method of working, collaboration tools, tracking and communication methods. The document should also detail the project objectives, high level scope, a governance model, change control, dependencies, milestones and deliverables, reporting and all the usual project management deliverables.

A Test Strategy that incorporates the test plans from the vendors to establish the format and methods for quality assurance. The document should define an agreed Definition Of Done (DoD) and, crucially, synchronises test phases, establish environments, defines defect classifications, agreed methods of triaging defects, reporting, roles and responsibility.

Following that, an integrated plan ought to be created to bring all the delivery streams together, identify dependencies, milestones, risks and issues, responsibilities and accountability.

Other documents to support the effort could to include a shared RAID and high level integrated design. This is not an exhaustive list, but as a guidance that could be tailored for individual, organisations or project needs.

The discussions above provide and an illustration of how Agile methods could be used to augment traditional project management methodologies for executing managing multi-vendor projects in any organisation.