Thursday, December 31, 2009

WTO Bidding Process Considered Harmful

I've long believed that the WTO bidding process for IT projects is an expensive, wasteful process. By its very nature, it forces a waterfall process, which the CHAOS and other studies (despite their shortcomings) have shown produce a consistent 60 to 70% failure rate.

Of course it is mandated by law, so everyone has no choice but to play along. But at what cost? Finally, this issue is getting some attention. Today, documented the many shortcomings of the WTO Process (here is a translation from Google):
  1. The losers invest at least as much effort in bidding for the project as the project is worth. WTO projects are a net loss for the economy.
  2. Companies involved in preparing the RFP are not allowed to bid - all the context information is lost, so quality is lowered and the costs increase.
  3. Government agencies can and do write the RFP so that only one supplier actually has a real chance of winning the project.
  4. The process is vulnerable to price-dumping which a low price dominates other considerations (e.g. quality).
To this discussion, I would add: the WTO Process values features over business value.

 In the Spring of 2008, I led a proposal effort in response to an RFP from a Swiss Government Agency (who shall remain nameless). The Christmas season was very important to the revenue of this agency. Our proposal offered the advantage that they would have a working (though incomplete) system in time for Christmas of 2008 instead of 2009 which would let them generate ROI a year earlier. The response: "Our decision criteria do not require operation this year, so your advantage, while interesting, is not something which can affect our decision." AFAIK, their 'Hoflieferant' (established supplier) got the contract.

Is there a better way? Yes I think so. I have written about how an agile bidding process might work. What we need is an agency who wants to look for a better way. We could define and try out an agile bidding process. Any one interested? Drop me a line...

Sunday, December 20, 2009

Free Scrum Resources in Switzerland

If you want to find out about Scrum, but a course or coaching is not the right solution for you, what can you do?
"The Doctor is In" - Free Scrum Advice

At the next Scrum Breakfast in Zürich, I want to try out something I saw (and had great fun with) at the last Scrum Gathering in Munich: Free confidential coaching from volunteers. 'The Doctor is In'.

Coaches will be able to volunteer their time and Coach-ees will be able to sign up with a topic they want coaching on. There will be three 20 minute slots from 10am to 11am. I will commit to doing one slot (but no more! I want to leave the field open to anybody who feels qualified.) The next Scrum Breakfast will be a beta test, and if it proves to popular we'll keep doing it.

Did I miss anything? If you know of something I forgot, please submit a comment & I will update the article.

Saturday, December 19, 2009

Standish Chaos reports miss the point

The Standish Chaos report of 1995 is probably the most cited work on project success and failure. The latest incarnation is quoted as saying:
  • 32% of all projects succeed
  • 44% of all projects were challenged
  • 24% of all projects failed
where succeeded means 'delivered planned scope on time and on budget'. Scope, Time and Budget are the classic legs of the 'Iron Triangle' ('What about Quality?' 'We don't talk about quality, that's a given.' 'Right.') which every project leader is taught is the holy grail of a successful project. But is that really success?

I teach my Scrum students about 5 perspectives on success, depending on who you are:
  • As a developer: success is fun and learning. A good working climate and personal development.
  • As a PL: satisfy the constraints of the Iron Triangle
  • As the line manager: business units are happy - line management gets to deal with escalations. (Or for a programming shop: the salesperson who is happy when the customers are happy).
  • As the user: "the product helps me do important things better and easier than before. I am thrilled and want to use the product."
  • As the investor/sponsor/paying customer: a good ROI (however defined
Which of these is most underrated? My vote: Fun and Learning. For the reasons why, check out this video from or Dan Pink's talk about motivating people.

Which of these is most overrated? My vote: Satisfying the Iron Triangle. Why do I say this? So many participants in my Product Owner courses, when asked what was their worst professional disaster, responded 'We built the product, but no one wanted it. The whole effort in time and money was for nothing.' Focusing on the project leaders definition of success misses the user and sponsor's view of success completely.

Want your project to be a success?
  1. Figure out who your customers and users are. Make sure they will be thrilled with what you build.
  2. Figure what what the product should earn for the company and what it should cost.
  3. Assume it will produce half of what you estimate and cost twice as much. Is it still profitable? If not, think twice about doing the project.
  4. Figure out what is the minimum set of functionality to get your customers excited about your product. Build that (more or less - you are probably going to learn more about/from your customers and your product along the way, which will change your understanding of what you need to build)
  5. Stay focused on delivering value to your customer. Do Scrum.
Did I say 'Do Scrum?' Yep Scrum helps you do all the rest.