StackOverflow sees quite a few threads deleted, usually for good reasons. Among the stinkers, though, lies the occasionally useful or otherwise interesting one, deleted by some pedantic nitpicker - so I resurrect them. 👻
Note: Because these threads are older, info may be outdated and links may be dead. Feel free to contact me, but I may not update them... this is an archive after all.
What issues carry the highest risk in a software project?
Question asked by Mehrdad Afshari
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.
Comments
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
Great to learn english language in SO! – alvatar May 19 '09 at 13:24
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
Answer by Jeremy French
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.
Comments
Which means that ultimately the biggest risk to a project is the competence of the people involved. – MusiGenesis Jan 22 '09 at 14:29
But that goes for any field. Because of the 'abstract' nature of software change is harder to fight against. – Jeremy French Jan 22 '09 at 14:32
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
Why do we think software is more 'abstract' than something physical like a car or a bridge? The AMC Pacer and the Pontiac Aztec are examples of design where change was not managed well. – MusiGenesis Jan 22 '09 at 14:53
MusiGenesis: There are many differences. It's not that they don't fail. But if you look at a construction project, you can roughly estimate how much work has been done and how much is left. Users can have an idea on how it's going to be from the first place. This is not the case in software. – Mehrdad Afshari Jan 22 '09 at 15:12
@Mehrdad: I can make similar estimates on my projects, assuming I'm reasonably familiar with the platform/language and the problem domain. – MusiGenesis Jan 22 '09 at 15:17
MusiGenesis: Yeah, there are measures to do so but the point is, this is much harder and less accurate, than say, counting the floors of a building :-) Another thing is, while you might be able to evaluate it, users probably won't, which does make a difference. – Mehrdad Afshari Jan 22 '09 at 15:30
@Mehrdad: your average modern car is vastly more complex than any piece of software I've ever seen, used or read about. The general statement "software tends to blow because programming is hard" is kind of a crutch. – MusiGenesis Jan 22 '09 at 22:46
MusiGenesis: Complexity is not the only factor. The non-physical nature of software makes it somewhat mysterious. And another thing that is so true about software is that writing code, involves reading code too. So writing software is a little like O(n^2) :). – Mehrdad Afshari Jan 23 '09 at 12:58
Also, as noted by Fred Brooks, adding people to a software project doesn't make it finish faster. This is not true for other kind of projects, at least not to this magnitude. – Mehrdad Afshari Jan 23 '09 at 12:59
That Fred Brooks quote is wrong though - adding people to a LATE software project makes it LATER. But that doesn't mean adding the right people at a right time can't make it finish faster. – Joris Timmermans Feb 10 '09 at 11:17
@MedKeithV: completely true. I think I missed the word "necessarily" in my comment. – Mehrdad Afshari Mar 26 '09 at 20:44
I think Joel Spolsky has quite an experience on bad changes (or rather, rewrites). – Halil Özgür Feb 16 '11 at 9:37
Answer by Joris Timmermans (Jan 22, 2009)
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.
Comments
McConnell calls this "Wishful thinking", i.e. assuming something will fix itself – Rob Nicholson Sep 29 '09 at 10:49
Answer by McKenzieG1 (Jan 22, 2009)
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.
Comments
Amen. I've been waiting for years for the time when I can stop avoiding third-party components like the plague, but it hasn't happened yet. – MusiGenesis Jan 22 '09 at 14:58
I wish I could vote this up 1000 times. – ojblass Mar 26 '09 at 5:50
Completely agreed - yes our medical information system has bugs but most of the issues we've been unable to fix/track down as with 3rd party controls. You take a chance with their quality – Rob Nicholson Sep 29 '09 at 10:48
In addition to technical problems caused by third-party components, legal restrictions on such components may make it very difficult for you to open the source of your system should you ever chose to relinquish support of the system to the community. – Erik Garrison Apr 7 '10 at 21:25
Answer by Slapout (Jan 22, 2009)
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 by Steven A. Lowe (Jan 22, 2009)
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
Comments
This is essentially the same as my answer, albeit without the down-votes. :) – MusiGenesis Jan 22 '09 at 15:19
MusiGenesis-I don't think this is like yours at all. It's similar to mine though ... so it must be right. ;-) +1 – John MacIntyre Jan 22 '09 at 16:25
Answer by John MacIntyre (Jan 22, 2009)
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 by Joe (Jan 22, 2009)
- 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.
Comments
+1 for "re-engineers" and "micromanagement from the client" – Andrei Rînea Nov 8 '10 at 0:51
Answer by Frank Michael Kraft (Sep 28, 2009)
Politics
If good reason does not prevail, because it is unpleasant to hear.
Answer by Otávio Décio (Jan 22, 2009)
Thinking that you gathered all requirements and being sure the client told you everything you need to know.
Answer by Jon Winstanley (Jan 22, 2009)
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 by MrValdez (Jan 22, 2009)
Anything that involves money or credit card payment. Keeps me awake at night :(
Answer by Kasper
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 by Gambrinus (Jan 22, 2009)
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.
Comments
Indeed, a lot of them don't succeed. At least most project miss on time and resources, quality, or features. – Mehrdad Afshari Jan 22 '09 at 14:35
yes - McConnel wrote in his book that every software-project that misses its monitary- and/or time-constraints by 400% can be seen as successful. biggest problem I think is that most customers do not know what they want in the first place and start to change the spec every now and then. – Gambrinus Jan 22 '09 at 14:50
I have never heard of a project that was "Completed Successfully". Sure there are successful projects, but none of them were COMPLETED. They just crossed a threshold into being "good enough" [even that bar keeps on rising though] – Mostlyharmless Jan 22 '09 at 14:52
Answer by meade (Jan 23, 2009)
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 by David Thornley (Jan 22, 2009)
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 by Jon Hopkins (Sep 29, 2009)
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 by Mammu (Jan 22, 2009)
Missing the following can make a s/w risky
- Extensibility
- Change Adaptment
- Clear goal of software
- Try using the software as End-USER
- 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 by Lonzo
- Lack of planning
- Skill/Resource shortage
- Ineffective communication among stakeholders
- Failure to get a full understanding of the requirements
Comments
I thought "Lake of Planning" was a setting in World of Warcraft? – MusiGenesis Jan 22 '09 at 15:00
Are we on the same team? – jamesh Jan 22 '09 at 15:46
Answer by JB King (Sep 17, 2009)
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 by Stephan Eggermont
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 by geowa4 (Jan 22, 2009)
Marketing.
Answer by Stu Mackellar (Jan 22, 2009)
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 by astronought (Sep 03, 2010)
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.
Comments
Scripting languages are designed to put pieces of code (such as C++ code) together. Most of them have C bindings so that they can be called from conventional compiled languages and call into them. I may be misunderstanding you, but I just don't see any real risk involved here. – David Thornley Sep 3 '10 at 13:53
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
Answer by Rob Nicholson
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 by mickyjtwin (Jun 03, 2010)
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 by Alb
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 by Gayathri (Nov 24, 2010)
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.
Shared with attribution, where reasonably possible, per the SO attribution policy and cc-by-something. If you were the author of something I posted here, and want that portion removed, just let me know.