Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

migrated from stackoverflow.com Feb 16 '11 at 23:44

This question came from our site for professional and enthusiast programmers.

5  
To be pedantic... "issues" are "risks" that have already happened. Issues don't have risk.. they just have impact, and a probability of 100%. –  Mark Nold Mar 5 '09 at 23:23
1  
Great to learn english language in SO! –  alvatar May 19 '09 at 13:24
2  
I don't think software projects are unique. If you are developing a new car a new factory or a new software there shouldn't be a big difference. As long as you are doing something new, with creative and a little bit peculiar people that is not fully understood yet and the goals are not 100% clear. I think the problem with software projects is grown out of the old, gather requirements, code, deliver project cycle. This does not apply to the examples before a building has a maintenance plan, a new car is a research project not a simple write down work... –  Janusz Sep 3 '10 at 14:09

29 Answers 29

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 neat 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.

share|improve this answer
2  
Which means that ultimately the biggest risk to a project is the competence of the people involved. –  MusiGenesis Jan 22 '09 at 14:29
2  
I agree with Jeremy here. Though incompetence and arrogance are big factors for uncontrolled and unmanaged change, the abstract nature of software means change creeps in and permeates much more easily. –  Mostlyharmless Jan 22 '09 at 14:50

Assumptions are the biggest risk.
You assume that you know what your team is doing.
You assume that your team knows what they are doing.
You assume that your team would tell you if they no longer know what they are doing.
You assume that you're doing what the customer asked for.
You assume that what the customer asked for is what the customer wants.
You assume that what the customer wants is what the customer needs (notice that there are already two indirections here!)

More specifically: project schedules. The bane of everything. Your customer or management will hold you to it. Unless you multiply every estimate by 10 and add a safety margin, you're probably not going to finish the whole project before the first project schedule you make runs out.
Why? Because things change, the customer asks for more, team members leave, people take holidays at annoying times, things get underestimated. You can't tell your customer "you can't have your new business-critical feature because it wasn't in the original planning", and you'll find that most of the time you don't want to tell your customer "fine but that will add three months to the schedule". Train yourself to do this anyway. It's not popular with customers, but it's the truth.

share|improve this answer
1  
McConnell calls this "Wishful thinking", i.e. assuming something will fix itself –  Rob Nicholson Sep 29 '09 at 10:49

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.

share|improve this answer

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

share|improve this answer
12  
-1 I've seen more managers kill projects than programmers. –  Stephan Eggermont Jan 22 '09 at 14:19
1  
I'm going to leave this up and see how many down-votes it gets. It's beyond me why people want to pretend that most programmers are competent. –  MusiGenesis Jan 22 '09 at 14:25
1  
MusiGenesis: It doesn't mean all programmers are competent, but a single stupid dev can hardly be the reason for a large failed project –  LeakyCode Jan 22 '09 at 14:27
  • 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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer

Politics

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

share|improve this answer

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

share|improve this answer

Users.

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

Involve them early and have user acceptance testing asap!

share|improve this answer

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

share|improve this answer

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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).

share|improve this answer

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.

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

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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

The highest risk today is the gap between the technical community and the business. The number of translations of the requirements that happens from business mouth to the developer's desktop impact the way software is developed. Most often, when you discuss the issues with developer you will find his problem is genuine and requirement is not gathered properly. On the same lines when you speak to business user you will feel his concern is valid as well.

Hence the process of translation needs to be improved and as the industry is maturing there are better methods like Agile which are being practiced.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
1  
I think he is talking about code generation... but in that context success cases also exist. –  João Portela Sep 3 '10 at 21:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.