Mar 26, 2008

A Tale of Two Companies

There were once 2 companies who both wanted to develop some custom software to help their businesses enter an evolving market and gain a competitive edge.  Both companies made an initial approximation of the costs involved in getting the software developed and both companies set aside a similar sum of money for the project.  Neither company had any real appetite or skill for developing the software internally and decided to get external companies to help.

Company A

Company A decided to take the traditional, recommended, "best practice" approach for getting the software developed.  It's what they'd always done in the past, it's what their project managers recommended and even though they'd never had a project come in on time before they hoped that if they  did things right this time then it would all be OK.  They also decided to set aside a portion of their budget just in case there was some overrun in the project.

Because Company A wanted to get the best value for their money they decided to put out a tender.  They knew that a tender would give them a result they wanted for the lowest fixed price and they'd get everything they asked for.

They also wanted to get the tender right. They knew how many software projects failed but they figures that that was mainly because requirements in tenders had never been quite right before. If they could get their tender requirements right this time then it would give them their best shot at a successful project and they'd be able to enter this new market with confidence.

Company A decided that the best way to get requirements right was to get in an external expert to help draft and clarify the requirements and to word the tender in the best way possible so that anyone could to clearly understand what it is that they were after.

It takes a week to find the right expert and during the initial meeting the expert listens to the high level overview of the project and estimates about 6 weeks to get the tender ready.  The expert then starts talking to the stakeholders in the company and begins to draw up an initial draft of the tender.

The expert uncovered more requirements than were initially explained and, as this was a perfect opportunity, a number of stakeholders added wish list items to the tender to be included as low priority items. After two months the tender draft is ready and placed before the stakeholders for review.  Everyone in the company understood why the extra 2 weeks were needed to get the draft completed and thought that it was time well spent, especially as some critical requirements were discovered that would otherwise have been missed.  Unfortunately the review also determined that some of the requirements weren't well described and others some seemed to have been misunderstood.

2 weeks later the revised draft was again presented to the stakeholders for review.  There were still a few things that weren't quite right and a couple of the stakeholders were unable to attend due to scheduling conflicts but as the tender had now taken a month longer than estimated the remaining stakeholders signed off on it and got the project moving.

The published tender had over 400 requirements and suppliers were given a 4 week window in which to respond.  Responses when they arrived were larger in both number and size than expected and the review of the responses took 4 weeks to score and complete before a group of 3 potential suppliers were short listed and allocated a day each to present their proposals, 2 weeks after being notified.

Now after 20 weeks the company was at the point where they were ready for vendor presentations.   And they still had no software to show for it. Plus they'd spent 15% of their project budget already.

 

Company B

Company B took a rather different approach.  They'd been burned by tenders and fixed price, fixed scope contracts before and their CIO had read about agile development and some of the success stories that were talked about.

While it was considered a risky approach,  the CIO knew that repeating what had failed before in the hope that the result would be different was the very definition of insanity, and recommended that an agile approach be taken and immediately set about locating a number of potential vendors who could deliver a project using an agile methodology.  After 2 weeks the potential vendors had been contacted and a preferred vendor chosen.  The CIO and the vendor also took an unusual approach to the contract. They agreed that cost would be limited, but that scope would not.  A minimum set of functionality would be delivered but beyond that anything could be changed by the company.  Company B could terminate the contract at any time of their choosing, as long as they paid out a portion of the remaining contract.  The vendor would deliver the highest value software they could using a prioritised list of requirements as determined by Company B. The vendor also stipulated that they wanted to have a single representative of Company B to work with, not a committee. Changes to functionality, priorities and requirements were allowed at any time with no extra cost so long as those things changed were not currently being worked on.  If Company B wanted to add new features or change existing ones then that was their right.  The vendor also agreed to deliver regular releases of the product so that the company could see what was being built and could optionally put that code into production should they deem it appropriate.

It took a few more weeks to get the legals and the resourcing of people sorted out but even so, the project kicked off 4 weeks after the initial "go" decision.

During the initial week of the project stakeholders from Company B and members of the vendor's project team sat together and worked out a prioritised list of high level requirements.  Many of the requirements were still somewhat vague but the vendor wasn't concerned - they would work with Company B's people to clarify those requirements better once they got to them.  Each requirement was given a relative effort estimate based on how much effort there might be compared to other requirements in the list, and was also given a simple set of criteria to help determine when a requirement could be considered complete.  After some consultation with the vendor the prioritised list of requirements was altered slightly to take into consideration any cross-requirement dependencies and pre-requisites but the end result was an order list of things that Company B wanted in their software.

The very next week development work began.

The vendors team started by taking the 4 first items from the requirement list making a commitment to complete them over the next 3 weeks, saying they would have something finished that they could show the people of Company B when the time was up.  However the CIO was a little concerned - 4 items didn't seem like that much to work on.  However after the team talked through how much code and database set up needed to be done in order to complete a single item the CIO was willing to go with it.  At worst they would waste 3 weeks and if they didn't like what they saw they could always terminate the contract.

Over the next 3 weeks the team set to work.  However the teams definition of work was a little unusual, they didn't go and lock themselves away and then turn up 3 weeks later with something to show, they were very visible, spent a lot of time asking people questions, clarifying what they were doing and getting stakeholders together to make sure they understood what needed to be done.Plus there were all these wall charts and sticky notes being stuck up on windows and walls so that anyone could see what was being done by the team and how they were tracking.  For the first time people in Company B could see what those mysterious developers were actually doing.

At the end of the third week of development the team got the stakeholders together and showed them what they had done.  All 4 items they took on were there and working.  No smoke, no mirrors. Plus the people from company B were allowed to play with that version of the software whenever they wanted.  Company B was quietly pleased.

The next week the vendors team took on 12 items to deliver in 3 weeks.  Now the CIO was thinking that they'd taken on too much.  But the same thing happened - lots of communication, lots of conversations and at the end of the next 3 weeks more product was delivered and things were coming together.  Company B was starting to take notice.

Shortly after this some of the Company B people were playing with the software and realised that with what they had already it would be a great idea and would really improve things if they could make a few changes to what they had planned.  They hadn't thought of them before, but now that they had seen the software and how it was shaping up it just seemed so logical.  The vendor was quite happy for the company to add requirements to their list, just as long as the list was re-prioritised and anything they didn't want any more was removed.

This pattern of work for another 4 iterations and at the end of the fourth iteration the CIO and the stakeholders looked at the product and realised that all of their main functionality was already in place.  There were still a lot of items on the requirements list, but they were low priority items and probably not worth the development cost, at least not for an initial release.

After 23 weeks the software was put into production.

As everything that was needed was already delivered Company B decided to terminate the contract and saved around 40% of their budget.  The money saved then went into further efforts to open up a lead in the emerging market giving the company even more of a competitive edge. As for the vendor they became the sole supplier of development services to Company B from that point on.

 

Company B was already up and running with their system and starting to make inroads into the new market before Company A even got the development work started on their project.  Over the next few years Company B continued to push hard providing their customers with regular updates to their offerings, adapting to the changing state of the market and managed to do so at a pace that no-one else could get close to matching.  When Company A finally made their venture into that market it was with a poorly conceived, me-too product that cost way more than budgeted and didn't work anywhere near as well as that of the established players.  Company A withdrew from that market not long after.

 

Before you ask - no, this isn't a story based on any specific companies.  But it is a story I'm sure you can relate to as this sort of thing happens all over the world every single day.  There are still far too many Company A's in this world and we should do all we can to help turn them into Company B's.

I'd love to hear your comments!

2 comments:

  1. Richard, does Readify offer the sort of no fixed price/term, unlimiited scope solutions you describe?

    ReplyDelete
  2. Short answer - yes. But it's not the only option - the best way to find out what they can do is to contact Readify and talk through the options.

    ReplyDelete