Saving Lives

In 2010, over 7500 people died of cholera world wide.

That’s 20 every day.

That’s 140 a week.

That’s 280 in a two-week Sprint.

That’s one hell of a velocity.

According to the World Heath Organisation[i] this was a 52% increase from 2009, attributed to an outbreak in Haiti following the earthquake in January 2010. The outbreak was so significant that 53% of this global total occurred over a period of just 70 days.

Cholera is caused by ingestion of food or water that is contaminated with the Vibrio Cholera bacterium that can rapidly bring on acute diarrhoea and lead to severe dehydration and ultimately death if treatment is not received promptly.

In May 2011, the World Health Assembly recognized the re-emergence of cholera as a significant global threat to countries that cannot guarantee access to safe drinking water and minimum standards for hygiene.

Consequently, almost every developing country faces the potential for cholera outbreaks.

Given the experiences in Haiti, a single catastrophe, such as the outbreak of war, an earthquake or a flood in a developing country can lead to a cholera epidemic of biblical proportions.

One of the main problems in containing cholera is the time it takes to identify a water source as being contaminated and for this source to then be quarantined and the community notified of this.

The sampling process is done on a monthly frequency, depending on the local population, and more frequently if an outbreak has occurred. In can take a number of days to test the sample in a laboratory and once the source has been identified as being contaminated it takes a significant effort to then communicate and isolate the source from use by the local population.

While this is happening lives are being lost.

Remember we have a velocity of 280 deaths per Sprint.

Now imagine we have a project that aims to provide the locals with a number of inexpensive devices that send an electric pulse into a sample of water to test for the presence of the Vibrio Cholera bacterium. The outcome is reported immediately and through a wireless connection in the device, the results are transmitted back to a centralized database instantaneously, that highlights the water source as contaminated or not.

This information is then used to communicate sources of contamination, understand where outbreaks or epidemics are likely to occur, which populations are the most at risk, and more importantly, it can help pinpoint the origins of contaminated sources.

The benefits of a successful project are numerous. The front-end devices can immediately warn or endorse a water supply for consumption, and the back-end analysis of the results across an area, country, continent or planet provides the ability to isolate the origins of an outbreak for rapid treatment. The end result, our velocity reduces from 280 deaths per sprint to a number approaching something more agreeable / acceptable / manageable…….no term seems appropriate where deaths are concerned….it is just less than 280.

Utilising our imaginations a little more, let’s now suppose we adopt a traditional waterfall approach to developing and delivering this project.

It takes 3 months to document the requirements in their entirety.

It takes 4 months to design the complete system, including the device and the back-end functionality.

It takes a further 9 months to develop then 6 months of testing before implementing a 6 month roll out plan across the globe.

That’s 28 months before we start to see the benefits. That’s the equivalent of 60 Sprints and, with a velocity of 280, that nearly 17000 deaths.

And that’s if the project goes to plan. What about all the risks?

  • Will the devices operate appropriately? How are they powered? Will they actually work?
  • Do they have a shelf-life?
  • How are they calibrated?
  • Does the continent have the appropriate infrastructure to support the wireless communications?
  • How are the devices distributed and the population trained in their use?
  • How do we roll out the devices in war-torn territories?

Given our past large scale project experiences, the schedule is more than likely to overrun, let’s say by a mere 50%. That’s another 8500 lives lost.

So to deliver the potential outcomes of this project using a traditional approach, it will cost millions of pounds and more importantly it will cost about 25000 lives.

Each day we delay delivering the benefits, it could cost 20 more lives.

Each week we delay delivering the benefits, it could cost 140 lives.

Each month we delay delivering the benefits, it could cost  560 lives.

Is a traditional waterfall approach appropriate for this project given the dire consequences of delayed Return on Investment?

So let’s assume the business case for this expects the project to not only reduce the number of deaths to pre-2010 figures, but to cut them further still by 20%. That’s a reduction of 72% from 7543 to 2112.

That’s 6 deaths a day.

That’s 40 deaths a week.

That’s 80 deaths in a two-week Sprint.

That’s a much worse velocity (but a better one given our unit of measure).

These savings are attributed to:

  1. 45% to the use of the wireless devices that immediately detects contaminated sources
  2. 20% to communication of contaminated sources in centralized database
  3. 35% to isolation of origins of contaminated sources and treatment to remove contamination

In addition, the business case also reflected which areas of the globe are most vulnerable to an outbreak of cholera. Based on figures collected by the World Heath Organisation the countries with the highest number of deaths from cholera are:


Number of Cases

Number of Deaths

Case-fatality rate













This equates to 84% of the total of cholera related deaths in 2010.

Now there’s a great example of pareto’s law.

Given this information, the associated risks and a recognition that a traditional waterfall big-bang approach is going to not just cost a fortune, it’s also going to cost lives, what other approach could we possible adopt?

Now lets not fall into the trap of labeling the approach. We could call is Agile or we could call it Lean but for now let’s not, let us define an approach to the project that helps us start to meet our goals the quickest…..

In this project, time to market and product utility are paramount.

In this project, our biggest risk is the devices not being fit for purpose.

In this project, if we can get utilisation high in three countries, we are well on our way to achieving our ultimate goals.

If we can therefore implement the feature of the system that gives us the most benefit (i.e. the devices) that also attacks the greatest risk to project success early (i.e. the devices not being fit for purpose) in the countries most impacted (i.e. Haiti, Nigeria and Cameroon) then we start to save lives.

Consequently, our plan shows a number of releases over a two year period showing testing of the devices in Haiti before roll-out to Nigeria and Cameroon as our initial releases. The central database, the communications from the devices to the database, the infrastructure to support wireless communications and the complex analytical features are all added in later releases building the project incrementally.

The project develops a prototype of the device and demonstrates it working on known contaminated sources in a controlled laboratory within four weeks of project startup. There were some minor problems with calibrating the electric pulse, analyzing the results, and presenting the results back in a form that could be understood and acted upon with minimal training but these were rectified and the design of the device (which resembled a light-weight aluminium pen) was fine-tuned.

After four weeks, the go ahead was given to manufacture 10000 devices for shipment to Haiti. 1000 could be manufactured a week and each week 1000 were distributed to Haiti and locals were trained in their use.

The large scale use of the first 1000 devices detected numerous sources of contamination that would have led to ingestion of the bacterium but also marked a small number of sources as contaminated that did not contain the bacterium and would have provided water that would be safe to drink. The boffins back in the project modified the software, calibrating it so that these sources would be marked as safe and released this software for the second batch of 1000.

The role out continued, water sources were sampled and the number of cases and the case-fatality rate began to drop.

From the initial release of 1000, not only did the team quickly get feedback on how the devices worked in situ, they also spotted the need to be able to do software updates while the devices were being used in the field (the first 1000 had to be recalled and the software patch applied).

This caused the project to adjust their schedule so that the next release would cover setting up the wireless infrastructure so that patches could be applied to the devices using their wireless capabilities. This proved invaluable as numerous changes were made to improve the devices over the initial releases to Haiti, Nigeria and Cameroon.

Six months into the project, the death rate  attributed to cholera in Haiti, Nigeria and Cameroon had dropped by 25%.

Six months into the project we were saving  4 lives a day.

Six months into the project we were saving 30 lives a week.

Six months into the project we were saving 61 lives in a two-week Sprint.

If our target was to reduce global death rates by 72%, after six months from project startup we were 75% of the way there.

The approach to project delivery we are yet to label, with its quick feedback loops that validated our assumptions quickly, contained our risks while they were small enough to deal with and allowed us to get the key features into the target users hands quickly. It was the white labeled approach that was the key reason for achieving these benefits so quickly.

Now this is just a fictitious project, where we have used our imaginations to demonstrate why the approach described is so powerful. It is void of technique, but it is common sense, it is logical is it not when the unit of measure for success is saving human lives.

The intent of using this fictitious project was to shock. To carve the rational of why such an approach should be used on the readers memory. Talking about saving lives leaves longer lasting trails of understanding than if we talk about efficiencies or investments……

But our projects are different.

Yes they are. They always are.

They always involve different people who all have different personalities, different experiences, different skills and different values about how the project should operate and what it should do.

They always have different customers who have different priorities, different goals, different problems, different infrastructure and different cultures.

In our projects we measure success in market share, in pounds and pence, in return on a monetary investment, in increased profits, in reduced costs. Not in lives…..

Our projects use technologies that are proven.

Our projects are based on automating known business requirements. We know what we want.

Our projects use inexpensive resources in India.

Our projects are based on fixed price contracts.

Our projects are enterprise-wide and involve hundreds of developers.

Our projects are not driven by time to market they are legislative and all requirements must be there by A-day.

All projects are different but they all have one commonality. They are all based on a myriad of assumptions that remain until the hypothesis has been proven. The best way to prove a theory or validate an assumption? Do the work and get the feedback. If the feedback proves the supposition then stay calm and carry on, if the feedback suggests an alternate is true then adjust, calibrate and try again.

Hopefully, by now you understand why the white label approach described in saving lives is a better approach to a traditional waterfall big bang approach. That the approach evolved because it was what was needed to start saving lives NOW! Not in 2 years.

All projects are different but they all have another commonality. They all have a myriad of statements about what the system should do. We call these requirements. Each of these statements is an assumption about what is needed, what problem is being solved or how the system should work. Each of these statements should provide some value to some entity of the systems external environment.  The totality of these statements covers a complete description of what the system should do and why.

However, they are still assumptions and still need to be validated. They are all statements of intent that need to be communicated. They are expectations. We therefore need feedback loops in place to quickly understand what we are trying to achieve, to ensure that those who work from these statements of expectation get it! and we need to validate that we are on course to achieve it.

We need to ensure we are doing the right thing and we all agree on what that thing is.

The best way to know this is to just do it.

[i] Weekly epidemiological record, 29 July 2011, No. 31, 2011, 86, 325–340,


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s