BlockPlans Smart Project Delivery

John Reynolds
6 min readMay 3, 2018

Private Project Delivery Networks Powered by Blockchain and Smart Contracts

There have been many well documented failures of IT projects within the UK public sector including

  1. NHS IT — The £12.7bn National Health Service National Programme for IT (NPfIT)
  2. The Department for Transport’s Shared Services — was initially forecast to save £57m
  3. £7.1bn Defence Information Infrastructure (DII)
  4. £350m Single Payment Scheme system (SPS)

These failed projects are often characterized by numerous suppliers in commercial conflict, and a lack of consensus and agreement on the overall status of the programme, roles, responsibilities and dependencies.

Over the past months we have been working with a client who has a significant IT portfolio to deliver. This is a highly complex portfolio of projects with low level of trust amongst suppliers with continuous challenges understanding the current performance against time, cost and quality baselines.

The following outlines the key challenges, the solution and next steps.

The Challenges:

The problems the client is experiencing are:

  1. Complex multi-supplier environments — The entire portfolio of projects entails a complex web of contracts, work packages, project plans and dependencies across multiple suppliers
  2. Lack of consensus — Each organisation involved in the delivery of a project has their own source of truth about the project
  3. Lack of trust — The portfolio tracking tools are centralised in the customer organisation resulting in, participating organisations not fully trusting the data
  4. Poor Financial Visibility — Difficulty tracking commercial and financial performance
  5. Retrospective Assurance — Problems identified after the event
  6. Reconciliation — Significant amount of time spent across projects reconciling status of facts e.g. finances, deliverables and dependencies

The Solution

To address the problems we are exploring distributed ledger to manage performance and achieve consensus across a portfolio of projects and associated work packages amongst key suppliers.

The solution is targeting the following benefits:

  1. Autonomy — Each party owns the status of their deliverables, there is no central controlling party to be trusted
  2. Achieve Consensus amongst delivering organisations — Each organisation involved in the delivery of the portfolio share a single source of the truth
  3. Contract Compliance — Delivery of obligations tracked and certain elements automated with smart contracts
  4. Real-time financial reporting and transparency — Finance teams can see the financial performance of the project in real-time
  5. Enhanced Project Assurance — Internal and external project assurance teams can see the entire portfolio in real time
  6. Automated Risks Management — Machine learning enabling automated risk management based on historic events

Solution Components:

The Portfolio & Project Network

The portfolio and project network consists of a set of project nodes; each organisation participating in the clients project portfolio will have their own private node which hosts their version of the ledger and associated smart contracts.

Shared Ledger

Each project node will maintain their own private secure work package ledger and as a result, each supplier will only see a subset of work packages in the customers overall portfolio, and no supplier is aware of the customers work portfolio in its entirety.

The client will see the work packages they have in place with each supplier, however, suppliers will only have visibility to their own work packages, unless these are shared work packages with other suppliers. Note the system also allows for supplier to supplier work packages that the customer cannot see.

Work Packages

Work packages will represent the work contracted between the client and its suppliers. Each work package is set out in the work package ledger. As tasks are completed, work packages shall evolve by marking the current work package as historic and creating an updated work package.

A work package shall be an immutable object representing the status of the work package between one or more project nodes at a specific point in time. Work packages can contain arbitrary data, allowing them to represent facts about the status of the project or work package e.g. milestones, value, delivery dates, spend against budget or RAG status.

For example, the above work package represents a work package for Supplier A to deliver a software release to the Customer by 1/1/2018

Work Package Sequencing

Work packages are immutable, they cannot be modified directly to reflect a change in the status of delivery. Instead, the life-cycle of a work package over time is represented by a work package sequence. When a work package needs to be updated, a new version of the work package representing the new status of the work package delivery will be created and the previous work package will be marked as historic.

This sequence of work package replacements shall give all parties to the work package a full view of the evolution of the work package status over time.

We can picture this situation as follows, Supplier A updates the status of the work package with the status ‘green’, this marks the current work package as old and creates a new work package with the status ‘green’.

Full auditability and traceability of work package progress, portfolio flows & consensus

The client will have a real-time view of all work packages in the portfolio and the current states of the attributes. The client can be confident that all suppliers share and are in consensus around status, dependencies, and the history of the work within the portfolio.

Flows automate the process of agreeing updates to work packages. Communication between project nodes will only occurs in the context of these flows, and will be point-to-point. Built-in flows will be created to automate common tasks such as, issuing and signing of work packages

Portfolio wide consensus shall involve project nodes reaching consensus about every proposed change to a work package. Consensus is reached by one node proposing a change to the work package and then validating that the change meets the rules of the governing contract and is then signed by participating nodes. The change is then committed with the work package ledger on each node as an immutable change.

Next steps

From our experience, a collaborative project delivery, based on shared facts about the status of project deliverables and dependencies is key.

We will continue to work with our client and its suppliers to further define requirements and progress towards a Proof of Concept based on the Corda platform.

Its very early days but after decades of experiencing the challenges of large scale delivery, the possibility of changing the dynamic on these huge programmes by bringing teams into consensus is an exciting prospect!

--

--