What issues carry the highest risk in a software project?

Question

Clearly, software projects are different from other industries in terms of many things like for instance, quality assurance, project progress measurement, and many other things.

Unique characteristics of software projects also makes the risk management process unique. Lots of issues in a project might lead it to unacceptable delay or failure to deliver business value. They might even make a complete disaster in the project.

What are the deadliest risk factors in a software project? How to analyze, prevent and handle them? Particularly, I'm interested in the issues that you can detect from the beginning and you should keep an eye on (for example, you might be told about a third-party API that the current application uses and lacks documentation).

Please share your experiences if they are relevant.

Answer 1

Failed software projects are almost always the result of programmers and managers who don't know what they're doing.

Answer 2

One often overlooked problem is legal clearance for using third party APIs, licensing etc. When several large companies are involved then negotiations can take months, if not years, which can really mess with your release schedule.

Answer 3

No clear mission statement and lack of support from upper management of the customer.

No commitment to get requirements right and prioritized is going to kill every project. Getting the wrong people involved sure helps. Having someone around who claims she's seen lots of contractors come and go, and is not willing to put in any effort to contribute.

I've had to start doing software archeology for a project where there basically wasn't anyone around anymore who understood the whole system. That's a lot slower than the normal way of working...

New technology for technology sake is also a nice project killer. Not all technology works as well as the marketing brochure

Answer 4

Change. Especially, unmanaged, uncontrolled change are a huge risk. You can embrace or control change but don't ignore it.

Edit: Extended answer with example (as the OP asked for one)

As I said in the comments, software is abstract, especially to people who don’t work writing it. With something physical it is easy to see the progress and barriers to change. Once you are half way through building a bridge you are not going to change where it is sited but with software it is much more difficult to justify resistance to change.

For example. Once I was writing a system where in one place the title of an object was to be displayed along with links and some other detail. So I designed and engineered it to bring back the title and the other information. This solution was fairly need and simple. Towards the end of development the requirement was changed so that in some cases the category would be displayed with the title. To me this required a lot of rework or a nasty fudge in the system (making it more susceptible to bugs and less maintainable) As far as the business was concerned there was just some more text on the page, so they saw no reason for our resistance to the change.

This sort of thing happens all the time as most people don’t understand how software works, they don’t understand why it is difficult and risky to change it late in the day, but with more physical projects it is intuitive.

Answer 5

You need to keep a close eye on your dependencies on third-party components, particularly if they are specialized ones that may have very few other users who are doing exactly what you are doing, and that may be difficult or impossible to replace.

If there are any bugs or gaps in the features you need for your system, you will be at the mercy of the vendor's schedule and ability to fix their product. The earlier you can explore the whole surface area of your contact with any third-party components, the better. Problems in your own code may be challenging to fix, but at least they are under your control. With vendor problems you usually can't do much other than wait and complain.

Answer 6

Thinking that you gathered all requirements and being sure the client told you everything you need to know.

Answer 7

Anything that involves money or credit card payment. Keeps me awake at night :(

Answer 8

People & Communication

The programmers need to be able to program. The analysts need to be able to communicate to the customer in a way that pulls out what the customer really needs. Then the analysts need to be able to clearly communicate this to the programmer.

Answer 9

Basically it is not that difficult - otherwise no project would ever succeed. What you need to watch out for is:

• clarify the aim - before AND during the project
• decide what tools you use (programming language, dbms, etc.)
• are you and your co-workers qualified enough
• scale of the project (how much data, users, objects, etc. do I need to handle)
• keep track of what you are doing
• test, test, test and test
• use the appropriate tools
• do not "over-engineer" the solution (you don't need a "full-blown solution" for displaying some lists of - let's say - bank account transactions and modifying the details of the bank accounts)
• clearly define the official paths of communication
• define the responsibilities
• estimate everything you want to do and record what you actually do (see mcconnell software estimation)
• try to have a stable project-team - every co-worker lost is knowledge missing

From my expierence these are the things that troubled my developer-life the most. Ah - yes and try to keep the truck-run-over-count as high as possible - so share the knowledge about the code and especially the business-logic. code is mostly self-explanatory - but as a developer you may not know the big picture.

Answer 10

Users.

No matter what you build, they will use it differently to what you expected.

Involve them early and have user acceptance testing asap!

Answer 11

New, new to us, and known technologies used in new ways.

You can minimize these risks by doing proof of concepts apps in the design phase. These small projects will also serve as a communication tool in the future on how something should be done.

Answer 12

• Lack of planning
• Skill/Resource shortage
• Ineffective communication among stakeholders
• Failure to get a full understanding of the requirements

Answer 13

anything you don't understand is a risk factor; this includes things that aren't specified well and things you've never done before and things with insufficient documentation etc.

mitigate the risks by planning for and doing - up front - investigation and prototyping (a "spike" project in XP terms)

be prepared with a fallback plan if the initial direction turns out to be infeasible

Answer 14

Change is a big one. Changes need to be controlled. They can't be eliminated, but the cost of changes must be understood.

Unrealistic assumptions are another biggie, in particular unreasonable schedules. These are typically imposed externally, although programmers are notorious optimists themselves. I worked for a company once that understood software development well, but the sales staff got out of hand selling custom modifications, and that was bad.

Lack of process, or bad process. This is particularly true of larger projects. Gathering requirements first and coding like heck can work on small projects, but it doesn't scale.

Lack of commitment from the rest of the enterprise.

People, whether incompetent, uncaring, or just jerks.

Answer 15

Missing the following can make a s/w risky

1. Extensibility
2. Change Adaptment
3. Clear goal of software
4. Try using the software as End-USER
5. Expertise in that domain

BTW making proper estimation of Time and effort to build the software also holds an important key for successful project.

Answer 16

Marketing.

Answer 17

• Organizations that treat talent (not just programmers) as resources that can be swapped in based on job title. This is really quite common, although it's almost never as 'coarse' as my description. The common manifestation is: We're running late, if we add these 5 guys who have never even seen this project, I'm sure we can pull it off!
• Orgs that think it can be done on time because of the technology they've chosen and not the quality of the staff. This happens less now, but there was a time when 'hard projects' were believed to be 'easy' if they did them in Java instead of C++. The reality is that a bad team using C++ would fail quickly. A bad team using Java would still fail - but it took a long long time. A good team would finish with either tech, and would finish sooner if allowed to pick the right tech for the job.
• Re-Engineers. You know these guys. They see code that works, but isn't what they would have done - so they re-write it, or wrap it in a bunch of fluff to make it what they want it to be. It doesn't matter if they are right or wrong, this kind of inflexibility ends up with tons of code churn, but very little progress. Some code is so bad it needs to be re-written. But usually you can wait until a feature would take you through the 'eh' code and work it then since you were going to have to mess with it anyways.
• Being micro-managed by a customer. Small companies have this problem the most. You are the little guy - you need that money. Too bad the customer calls the project manager every other day and changes something. Had a bad spec/agreement - To be expected. Had a great spec/agreement - well no, so what. Big guy says 'I want it changed or I'm cancelling the project!' - your business guys will cave. This is a real tough one. If you don't get to make most of your product before end customers get involved, it's a mess. Customer driven projects are better done under a time based contract where you can just set your soul aside for awhile and roll with the changes.
• Sales guys obsessed with selling what you haven't made. Sales guys love to get excited. They've seen the product. They aren't excited anymore. So what that the customer hasn't seen the product and will be 'super-excited'... the sales guys need to go invent a bunch of stuff that doesn't exist and sell it. They can't seem to come to terms with the idea that the customer is not immersed in the developed product and will be excited.

Those are the worse ones I've seen.

There's always the death-by-meeting orgs, but I think Dilbert has that sufficiently covered.

Answer 18

Based on research (Capers Jones http://itprojectguide.blogspot.com/2008/11/caper-jones-2008-software-quality.html) the top issues are bad requirements and bad design - without a good base to work from the project is doomed. Most rework, scope creep, etc. is due to missing information during the requirements and design phase. The best way to address this is through requirements, design and code reviews - adhoc is better then nothing, but there are systematic approaches also.

Answer 19

I have seen project that were on time, on budget and covered 100% of the requirements AND failed big time. When we did a post mortem it became very clear that the client's representatives were focussed on their part of the system and nobody cared about the flow between the subsystems.

So my prioritized list looks like this:

• Unprepared customer
• Fluffy requirements
• Scope creep
• unstructured change request handling

Technology and project methology is insignificant compared to the power of bad requirements

Answer 20

Here are a few that I've seen over the years:

The evolution of the end result - How well can the project sponsor articulate the final result of the project? "Build me a way to track inventory," leaves a lot open to interpretation. Similarly, a group of business users may not understand all the things that a CMS can do so the end result will change as the project progresses.

The evolution of the resources - Are things like time, money, or scope really fixed or is there some flexibility there to handle things if the project goes off track. Maybe some people on the project want to take vacation or leave the project for a change that can impact things as if the lead goes away for a month, that likely will change things for a while.

The evolution of process - How are we going to do things and will this shift over time? Generally, the answer is yes things are going to change as a team dynamic emerges and things get done, but the flexibility has to be allowed here. There may be some places where the process is so fine tuned that it just works and there aren't problems, but I haven't seen that place yet.

The handling of failure - If something doesn't go right, or some major problem is found, how is that handled? Generally there will be errors or things not done right initially and this has to be accepted.

Answer 21

Politics

If good reason does not prevail, because it is unpleasant to hear.

Answer 22

Not a direct answer to the question, but all developers interested in why projects go wrong should read "Rapid Development" by McConnell. The list of classic mistakes is listed on the web as well - slightly updated from the book http://www.stevemcconnell.com/rdenum.htm

From memory, McConnell sites "Lack of planning" as the most common reason projects fail.

Cheers, Rob.

Answer 23

Lots of good stuff already listed but I'd also add external dependencies:

• Interfaces to other systems (particularly when unproven or unknown)
• Deliveries by other companies (for instance a graphic design company when you're doing a web site)
• 3rd party contractors when they're not under your close management

These are all areas I'd allow extra time from both in terms of slippage (that is they WILL deliver late) and effort (what they deliver won't be up to scratch and will need you to help them resolve / rework / test / analyse it).

Answer 24

The two causes of failure that immediately spring to mind for me are:

• Not creating the software iteratively with the customer. This means delivering a real working feature with each iteration, and ideally the customer trying out the software after each iteration. This prevents the case where something is released after 2 years of work to discover it's nothing like what the customer actually needed.
• Not making the software easy to change which starts with good code factoring (DRY etc) and good test coverage.

If both of these common agile methods are fulfilled, you should have something the customer wants at each stage, or at least it will be relatively easy to make the changes required to make it so.

Answer 25

I'm sure most developers would agree to, after a project has been completed, you always think of things you would have coded differently, that would have saved you time etc. From my experience, one of the biggest factors that leads to failures in Software Development is inadequate preparation. Most often this comes from time pressures, low-budgets, which leads to cutting corners. Again, as most developers would agree to, we do not develop in a perfect world, with perfect budgets and ample time constraints, however having said that, you must start of with at least a plan that can be followed and tracked against.

The second reason I think Software Development fails is lack of communication. Without a clear line of communication, from team(developer) level, through to project managers, account managers, clients, or even developer straight to client (if working alone), will bring down a project faster than I get an answer on stackoverflow! With, I'm sure, many advocates for both Waterfall and Agile development, and having worked with both, one of the things that works best for both, is having daily communication catchups. This ensures the whole project team is aware of what has been achieved, what will be achieved, and how to achieved.

Answer 26

I'm sure most developers would agree to, after a project has been completed, you always think of things you would have coded differently, that would have saved you time etc. From my experience, one of the biggest factors that leads to failures in Software Development is inadequate preparation. Most often this comes from time pressures, low-budgets, which leads to cutting corners. Again, as most developers would agree to, we do not develop in a perfect world, with perfect budgets and ample time constraints, however having said that, you must start of with at least a plan that can be followed and tracked against.

The second reason I think Software Development fails is lack of communication. Without a clear line of communication, from team(developer) level, through to project managers, account managers, clients, or even developer straight to client (if working alone), will bring down a project faster than I get an answer on stackoverflow! With, I'm sure, many advocates for both Waterfall and Agile development, and having worked with both, one of the things that works best for both, is having daily communication catchups. This ensures the whole project team is aware of what has been achieved, what will be achieved, and how to achieved.

Answer 27

I've heard about various attempts to write scripts in one friendly language to run code in a less friendly language like c++. Both attempts I've know about have failed. Should be obvious I know.