RSS

It is more important to deliver value than to deliver on-time and within budget

16 Jul

I have placed a link below to an article written by Tom De Marco.  It raises some very interesting issues.  I think one of the most important issues it raises is pertinent to my thoughts on how important it is to have a proper, and is far as is practicable quantified, business case for any software project.   Please please please establish the business case before attempting to estimate the cost/effort of a project.  I also feel the article presents a strong argument for agile approaches (please note the small a) to the development process ….. processes that are nimble, flexible, collaborative, non-bean-counter-driven, focussed on delivery of value

Check out this article from Computing Now:

http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r

Also: a reminder … have a look at this link (first posted by Shane)  http://www.cio.com.au/article/205313/why_projects_fail_part_three_wrong_targets

Posted by John Watson

Advertisements
 
 

Tags: , , , , ,

6 responses to “It is more important to deliver value than to deliver on-time and within budget

  1. Martin Proulx

    July 16, 2009 at 1:17 pm

    Although delivering business value is critical, I am not comfortable with your statement. Driving for a single objective without constraints or control mechanisms can lead to very bad situation. Imagine the scenario.
    Boss: “Team, the project is late and over budget. What’s going on?”
    Team: “Sorry, we realize we are exceeding our timelines and budget but just wait until you see the business value we will deliver…”

     
    • John Watson

      July 16, 2009 at 1:51 pm

      Quite right: we must have constraints and controls.

      The question then is, “Where do the constraints come from?”

      The answer to that question is “The constraints come from the business case”

      Next question, “What is a business case?”

      Answer, “The description of the value that the business is seeking to gain from the project effort and the stated spend limit.”

      Question, “Where does the spend limit come from?’

      Answer, “The spend limit is the answer to the question “What is the most we are prepared to spend to gain the value?”” Presumably some variation of return on investment principles will apply.

      Having produced a business case (thus getting constraints) the control then comes from frequently, iteration by iteration, asking, “Given what we know now (feasibility, cost,progress rate…), is it still worth proceeding?”

      In the end,we must have a factory that produces widgets (i.e. delivers value) rather than building a widget producing factory.

       
  2. Sharon Robson

    July 21, 2009 at 2:17 pm

    This is also an aspect of project delivery that Testing has to consider. The usual focus for testing is recieved via a directive to “remove all defects” – we know we cannot do that (a topic for another discussion) but we need to make sure that the testing that is applied is appropriate to the project’s goals and constraints. We can deliver great software – too late and too expensive and the customer will be dissatisifed. In ISTQB terms it’s called the “Absence of Errors Fallacy”. We need to know what makes the customer happy and then focus our approach to meet that need. It is probably called the constraints when we are discussing time and money. There are also legal and other aspects that need to be considered. Business Value is much more difficult to assess – but does need to be considered, even at the individual team member level.

     
    • jwpegasus

      July 21, 2009 at 3:59 pm

      We do seem to think alike. It is really rather a waste of time to produce a defect free product that does nothing for the business.

      I think the issue highlights the difference between validation and verification.

      It seems to me that too often we deliver products that conform to the requirements stated in the system requirements specification (or its equivalent)…. verification …. product built right: but the product itself is invalid… wrong or no process/technique used to validate the product.

      On our BSA, EBR, UCR, and SPM courses I always stress the desirability of performing business outcome realisation testing (BORT). Clearly this cannot be done until some time after the product has “gone live”.

      The point, of course, is that BORT cannot be done unless there are good business requirements which naturally must focus on benefits to the business and not on features of the product.

      How do we get this message across in a way that will encourage project governors to alter their to date sloppy behaviour?

       
  3. Sharon Robson

    July 21, 2009 at 7:00 pm

    It is the challenge, but it is getting easier these days. We, as testers, just keep on asking “how will you know…” to each of the requirements. If they (the business) cannot tell us how they will know the requirement has been met, then the requirement is either redundant or needs more refinement. The key thing is getting access to the people who write or “approve” the requirments BEFORE the system begins development. That is what I really enjoy about agile…you are there asking these questions all the time!

     
    • John watson

      July 22, 2009 at 9:37 am

      I think there are two different “how will you know…?”questions.

      1. This has to do with product testing at various levels and is, “How will you know the product is good?” To answer the question, as you have said, the product requirements must state measurable acceptance criteria and the question needs to asked over and over again…agile.

      2. This question should be asked first, has to do with outcome realisation testing, and is “How will you know your business has improved (through use of the product)?”. It is really the questions “Why are you intending to get the product?”; “What’s the product for?”; “What business outcomes are you seeking?”

      My experience is that too many projects start off with a business case that is so vague that it is useless as a basis for project governance. I do feel that “agile”, used appropriately, can alleviate the problem but only when project owner/sponsors realise their responsibility to provide specific and quantified business outcome requirements.

      It comes back to the discussion about having a brick producing factory versus having a factory that produces bricks. Having and running the factory will not make money. Selling produced bricks might make money (right bricks, right market, right price …)

       

Leave a Reply

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

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

 
%d bloggers like this: