Why Do Software Development Projects Fail? Again? 1

[LNBruno]

If the CFO rules, as appears to be the driving force in most organizations, then the cost of business software development (BSD) has to be offset by a Return On Investment (ROI) generated by the end product.

I have seen BSD projects fail for the following reasons (not inclusive or in any particular order, by any means):

1) loss of key team member
2) adding team members to accelerate production ("throwing more bodies at it")
3) unexpected problems with technology choices
4) undocumented "critical" requirements after development starts
5) a shift in target user group
6) failing to address more difficult issues early enough (doing "the easy stuff first")
7) trying to address code defects (bugs) as "next release" issues
8) pushing "lessons (not) learned (from every other project failure)" to a proposed next release which requires a cost-expenditure (time and money) exceeding any anticipated return
9) a prototype actually becoming the product (too much time and money spent developing it to throw it away)
10) some RAD development process locking the BSD into an I/O of data which prevents flexibility (change, as described below)
11) development without commenting or documentation making maintenance and implementation of new features cost prohibitive
12) adoption of policies and procedures which lock developers into a specific technology (which may or may not survive the next X years)
13) attempting to re-engineer outdated code which can take as long or longer to produce the same features (a zero-sum gain)

How many BSD projects have their ROI calculated over a fixed period of time? It may take six months to develop a product that ends up having a life expectancy of five years. Where is that in the typical "12-month return" equation? Some applications are band-aided to reach a 10-year life. How does that figure in?

Added features drive up the cost, sometimes to the point of creating a negative ROI. But often those marginal gains prove to be breakout points for organizations in an industry - the "AH-HA!" moments that thrust an organization to that "next-level" of success.

Business is fluid. Providing a level of (not data-centric, but business question-specific) information only serves to raise a whole new set of questions. Change is not only a constant in business, it is (and should be) a requirement for the data (information) providers. And yet, any change in a BSD project increases costs which, in turn, jeopardizes the support for the effort.

If the result of BSD is viewed as a corporate asset, the value of which is dictated by a positive ROI, then do any really succeed?

If so, how?

< M!ke >
I am not a hamster and life is not a wheel.

 

[prjman]

Great Post,

# 1, 2, & 3 are really where it all lies in my opinion. In this very dynamic industry, it's super easy to lose a great resource (who opted for a higher pay somewhere else) in the middle of a project. As for #2, adding more resources often creates more problems and delays things, as if you're in the middle of a project, the learning curve might be fairly steep to integrate those new team members, that may or may not want to get integrated. As for #3, I also totally agree, technology choices that might seem very logical at the beginning, turn out to be a nightmare in the middle of road. I've seen all 3 points in the same project. The project eventually succeeded, but it took 3 times more money and time than originally planned.

http://www.pmhut.com/

- The Project Management Hut

 

[AlexCuse]

I am the only developer here (as well as a few other things), and I think the main reason why projects seem to fail in this kind of environment is because users don't get how complex the projects are.

Another problem is the fact that I have several projects on my desk at once, and I am expected to devote 100% of my available time to all of them...

To make matters worse, there is no clear prioritization for these, it tends to be just whoever was the last to bug my boss about something, that is the project that is most important to work on.

I just got an idea for something to bring up at my next status meeting

I don't do any programming whatsoever

Ignorance of certain subjects is a great part of wisdom

 

[LNBruno]

Good luck with that, Alex!

< M!ke >
Your right to an opinion does not obligate me to take you seriously.
- Winston Churchill

 

[AlexCuse]

I already brought it up, and it was well received.

If you mean the other things, there is no helping me ;-)


I don't do any programming whatsoever

Ignorance of certain subjects is a great part of wisdom

 

[JoeAtWork]

Something that happens to me quite often:
1. Requirements gathering: interview users, have meetings, go through iterative questions & answers, etc.
2. Write up Requirements documentation, including mock up screens, and detailed description of the application's behaviour
3. Distribute Requirements documentation, ask for feedback, amazingly everybody signs off on it
4. First release of the program. I review the Requirements documentation and check off each requirement that has been met
5. Users try it out. I get a long list of things that "don't work right" or need to be added. Needless to say, everything on the list contradicts the Requirements documentation, and the things that need to be added were never once brought up.

More often than not, users are not able to describe to me what they really need until they see version 1.0 in front of them. A lot of time would be saved if the users would actually read the proposal and try to match up the described behaviours with their actual business processes.

 

[Chance1234]

Poor leadership



Chance,

F, G + [sub]H[/sub]H

 

[JedSimms]

Many of Mike's points are excellent tactical reasons why projects can fail

Having researched this for 18 years from the business strategy perspective (measuring failure as not delivering the business outcomes and benefits expected) the principal causes of failure are
1 Wrong or inappropriate scope at the outset
2 Inadequate business requirements
3 Poor business cases (missing much of the value)
4 Project plans disconnected from the business case's value proposition (ie the project is not focused on delivering what the business expects)
5 All of Mike's tactical reasons
6 Poor organisational change management
7 Poor business project governance

A pretty horrible list considering we've been doing this for over 50 years!

NB The project can be 'successful' in terms of delivering its outcomes, but unsuccessful from the business' point of view as it does not deliver what they wanted, needed and expected.

And its mainly their (the business') fault. But what do we do to enable them to lift their performance? This is where I focus, uplifting org's project delivery capability to try to get them to do their (project-related) jobs

 

[buitenhek]

ROI is the corner stone for any company in business to make a profit. However, ROI or return-on-investment usually has a time limit associated with it...as do most savings plans. Business plans are really not savings plans and should be treated differently.

To opine a solution, gross profit margin.

The gold standard for any company GPM "has" always been 30%. However, if you bid a project and expect to get a 30% GPM you will quickly see that you will not win many competitive bids. Shoot for a 20-25% margin and ask your employees (techs, PMs, buyers, etc) to figure ways to safe money so the cost goes down and the profit rises. You can even build in a bonus structure that compensates for innovative solutions. Your employees are a company's best asset, the product is second. With a known GMP, Finance will know that any project will have a known target they can track.

Regards
Peter Buitenhek
ProfitDeveloper.com

 

[BNPMike]

Always an interesting topic. One thing I would say is you have to be careful what you mean by 'fail'. Many big projects just die without anything implemented but a lot of other 'failures' may just be things that cost many times what they were budgeted and took a lot longer. This is not so much a failure as self-delusion in the first place. Maybe we all feel we could do projects ten times better than other people (I do) but they're entitled to take ten times longer if that's the way their organisation works. If their project over-runs by a factor of two then maybe the first question is why somebody under-estimated it. There are many other ways projects can go wrong but one of the most important is stupid budgets up front.

 

[supermenon]

I dont know if this already mentioned in a different form: But I have noticed many project fail due to project process over-kill.

I remember when I was a developer and I had to make a change (as a result of change control), I had to get approvals from 5 different stakeholders and each of them have their own philosophy they want to impose to make the change control. After this huge, time consuming red tape process, when I finally get the change approved -QA team has a concern. Once thats solved, then the change is to be presented to the Change Control Board which was headed by a PM, who just recently passed PMP and he wants to go over every small detail for change control process as prescribed by the PMBOK.

In reality something that could have been accomplised in 2 hours max, takes 2-3 weeks.
Glad all these were in-house projects and not client related.

Now as a PM, I encourage and promote streamlined processes for my projects.
My philosophy is "more from less, without losing any functionality in between".

Works for me...!!!

 

[prjman]

Here's a great article on why IT Projects fail.

http://www.pmhut.com/

- The Project Management Hut

 

[prjman]

Got another article on the subject: Failure Causes in IT Project Management. I like this one a lot as it discusses main failure reasons at different maturity levels.

http://www.pmhut.com/

- The Project Management Hut

 

[vpneloh]

I've seen alot of resource stealing by departments like R&D who could care less about the company making money or successfully deploying a product. I have also seen multiple chains of command, PMs who never get the sponsor to effectively communicate their support or sign of on the authority of the PM, and the ultimate killer is the changing of the guard at the Executive Level mid-project.

http://wirelessmms.blogspot.com/

 

[Alcaeus]

Very interesting discussion here. I advocate that there is a big difference between a project failing and a project going not meeting some of the expected parameters of Time, Quality and Cost (in effect anticipated ROI).

I have actually been discussing it on my blog this morning!.

http://alan-fuller.blogspot.com/2008/06/big-projects-go-bad.html