Risk Management: Current & Future Development in Software Development

Question

Hi, Am new to Software Project Management and currently doing some research on Risk Management in S'ware Development. Just interested in knowing what are the current methods applied and any future trends to come. Thnx

Answer 1

A popular method used by many project managers of my acquaintance is to ensure that every risk is written down as accurately and fully as possible in a RISK LOG and then stored in a sharepoint document library never to be seen again except perhaps briefly as they float out of the effluent pipe and drift on out to sea.

Answer 2

thnx, that was helpful. what about the future, any new things coming out. How is it incorporated in Agile.

Answer 3

There are so many Risks associated with the average software project that any "risk management strategy" is at best window dressing and at worse gives a false sense of well being.

For some time now I have been convinced that (as there are relatively much fewer of them!) its much better to concentrate on the factors that will make a project a success.

• Does the business really want/need it -- is your project sponser sane?
• The right people -- do you have good developers with the right attitude?
• Clear and sensible requirments -- does the project brief make sense to you?
• Tight Schedules -- is the project due for delivery in the next twelve months?
• Acheivable Schedules -- is it possible to deliver within the next twelve months?
• Is it based on standard proven technoligy -- not just the latest buzzwordware?

If the answer to any of the above questions in "no" then you may as well can the project now and save everybodys time and money.

They are all equally important, but the timescale one is often neglected. Most projects which take longer than 18 months will be cancelled before completion, regardless of the excellence of the team or the implementation. The requirments will change, the business will run out of money, the management strategy will change, you will be taken over by a competitor etc. etc. a lot can happen in eighteen months.

Answer 4

We use risk management fairly heavily. For us, it's a way to document communication up the internal food chain, mostly about external difficulties. We have a formal in-house, self-made web tool that lets us:

• document the risk as an if/then statement
• note the anticipated impact in terms of cost, schedule and quality
• create mitigations - general strategies for coping with the risk. Ignoring is an acceptable strategy if the anticipated impact and probability are low enough.
• create actions - documentation of concrete action to prevent the risk that have already been taken

The risks, mitigations and actions are then updated and reviewed at Engineering Status Meetings (ESR) every other month. If something goes really off the rails on the project, the ESRs get more frequent as management "helps".

The risks are proposed by the front-line managers - in our project, that's me - the software task manager. We're the ones who see something that could potentially derail our ability to complete on time. Then our project management and engineering management see it.

I found it was a pretty good venue for getting management help for external factors. Risks have included:

• Critical problems with tools supported by our IT department that aren't getting addressed in a timely manner
• Problems with other components on other contracts with which we integrate
• Problems with not getting a key deliverable from our customer
• Areas of profound technical uncertainty - they can't always be fixed, but at least management knows that there's some stuff we're dealing with.

Risks stay in the database forever, so they serve as a historical documentation that something was brought to managements attention. At the very least, they are a CYA (cover your a**) procedure - but with our management, they are also a tool for working together to fix a problem. - often with the assistance of upper management leverage. Several of the attendees at ESRs are people with some vast experience at managing technical teams, who tend to be able to offer good suggestions.

There is definitely some political savvy required. For us, it has to be technical - but you don't want to highlight problems with individual people. Unless you want to highlight a lack of people or a lack of people with sufficient experience/knowledge. My preference is to keep it externally focused most of the time, and manage the team problems personally and quietly with limited help from my managment.