3 October 2007

Software Product Success Stories - a meme

In what has the potential to be a very inspiring post, Scott Sehlhorst at Tyner Blain has challenged us to tell a story about when we helped make a product successful. It will be a nice counterpoint to all the stories of project failures and disappointments.

The rules of this meme are simple; tell a true story of something you did that made a product successful or more successful than it was otherwise going to be. Be specific. Be anonymous if you want to. Read the details here.

As you'd expect my example of something I have done that has made a product more successful is comes via a project…

Focusing on outcomes rather than processes
When you work in a large bureaucratic organisation process often becomes the way you think, let alone the way you work. Here (and at Tyner Blain) we believe that following the processes reduces risk but often doesn’t get you to the end game.

In this story, before I turned up the team had followed a usual corporate waterfall approach of getting high level requirements, and chasing down estimates from developers and infrastructure people. The tool was going to be a simple web interface to back end systems with existing interfaces all built and ready - that a small business could put together in a week. It was quoted in the millions.

The team had followed the business process and come up with an outcome that wasn’t going to fly.

I was invited to participate. My job was to look at the requirements, which I was already reasonably familiar with, and find a cheaper solution. I worked with the lead business analyst on the team, who was smart and capable, but having been on the job for a while, and led by a PM who had a strong “follow the business process” orientation he hadn’t been able to get to the right solution.

We worked together and started with removing the constraints of the local business processes. Then we looked at the end outcome; which was the main functions and the constraints of time and costs. I drove the agenda that the solution should be cheap and quick, because we knew it should be.

A bit more work with an external solution provider; getting a prototype up and showing the key stakeholders what we were intent on building, and we had endorsement to go ahead.

We had gone outside the usual processes – going to an external vendor without documented scope and business requirements, building a prototype off verbal requirements and come up with a solution less than 20% of the initial estimates. And our lead BA was now re-invigorated and led the team (under a new PM) on to an on-time, on-budget on-scope (
OTOBOS) delivery that met all the business needs.

My time on this project was brief – about two months but it brought me satisfaction in that it set a new precedent for getting things done properly, shifting the view from the mandated processes to targeting business value, and it enabled an excellent BA to move outside the constraints that he had found himself in, and to again become motivated about the work.

Tag you’re it; Mike Ramm, Elizabeth Harrin, Bas de Bar, Pawell Brodzinski, Rajeev Sing and Adrian Marchis. (Don't forget to link back here and to Tyner Blain. )


  1. Thanks for sharing Mike.

  2. Thats so true Craig.

    I often feel bounded and handicapped by processes... and have pften realised that given the freedom I would have done it the other way.
    Thanks for sharing.
    Its definitely something to write about :)