Factors to be Considered for Software Risk Management

Question

What are the risk factors that we need to consider while planning for a software project.

Answer 1

• Is your team adequately trained?
• Is your team large enough?
• Do you have contingency in case someone leaves the project, and how would it affect the schedule?
• Is your team too large?
• Do they have the resources they need?
• Might a competitor bring a product to market before your project completes?
• Can you deal with changed requirements?
• Can you deal with the project becoming irrelevant?
• Do you have buy-in from senior management?
• Do you have any reliances on suppliers or contractors?
• Are you doing anything in-house that your team isn't competent enough at?
• Do you have budget big enough to meet the estimated project cost?
• Can you meet unforeseen project costs?
• And anything that's specific to your circumstances :-)

Answer 2

I would add to @Graham's list:

• Are some of the requirements out of your control (eg the laws about calculating sales tax) and might they change?
• Are you using a tool for the first time and how confident are you the tool will work for you? (It might be brand new, eg Azure, or just new to your team)
• Are you relying on a general acceptance by your users of another product (eg writing an iPhone app means you expect your users to have iPhones, writing a BlackBerry app means you expect your users to have BlackBerries etc.)
• Can you restore/recreate any lost or wrongly-changed work (not just source control but version control for documents, emails from clients, etc)
• Do you have tools and process that enable you to understand progress, lack of progress, and regressions? Does management understand the milestones (I've had projects where at 10% complete the management saw UI prototypes and believed the work was "almost done" then pressured to hurry hurry hurry from then on.)
• Do you have testing (automated or not) to demonstrate that a particular set of changes has not broken some other part of the application? Without such tests, could you ever make significant changes such as porting to another language or platform?

Answer 3

I'd add the following:

• Do you know your customer's needs. If not, has your requirements gathering team adequately determined what it is that the customer wants in the past and been responsive enough to ensure that changes are propagated as quickly as possible to the development team? Are they adding in gold-plating to the requirements?
• Is there an existing product you are competing with and have you determined prior to design just how you will compete with this product? This is critical as existing products often come out with "I want that feature too" aspects which could make you deviate from original plans. Is your team/management/target customer able to be side tracked by such an occurrence and do you have contingency plans set-up to handle such an issue?
• Is the proposed design of your product relevant to the market? Halfway through you don't want to discover that while it satisfies your customer's needs it lacks critical aspects to compete in the "new" world.

Answer 4

Steve McConnell's Rapid Development contains a chapter on risk management, with a usefully long list of potential risks. I've used it as a starting point more than once.

Answer 5

Do you have the right mix of people? Are all your developers application developers in a data-centric project? Do you need a database designer, a QA person or a UI specialist instead of only hiring people with the same skill mix?

Do you have adequate hardware to support the project? This is especially true if you are creating a high volume system or if you are too cheap to buy development servers in addition to production servers.

Have you set up backups of your databases? Just having the code to recreate a database is not enough, you need to be keeping the data as well even on dev.

Are your developers working with a small data set instead of one the size that production will be? This almost guarantees production performance issues because queries that work well on a small data set often do not on a large set. I've seen a lot of failed production updates that had to be immediately rolled back due to this particular problem.

Are you defining what to do in edge cases and are you testing them? For instance, I've seen projects where nobody ever defined what happens what an approval is required and the approver says no.

Will you be forced into making bad design choices in order to meet unreasonable deadlines?

In your planning for the project did you consider that people take vacation and sick days, get jury duty, take bereavement leave etc? You need to plan not just for people leaving the project but for the day-to-day time off people get.