Managing Risks on Software Projects
The challenges of software projects
Like all projects, software projects have risks. Risks that were not foreseen and planned for frequently cause major project issues and even failures. Such risks could be due to problems in the project or due to external events. For example things like changing requirements, integration problems, unavailability of skills, design issues, faulty technologies and so on are a frequent cause of problems. These sorts of issues are usually a challenge and a major source of worry for project supervisors, their managers and executive sponsors. Often their existence is recognized very late and desperate attempts are made to somehow mitigate their impact. However, recognizing them early and taking steps to address them can help bring the project back onto it's tracks or in the worst case help make a decision to terminate the project before too much time and money is spent.
Handling common risks on software projects
Requirements related issues are one of the most common types of risks. Software being a fairly abstract item is often subject to this sort of risk. Users find it hard to visualize and get a feel for what they want and will get. In many traditional software development methodologies there is little early feedback on how the final system would look and feel. At the most users can expect hundreds of pages of documents (very sleep inducing!) or sometimes if they are lucky some early prototypes they can play with. It is no wonder that on many projects requirements are often subject to change as users progressively get a better idea of what they are buying into. This is what the newer agile development methods try to address. The aim is to deliver working software early and often as a series of iterations. This provides users a lot of early and rapid feedback and can help deliver systems that provide much better user satisfaction and have a higher chance of successful acceptance. Besides this, another big benefit that project sponsors and management receive from planning projects using agile methods is clearly defined project milestones set at delivery of working deliverables. In my experience project milestones based on the delivery of documents or intermediate work products can often give one an optimistically wrong sense of where the project is in terms of completion.
Another item that frequently causes problems is lack of skills or resources. The project team may not understand the problem domain or be new to the tools and technologies being used. In such cases having experienced mentors who can provide this input can be very valuable. Mentors could be from within the organization or could be external consultants familiar with the problem domain or technology. A lack of resources could involve insufficient funding or unavailability of people and facilities. Here identifying alternate sources for these resources or ways to share resources with other teams can help.
Integration issues are another area that produces problems and are becoming more common as more projects these days are done as sub-projects done by widely distributed teams. Having agreed to interfaces defined as soon as possible and having frequent integration checkpoints can be very helpful. The frequent deliverables of working software created by using agile methods make it easier to define such integration checkpoints. Integration failures at these checkpoints help flag problems early and provide the project team(s) a chance (and time) to work on getting them resolved.
Technology and design issues can pose their share of problems. I have often found new technologies seem to promise more than they can deliver. Creating stub systems early to do testing of important features can be helpful to find bugs. Many system design issues can also be discovered early using similar techniques. Stub system tests for system load, user interfaces, security and so on can provide valuable feedback or clues to potential problems.
One area that people frequently neglect is the impact of business issues and decisions. Difficulties with partners or vendors, changes in the business environment can leave a project vulnerable to failure. Attention to detail can be valuable especially if one knows of loose ends in contracts or external business issues that if not addressed can cause problems. Besides this contingency plans and identifying alternative sources can be very helpful.
The time when a project is done and over can pose it's share of risks. Deployment issues can delay rollout of a solution. Maintenance & enhancements requirements can pose problems. Having a good idea of deployment needs and working closely with operations teams is important. Identifying and training a maintenance and enhancement team before project handover will make it easier to handle new needs or changes that always crop up!
Political issues are another area that gives project managers sleepless nights. They can be extremely hard to handle. Being politically savvy and knowing when to compromise becomes really important. Finally be ready for the unexpected. Things like losing your source code repository, your server and so on. Make sure that regular backups are being taken. More than one type of backup may be advisable. Identifying other teams one could share with in case of loss of servers or facilities can keep the project running in many situations.
Managing a software project can pose many challenges. Keeping an eye out for items that can go wrong can help save a project before it is too late. Many issues are common to most projects and there are ways to mitigate their impact, especially if they are detected early on. It may seem a challenge to do all this while doing all the other project management tasks. However, putting together a proactive risk management process for your software projects will pay many dividends in the long term.
Copyright © 2002 Sanjay Murthi
Sanjay Murthi is President of SMGlobal Inc. He has over fourteen years of experience in the software industry in a variety of roles and responsibilities. He now helps companies to review and improve their software definition, development and delivery process. He can be contacted at firstname.lastname@example.org.