IT project failure

March 12th, 2014 at 3:00 pm by David Farrar

The have announced:

The Institute of IT Professionals is currently undertaking significant research into the impact of software procurement on IT project failure and are asking the software community to come together and help answer this question.

The research explores what software factors and characteristics are responsible for project failure, then analyses whether different approaches to procurement in New Zealand might mitigate these factors.  The intention is to determine whether there is evidence that alternative approaches, such as non-price based procurement, would lead to more successful outcomes for software projects than the existing procurement models.

As part of this research the Institute today released a very short survey.

The survey is for those who:

  1. Have been, or currently are, involved in software development in any context or role, OR
  2. Have been involved in any way in responding to IT-related procurement or tender requests.

There are just 3 short sections with a few questions each, and many participants will only be asked some of the questions related to their own experience. If you fall into either or both of the criteria above, we’d love for you to spend 2 minutes helping contribute to this work, which may influence how procurement is undertaken in future.

You can take the survey here: www.iitp.org.nz/spsurvey

I look forward to seeing the research in due course.

Tags:

21 Responses to “IT project failure”

  1. peterwn (3,314 comments) says:

    My son commenced IT and business studies, then went off successfully on another tangent. I told him that a very valuable area of research would be how to devise the design and execution of IT projects so that they did not ‘bomb’. This is something which IT academics should be taking up in earnest. It could be an export winner.

    A useful illustration of how to help project success – UK’s long distance dialling system. Information technology especially as applied to a phone system was still very primitive. Long distance calls could only be charged by using the odometer type meters already installed for local call charging. To keep the necessary electromechanical circuitry to a reasonable minimum, the long distance charging zones were reduced to three. It is now realised similar should have been done with Novapay.

    Vote: Thumb up 1 Thumb down 1 You need to be logged in to vote
  2. leftyliberal (651 comments) says:

    I took the survey. If they think that Agile Development will lead to better outcomes than Waterfall, they’re asking the wrong questions. Fortunately there is the odd “other” categories where one could write such things.

    Vote: Thumb up 4 Thumb down 0 You need to be logged in to vote
  3. freethinker (696 comments) says:

    No Vo pay comes to mind as a beneficiary – any pun is intended.

    Vote: Thumb up 0 Thumb down 0 You need to be logged in to vote
  4. Nigel (517 comments) says:

    It’s misleading the title, they are really trying to compare agile and waterfall. That should be clear up front.

    It’s a complicated question, but I think agile is to development what democracy is to politics, it’s not perfect but it’s better than anything else and at least you have a decent shot at a good outcome, but bad leadership can screw up any project no matter the methodology.

    Vote: Thumb up 1 Thumb down 1 You need to be logged in to vote
  5. Manolo (14,084 comments) says:

    Done!

    Vote: Thumb up 0 Thumb down 0 You need to be logged in to vote
  6. hmmokrightitis (1,595 comments) says:

    Agile is only as good as the people using it – Ive seen and run successful projects with both Agile (and in an agile (small a) and WF way. The application of the methodology is the key.

    The secret to success with SW development IMHO is start small with limited scope. Manage scope downward constantly, as with user expectation, and deliver fast iterations. Users change their minds about what they want like my Mrs – frequently and in great detail.

    And dont offshore development :)

    Vote: Thumb up 5 Thumb down 0 You need to be logged in to vote
  7. Nigel Kearney (1,051 comments) says:

    Obviously I’m a developer so completely biased, but anyway:

    When I started 25 years ago, it was all analyst/programmers, apart from maybe one manager and a tester or two. The project was split into bits and each person did the analysis, design and build of their piece. Before I promised something to a customer, I would have to plan how to build it and make it run efficiently.

    Nowadays a project team will be loaded up with ‘analysts’, who are generally young people with a background in business not IT, have never written a line of code in their lives and even an Excel formula can make their eyes glaze over. They spend their days going to meetings and writing documents. This means that before a developer gets involved, a lot of things have been promised and money has been spent. There will be big documents with lots of pictures and an average of maybe 20-25 words per page of actual text which is mostly crap anyway. Very hard to recover from that.

    Vote: Thumb up 6 Thumb down 0 You need to be logged in to vote
  8. Peter (1,725 comments) says:

    Agile pretends to solve this problem, but doesn’t. Most problems start with management wanting too much, too soon, for too little.

    A lot of pain could be avoided by significantly reducing scope. Ask “do we *really* need this?”. Keep de-scoping until you’ve got core functionality. Built it. Then introduce added features on pain of death.

    From what I can see of NovaPay, the system is not needed at all. Schools could be bulk funded each month and let school administrators sort out payroll with tools like Xero. Simplify teachers pay scales.

    Vote: Thumb up 4 Thumb down 0 You need to be logged in to vote
  9. griffith (1,111 comments) says:

    Scope creep….

    Vote: Thumb up 6 Thumb down 0 You need to be logged in to vote
  10. leftyliberal (651 comments) says:

    Not surprisingly that all the developers here are saying the same things. Did they really need a survey?

    Vote: Thumb up 3 Thumb down 0 You need to be logged in to vote
  11. Dave_1924 (121 comments) says:

    Projects failure for heaps of reasons…

    At the top of the list is demanding the world and wanting to pay for a 1/4 acre section.

    WF and Agile can deliver results – if applied correctly, and without the normal Vendor we can do everything attitude. Limit the scope, build modularly/incrementally and be reasonable in your expectations. Then manage scope tightly.

    Nothing makes Project Manager sigh more than a Business Owner saying “I have been thinking we could add this in to scope” generally during testing when it will cost the most to deliver….

    Vote: Thumb up 0 Thumb down 0 You need to be logged in to vote
  12. Zapper (1,033 comments) says:

    Hard to argue with Nigel Kearney – to me the biggest hurdle to delivering a software project has always been analysts or PM’s, regardless of methodology. If you find a good analyst or PM hold on to them for dear life.

    My most successful projects have been when I’ve ignored everything a PM says and basically been PM myself – not through choice, but because they missed so much I had to do their job for them.

    I’m yet to experience a PM who doesn’t overlook a major aspect of the project, tell the developer(s) this has to be done by Monday morning so they need to work the weekend, then leave at 5pm saying “Text me when it’s done (so I can report to the Business Owner what a great job I’ve done)”.

    hmmo, I’ve followed a lot of your posts since you sound like you are where I want to be in a decade or so and it’s very gratifying to hear you say don’t off-shore development. My current company has off-shored development for a major project that began in 2005 with a 2009 implementation date and is stil a work in progress with a 2015 estimated completion. I’m amazed it hasn’t been canned. Honestly, if I’d started in 2005, developing solo, I could have done it by now.

    Vote: Thumb up 3 Thumb down 1 You need to be logged in to vote
  13. anticorruptionnz (215 comments) says:

    There is a very good reason for soft ware failure. As an anti corruption specialist people come to me from all walks of life. I was approached by a software developer who worked for a very large global software company the company had tendered for and won a substantial contract. to get the contract the developers CV’s were amended to include the particular skills required for the project.

    The developers learn on the job, project went over time, over budget and never really ran well .. who cares its about money isn’t it ?

    Vote: Thumb up 0 Thumb down 0 You need to be logged in to vote
  14. Reid (16,638 comments) says:

    I’d suggest re-engineer the RFP process. Complex design is very difficult to nail down to the degree the current RFP process expects it to be and what normally happens is the vendor and client ends up lawyering up when 20% of the money’s left and you’ve only got 50-70% of the solution delivered to code stage, let alone tested.

    Clients seem to think it’s absolutely necessary to do it the way its currently done because it gives them a contract and a defined budget but that’s just because the client’s don’t have the imagination or inclination to do it any other way and the vendors if they want the business can’t suggest otherwise because doing so would be regarded as irrelevant to the project and the client will just find another vendor to play the game.

    But what the client never seems to get is that software, while engineering, is not mature like construction engineering is. Construction engineering got it wrong for decades in the same way software gets it wrong worldwide, while the kinks were worked out and finally the whole tender-to-build process began to work smoothly after WWII.

    I don’t know precisely what the solution might be, perhaps it’s to do multiple RFPs on large projects, who knows, but my gut tells me that’s the process which is the root cause of failure.

    Vote: Thumb up 0 Thumb down 0 You need to be logged in to vote
  15. nasska (11,822 comments) says:

    Once upon a time, in a kingdom not far from here, a king summoned two of his advisers for a test. He showed them both a shiny metal box with two slots in the top, a control knob, and a lever. “What do you think this is?”

    One advisor, an Electrical Engineer, answered first. “It is a toaster,” he said. The king asked, “How would you design an embedded computer for it?” The advisor: “Using a four-bit micro-controller, I would write a simple program that reads the darkness knob and quantifies its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I’ll show you a working prototype.”

    The second advisor, a software developer, immediately recognised the danger of such short-sighted thinking. He said, “Toasters don’t just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don’t look to the future, we will have to completely redesign the toaster in just a few years.”
    “With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialise this class into subclasses: grains, pork, and poultry. The specialisation process should be repeated with grains divided into toast, muffins, pancakes, and waffles; pork divided into sausage, links, and bacon; and poultry divided into scrambled eggs, hard- boiled eggs, poached eggs, fried eggs, and various omelette classes.”
    “The ham and cheese omelette class is worth special attention because it must inherit characteristics from the pork, dairy, and poultry classes.
    Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, ‘Cook yourself.’ The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs.”
    “Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don’t want the eggs to get cold while the bacon is frying, so concurrent processing is required, too.” “We must not forget the user interface. The lever that lowers the food lacks versatility, and the darkness knob is confusing. Users won’t buy the product unless it has a user-friendly, graphical interface. When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it, and the message ‘Booting UNIX v.8.3′ appears on the screen. (UNIX 8.3 should be out by the time the product gets to the market.) Users can pull down a menu and click on the foods they want to cook.” “Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform for the implementation phase. An Intel Pentium with 48MB of memory, a 1.2GB hard disk, and a SVGA monitor should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built-in GUI, writing the program will be a snap.”

    The king wisely had the software developer beheaded, and they all lived happily ever after.

    Vote: Thumb up 1 Thumb down 0 You need to be logged in to vote
  16. hmmokrightitis (1,595 comments) says:

    Zapper, Ive been dealing with the Indian names like HCL etc for around 15 years. For the basics they are great – and when I say basics I mean like form development, basic infrastructure support and the like. For anything else they need significant hand holding, and whilst their technical skills are largely good, they just dont understand how we think, or have the intellectual freedom we do as a result of working within a totally different environment. I even get my workshop notes typed up in India after a scan and send, over night turnaround, great service at $USD 2 a page :)

    I have seen and heard too many horror stories from the sub continent, and the reliance on forms and their inability to make good judgement calls with no real skin in the game is a real issue. Im seeing more of my clients onshore this stuff now, as they have realised the hidden costs are what get you. Loved the server room in Mumbai that had a sea of Punkah wallahs fanning away briskly to keep temps down :)

    15 + years ago I was at “Global Consulting Inc”, making just over $130K, and spending 200 days a year off shore so some partner could drive the latest Porche and shag his blond PA. Doing the hard yards then was well worth it, now I work 6 to 9 months a year where possible, have a brilliant team, and love what I do. There is real scope for project / programme delivery in this country, and we are seeing huge growth in the IT sector – our export earnings are showing this to be true. NZ’ers are great resources. Our next gambit is to be the offshore service provider for European and US corporates, running a 24/7/365 tier 1 through 3 support model from the provinces. First customers set to go, and we have enterprise server engineers working from home around the country to support the model.

    Doesn’t get better than that :)

    Keep on pushing, its well worth it and a shit load of fun.

    Vote: Thumb up 1 Thumb down 0 You need to be logged in to vote
  17. Zapper (1,033 comments) says:

    Thanks hmmokrightitis, interesting to hear your path. I’m currently leading a support team doing Level 2/3 support for applications used by a contact centre of about 500 or so users. It was a complete mess a year ago but is humming along now so I’m considering going to my next challenge. Previously I worked as a developer in an Agile project and I’m undecided if I want to go back to something like that or continue working in support – I love the pressure of trouble shooting application and/or database problems with 500 people breathing down my neck, but it doesn’t always mean keeping up with the latest technologies.

    Me and a former colleague are considering setting up something ourselves to provide basic Infrastructure and Application support, and I’m getting up to speed with IOS app development for when we get a great idea but it’s tough when working full-time too. The biggest drawcard to that is no PM’s :) The only problem is my location of Melbourne, where things are really slowing down at the moment. Anecdotally though, I’ve heard of so many businesses not doing things anywhere near efficiently, the problem is crowbarring my way in and convincing them to spend some money to save money.

    I’ve also followed your crazy fitness habits too, I’m more of a half-marathon/marathon type guy though.

    Vote: Thumb up 0 Thumb down 0 You need to be logged in to vote
  18. hmmokrightitis (1,595 comments) says:

    You’ll feel the urge to run long, real long ;) Shes a wonderful mistress. Ive backed off a little, dealing with some gastrox issues, and Ive got some target races, run and ride that I really want to do this year and next, turning the big 5-0.

    You’ve reminded me. Just back from the gym, was going to go and play sad bastard for one in the movies, think Ill go run a trail instead :)

    Oh, and as for IT, leverage your network for all its worth, getting that first break is crucial. I worked 14 hour days until it happened, didn’t kill me :) Even do it for peanuts, or free, you cannot beat the experience and a glowing customer telling the world you rock.

    Vote: Thumb up 0 Thumb down 0 You need to be logged in to vote
  19. PaulL (6,048 comments) says:

    Seems like they’re looking at agile v’s waterfall. In my experience either can work. The seeds of project failure are usually sown at the start, when someone decides to over specify in the interests of running a “fair and transparent RFP process.” What that really means is asking the users to write down everything they have today, then having a bunch of light weight internal analysts attempt to turn that into a set of requirements. Remembering that these people, being (usually) internal govt types, will only ever do this process once in their career. They then go to market, and all the corporates reply in an attempt to twist whatever they’ve got into the shape that the RFP asks for, both knowing that what it asks for isn’t what the agency needs, and knowing that what they’re selling doesn’t actually do all the things they’re saying. Then once they win, and having signed an overly prescriptive contract, they sit down to redo all the analysis and attempt to work out what the agency actually needs, and then bend the contract in an attempt to deliver something approximating that, all the while fighting the users who are convinced that there’s nothing wrong with what they have today, so they’d like to preserve as much of it as possible into the future. That’s the govt procurement dance…..

    Vote: Thumb up 0 Thumb down 0 You need to be logged in to vote
  20. slijmbal (1,236 comments) says:

    Nobody said the real issue is that it’s all about internal politics in a large bureaucracy.

    I’m getting on a bit and reckon I’ve had responsibility for about $70m worth of software projects/development over 30 odd years in various forms.

    All the large f*****d up projects I worked on were never truly represented as f****d up and we were not allowed to address the real issues for political reasons until it all exploded as it invariably did.

    Government procurement is a minefield I learned to walk away from as it’s all political – Very large companies ala IBM rely on buying the project up front and then making a profit via change requests for instance. Government or local government customers don’t really care about a successful project they care about appearances. This is also true for large commercial bureaucracies but not as excessive as the profit motive does kick in (less than it should do).

    For instance, I lost a large contract as one large software provider promised to deliver something at a loss and then spent the next 2 years ensuring it delivered nothing and then renogotiated the contract. Of course, the client suffered. This was represented as a success and it is also representative of many large projects.

    Agile can work for departmental projects but most corporates cannot fit it within their corporate level projects’ need for apparent certainty.

    Vote: Thumb up 0 Thumb down 1 You need to be logged in to vote
  21. PaulL (6,048 comments) says:

    In my experience, Agile isn’t really suitable for projects with an external vendor. It’s hard to contract to a fixed outcome and a fixed price if you’re doing agile. So you end up contracting to a length of time and to try really hard. Which isn’t a real contract in govt terms.

    Vote: Thumb up 1 Thumb down 0 You need to be logged in to vote