Making More Money - example 1

My book's most blatant theme is that many, many businesses can use Agile+TOC to transform their software development teams from financial black holes into a gold mines. 

In my equally blatant on-going effort to promote my book and my own consulting services I am going to post some examples of how Agile+TOC can make these businesses much more money.

Let me give you a mock, but realistic, example.

Imagine one of CCXCO's many software development teams is made up of 10 staff each earning (for the sake of argument) £250* per day.  A little math reveals that CCXCO spends £2,500 each day to keep this team producing software. Assuming that there are 20 working days in a month then CCXCO pays out £50,000 each month on building software for this team alone.

Now, imagine that the team has just spent 6 months delivering a project using traditional methods.

The project cost £300,000.

Now, ask yourself: how much could CCXCO have saved if the project delivered a better product in 4 months, rather than 6 months?

That’s right: £100,000.

That is a lot of money even for a big company like CCXCO ... especially when you add it up for every software development team in the company.

That's the sort of saving that well most well run Agile+TOC projects can expect to achieve. 

CCXCO wasted £100,000 in that half of the year, for that team, because they didn't use Agile+TOC.

Most Agile+TOC projects can reasonably expect to finish in between half and two-thirds of the time a traditionally run project would. 

Why?  The first reason is that Agile+TOC projects they do far, far less rework.  The second reason is they build far fewer unwanted features.  The third reason, is that they force technical catastrophes (which only happen on some projects but often cause those projects to be cancelled) to happen earlier in the project when they are easier, quicker and cheaper to solve. 

Agile+TOC projects finish earlier.

Fortunately, that's only a tiny part of the good news.  More to come.

The unfortunate thing is that most businesses have no idea they are missing out on these savings.  That's one of the reasons why I've written my book.

* to convert each pound figure into American dollars using the current exchang rate, just change the symbol to $ and add another zero to the right of the orginal number.

Comments

[Glen B. Alleman]

Clarke,
I know the statement "agile projects finish earlier," is a very popular notion. However there are examples - we are on two now - where agile projects have gotta completly in the ditch. One a B2B web app and another a backoffice reconciliation app.
It is sporty business to assert one thing over another in the absence of statistical evodence. By this I mean, do "well run" agile projects statistically finish earlier than "well run" conventional projects? By statistically significnat I mean outside the expected variances in the completion dates of all projects, with the variances of all the independenct variables.
Finishing earlier in the absence of the boundaries of these other varianbes is called hype.
A CIO woudl ask, with the same requirements, same regulatory documentation (SOX for us here), same investment on the customer side, same labor cost, same management foot print. In other words the same "all in costs" and the same "all in benefits" with the same units of measure on boths sides.
That woudl then allow the statement, "agile projects finish earlier," to be correct.

[Glen B. Alleman]

Clarke,
Just an add on from todays mail. CrossTalk, The Journal of Defense Software Engineering arrived in the mail. Alistair Cockburn had an article as did Bas Voode - who I sat on a panel with at this weeks Lean Product Development conference.
On the outside back page was an ad for the 76th Software Maintenance Group, Tinker Air Force Base.
99.5% on-time delivery of software for weapons system, automated test equipment, engine test cells, idustrial automation, and applications (they did say what kind).
What came to mind was your statement about "shorter development times," and what that means - in units of measure - to customers. 99.5% on-time with a CMMI Level 3 and 5 appraised process is interesting, but more important begs the question - can it be better? If so, how and with work measureable impacts on the other variables of software development.

[Jack Vinson]

Clarke-

Your example was a very cost-world analysis. Could you have done something different by talking about the added capacity that faster project completion buys the company: 3 projects of similar scope per year instead of two! That is 50% more revenue, not 33% less costs.

[clarke ching]

Hi Glen,

You are (imho) mostly right. I specifically wrote that *most* Agile+TOC projects can reasonably expect ... because it is true that there are some cases where they won't.

I also compared them to *traditionally* run projects, by which I mean waterfall/critical path projects.

I envy you because you're working in "rocket scientist" land - miles ahead of most commercial software development organisations. That's great news, from my point of view, because it means that most projects can realize huge improvements.

Clarke

[clarke ching]

Hi Jack!

You are 100% correct. I'm just starting with the easy stuff first.

Many managers (who I'm aiming to persuade with this type of message) live in the "cost world" so I want to speak to them in their language, first, before introducing them to throughput world thinking.