Redefining success

Posted: June 23, 2008 in Requirements and specifications

I was listening to one of my favorite bloggers today, the podcast from Hanselman is about lean development and starts out about defining success. The first statement is that defining success for a software project to be “on time” and “on budget” is rather misleading. And then goes on to defining success as wether the project is a business success, that is a business case with a positive outcome.

I really like the podcast and it gave me an idea of another way to describe what I blogged about a few weeks ago in my post on UATs and my series on Requirement specification.

I tryed explaining the usual short comings of requirement specifications based on Change management theory, funnyly enough applying the metrics of succes that the above podcast is about would yield the same conclusion.

Usually the requirement specifications are very low level describing small steps needed to complete some function but generally that “some function” is not described at all. “Some function” in this context is a task that the end user needs to perform to complete everyday work.

If you wrongly define success as just being “on time” and “on budget” you might define a project as a success even though that project was such a lousy business case that the company went backroupt, you know that happens everyday. (Just talk to your manager, also know as the  #if the project is not a success we’ll go backroupt” management style)
Same goes for requirement specifications that have forgotten that the most important part is actually the tasks the users need to complete, not every single step on the way.
I’ve seeen numerous projects that met every single requirement but the user found them at best difficult to use. Defining them as a success even though they met all requirements goes against the logic of the users im sure.

I find a good way to measure the success is to “user metrics”. If the system is build to help users perform their tasks faster, then let’s measure how fast the users are when we start the project and how fast they have gotten when we’re done.
If the system is build to make our products easier to use than the competitors, let’s ask the users what they think in regards to usability and so on for the high level goals each project has.

If we start out every project by documenting these high level “user goals” we make it easier for us selfs to review requirements.

When you’ve read the requirements you should be able to do one of three things with each requirement

  • Relate them to a high level goal
  • Discard them
  • Create a new high level goal

When all requirements are related to a high level goal, look at every high level goal and ask your self and the project “do we have all the information we need to meet that high level goal” The answer is probably “no :-)”. At least I found my self time and time again needing information. To be honest I often find my self in that situation when i did not to as I “preach” in this post. If the answer is “no” I for one will in the future try and remember to go out get that information


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s