Tuesday, August 7, 2012

Great or Successful: Lessons from the Olympic Games

This week's achievement of Michael Phelps at the 2012 London Olympic Games to surpass Larisa Latynina's record of a total of 18 medals in a Olympic career has made me think about how we determine success of information systems development (ISD)  projects.

Phelps now holds 22 Olympic medals, 18 of which are gold.  So without argument he is currently the most successful Olympic athlete if measured by the total number of medals received in a career.  There starts the trouble.  Olympic success has never been defined to be measured as the total number of medals received in a career.  It has not even been defined as the total number of gold medals won in a career (which Phelps also holds the record of 18, compared to Latynina's next best total of 9). It has not been defined. Viewed in isolation it might be easy to say that it is obvious, having received the most medals he must be the greatest Olympian in history (as is being said by some)!

To put this in perspective, consider some of the records Phelps does not hold.  Latynina still holds the record for the most individual medals (i.e. not medals received in team events, so medals received by your own achievement only and not by a group's achievement).  She has 15 individual medals, whereas Phelps only holds 13 of those.  On a totally different track, Ian Millar holds the record for the most times an athlete has qualified and participated in Olympics, so he holds the record for the longest Olympic career, having taken part in 10 Olympic Games.  Phelps has only participated in 4 Olympic Games.  Which of these are the correct measure of Olympic success, to be able to say one of these three are the most successful Olympic athlete?  Then there is the question of greatness, which probably lends a more philosophical nature to the debate. 

It is common practice in ISD projects to define success in terms of the goals of the project.  Given the Olympic goal stated as "...to place sport at the service of the harmonious development of man, with a view to promoting a peaceful society concerned with the preservation of human dignity", it seems none of these measures of success as achieved by Phelps, Latynina or Millar is in any way related to the Olympic goal.   It would seem that Jesse Owens's achievement of 4 gold medals at the 1936 games in front of Adolf Hitler, that embarrassed Nazi Germany who wanted to prove Aryan supremacy with the games, achieved the goal much more than medal counts.

So what is the measure of your ISD project's success?  Is it success to have done what the contract with the customer asked (if your lawyers can prove you have done so)? Or is it success to have developed what the spec asked, even though the users did not get what the really needed?  Is it success to have built a system which works and functionally does all it needs to do, but the users hate using it and constantly complain about the system? 

The Project Management Institute (PMI) proposes a list of factors that indicate success:
  • Stakeholder and customer satisfaction;
  • Meeting business case objectives;
  • Customer/end-user adoption;
  • Quality of delivery;
  • Meeting governance criteria; and
  • Benefits realization.

The normal criteria for making sure the project is delivered on time, within budget and to the required quality (i.e. scope) does not measure project success, it measures project management success.  Project success has to be measured on business outcomes.

How about next time we build a GREAT system, instead of just complying with specs or contracts? But remember to first define what would make it great, and then do it.  It is going to require a team working together to each do their part and contribute to the greatness.  A great BA doing a great spec, a great UX specialist designing a great user experience, a great architect producing a great design, a great developer building the system to perform great, a great user to provide enough input and participation to the great team, and a great tester to make sure the quality is perfect!

Be great!

About the author
Pieter Kruger is a Manager at EOH Microsoft Services.  He has worked on various projects for the company over the past 8 years, mostly in the role of Project Manager.  He is passionate about delivery, client satisfaction and user participation.   He believes we should consistently improve and work towards doing IT right.

1 comment:

  1. I agree with you that it takes everyone's involvement to make a great system, from the BA to the end-user.

    That's why its so important to get everyone involved as soon as possible in the project's lifecycle.

    I've found that too many projects have the developers working for months on their own and then only at the end the user gets a peek at the system.

    This causes misalignment between what the developers are building and what the users are expecting, causing the product to be perceived as low quality in the only eyes that really count at the end of the day - the end-user's (ie the ones that are paying for the system to be built in the first case).

    However, I've also found that getting everyone involved is often much easier said than done!

    One solution I've used in the past is to get the users involved as non-formal testers of the system. If you can make the system useful to the end-user as soon as possible in the projects life, even if it only does one simple thing to help the users, it'll at least get them to start using your system, get them involved, and get them to start providing feedback

    Getting the end-user involved like this helps to increase the probability that the final system will be of high quality in their eyes, and actually relevant to their needs.