Successfully building real software systems is a high-risk undertaking. To manage risk, you need to explicitly identify and face risks; and then implicitly manage these risks in the way that you build and develop the software. Let me explain.
Poor (or nonexistent) management of risk has led to continual, and in some cases, spectacular project failures and product failures. As a result, development managers and project managers are now expected to follow risk management in their work. Standardized risk management is an important part of the Project Management Institute’s professional standard for project managers. Steve McConnell and Construx introduced a simple, and commonly referenced tool, the Top 10 Risk List in his Rapid Development book – this tool, and generic risk patterns as well as a set of plan templates and checklists, are available as part of the CXOne method available for free from Construx.
Using the Top 10 Risk List or following other risk management practices, the team, and especially management, need to first recognize and confront risks – recognize what can go wrong, recognize the early warning signs or triggers of risks, don’t hide from risks. Continually review and look for new sources of problems.
The next part is to manage risk by how you build and deliver software – build risk management into your SDLC. Let’s consider the common types of risk:
Architecture, tools, platform and technical risks. Build software incrementally. Build the hard parts first. Develop vertical, technical prototypes to evaluate your design. You’ll know if your idea and your technology is going to work, if it works. If you’re going to fail, fail early.
Requirements risk: changes, incomplete, wrong requirements. Prototyping, incremental and iterative development. Work closely with your customers. Get feedback, adapt.
Stakeholder risk and other political risks. Deliver concrete value, deliver early, deliver often, and make sure your stakeholders are well-informed, that your work and your approach are transparent to them. You are unlikely to be stabbed in the back by someone if you are giving them (or other important people) what they want and making sure that they know it.
Staff, personnel risks, key people leaving. Share code, conduct design and code reviews, pair, switch tasks between team members. Invest upfront in automated unit testing and other developer testing - not only does it protect team members when they need to change code written by someone who has left; it also helps you understand what that the code is supposed to do – good unit tests are the best form of documentation. And code that is well unit tested is also generally simpler.
Schedule risk. Like requirements risks and technical risks, manage through incremental delivery, deliver the most important and hardest parts upfront, time box everything. If you can’t get to everything, you at least get to the important stuff – this is probably all that they need anyways. As always, hire the best people you can and make sure that they have good tools and a good working environment.
Quality risk. Incremental development, continuous integration, extensive automated developer testing, use static analysis to find the stupid mistakes, reviews or pair programming. Ensure that developers and testers work closely together, and fix bugs early. Review and learn from each delivery, constantly find ways to improve.
Design risk – over complex or bad design. Again, incremental development, focus on hard things first, build a technical proof of concept upfront to prove the design approach.
Subcontractor risks. Manage your partners and contractors like you manage yourself. Demand regular, incremental deliveries and transparency into the construction and delivery process. Hold your outsourcing partners to the same standard as you would hold your own team; or in some cases, a higher standard.
Following a basic set of good practices in incremental development will help you and your team avoid or deal with most of the classic development risks. What changes is the amount of care and discipline in your development approach.
