USER-EA: Procurement Approach

“When to Gather Requirements in the Procurement Process”

The following is the script for the video:

Introduction Slide
This presentation deals with the thorny question of how to gather requirements and procure a solution.

Very often, projects are initiated and high-level requirements gathered, feeding into a commercially-led procurement process. Typically, this then leads to a contract in which there is an agreement to work together to elaborate more detailed requirements leading to a detailed design.

It is our contention that this approach is fundamentally flawed, creating a cast-iron provision for delays, change-control and budget over-run. A fundamental principle of a service-based approach is to define the contract first, and you can only define a contract based on sound requirements

Slide 2

This Solution Delivery Lifecycle is based on a waterfall approach, which is ideally-suited to and aligned with the approach of UK central government over the last 30 years. Outsourcing solutions to large Systems Integrators inevitably creates a "virtual wall" over which requirements are thrown by the customers and solutions tossed back by the SI.

While the above is an extreme interpretation, the basic premise is correct, and the waterfall approach provides periodic checkpoints for this "volleyball" approach.

Slide 3

There are a number of consequences of this approach:
a) The delivery process is lengthened to provide breathing space for the processes surrounding each of the checkpoints
b) A whole army of "pen-pushers" produce documents purporting to summarise the work done in the last phase, so that another army of "pen-pushers" can review them and supposedly provide assurance
c) You have to question the value of this "assurance" approach. Documentation provides limited value:
a. It can never accurately convey the detail of a design
b. It is usually out-of-date by the time it is published
c. It invariably becomes shelf-ware after its initial review, and therefore is of little value as reference material in the future
The checkpoint approach means that errors (particularly errors / gaps in requirements) are identified late in the process, increasing risk and cost by having to regress and rectify.

Slide 4

On top of the drawbacks mentioned in the previous slide, Waterfall is not inherently suited to the implementation of Commercial Off The Shelf (COTS) packages

The overwhelming reasons for choosing COTS packages are reduced Time to Market (pre-prepared functionality) and reduced Risk (pre-tested.)

Slide 5
A key principle in this approach is to minimise customisation in order to maximise the purchased advantage.

Waterfall simply introduces unnecessary additional time and resources, and therefore cost and risk

It seems clear that an Agile rather than Waterfall approach is more suited, but there is a significant problem….

Slide 6

Many organisations have built up a complete and mature set of governance and commercial processes and human resources based on the checkpoint approach. Senior stakeholders are loathe to dismantle this comfort blanket of the checkpoints, and many organisations would be thrown into a state of chaos if this happened overnight.

The question is how to introduce agile approaches within the framework of a waterfall governance approach. This slide and the next outline two common ways in which organisations try to reconcile this quandary, and the problems associated with each.

This slide shows the issues with commencing agile delivery after High Level Design

Slide 7
This slide illustrates the problems with introducing agile approaches after detailed design. This means that end-users are not able to re-conceive their requirements once they understand the capabilities of the package they are adopting

Slide 8

I think it's clear that these approaches are not very successful in terms of achieving a satisfactory balance between the waterfall governance framework and agile development

The approach advocated by Doug Walters & Associates aligns three phases of Agile Development (Collaborative Requirements Engineering; Convergence including Managed Sandpits; and Iterative Build) with the waterfall checkpoints at the end of Concept, Shape and Deliver.) This has been proven to provide a successful blend of existing governance frameworks with the benefits of agile development

Slide 9

If you'd like to hear more, please give us a call on:


Sign up for extra content

Register here to access premium content - the only information we require is your user name and a valid email address

Follow me

Latest private posts

Latest public posts

—1st July 2014
—18th April 2014
—9th April 2014