Thursday, 30 January 2014

Value

One of the things you hear when developing software, especially in an agile environment, is ensure that you are delivering business value .

But what is business value?

Does your team understand “the value” that a piece of work will provide? I suspect not but here’s the dirty little secret in most companies neither do the business.

The issue with the business not understanding the value of “your work” or a project is that even if the project is delivered on time and with all the features that were asked for it can be a failure as it doesn’t actually deliver the value the business needs.

Part of the problem is the term value in the first place, what does it refer to? How do you define value?

A bit like Phaedreus’ quest to find a definition of Quality in Zen and the Art of Motorcycle Maintenance you could spend a long time searching but not come up with a definitive answer.

What you can say with some certainty is by the time a team starts development if the value relating to that piece of work hasn’t been defined its too late, the team is building what has been asked for and its costing the business money and you have no idea if it will deliver value to the business.

The time to define the value of the project is when its proposed, what value will the business get from this project? it could be things such as:

  • Gain new customers
  • Retain existing customers
  • Be seen as “Thought Leader” in the sector
  • Increase specific revenue
  • First to market

When you understand value of the project you can proceed to create the goals of the project and the value each goal brings, the features for each goal and the value each brings and so on, you get the idea.

What is key here though is to communicate this value to everybody involved so that not only do they understand the value of what they are delivering but crucially are then able to make judgements about that work, should they take approach a or approach b? what does each approach contribute to the overall value of the project?

So next time you start a project ask about what value is being delivered, you never know it may just help you deliver a project that actually delivers the value the business needs.

2 comments:

  1. Nice post Nathan. I completly agree with your premise but would swap the word 'value' with 'why'. When you do this and people buy into the 'why' it allows delegation of decisions to the team or business to achieve 'why' which actually allows more innotive solutions.

    Using 'why' also then scales up to the business as a whole. It is amazing how many places know 'what' they do but not 'why' they do it. Examples are companys like Kodak and Yell who lost their 'why' and concentrated on 'what' they did (film not taking pictures, paper directory not putting customers in contact with businesses) and missed the opportunity to innovate to use better processes and technologies to achieve the 'why'.

    Remember why people :)

    ReplyDelete
    Replies
    1. I'd go so far as to say I think that both need to be thought about.

      I'll explain, asking why is a good starting point "why are we wanting to build/make this ?" which can mean you can end up with a perfectly reasonable answer to this but then you also need to ask the question what value is there in this?

      To my mind a why question should give you a reason for doing something, but the value part then gives you what you should get out of this and ideally something that you can measure to see if you achieved what you wanted.

      Make sense or am I just rambling? :)

      Delete