Table of Contents
Risk Factors in Software Development
When evaluating Risk, the risk factor is the intersection of Probability and Consequences.
Do not neglect the Factor in The Risk Factor.
"Eating the Elephant in one sitting"
Attempting to deliver a new software system in a single phase is a dangerous practice; big projects = big bang = big risks. Professionals Software Engineers needs to constantly manage mitigate risk; which avoiding analysis paralysis and feature creep.
What is the nature of the Risk ?
- Political Risk.
- Scope Risk.
- Requirement Risk.
- Technology Risk.
- Skills Risk.
Quantify the Risk Consequences
What is the magnitude of the event?
Quantify the Risk Probability
What is the likely-hood of the event?
Quantify the Risk Factor
This factor is the Consequences * Probability.
Establish a consistent development process that allows a small start, early delivery and continuous improvement. Iterative development methodologies offer incremental delivery and are responsive to change. On larger scale projects iterative development allows for continuous reduction of development risk.
The optimal solution is not necessarily the perfect solution.
Are the limits of the scope of the project well understood by both the development team and the stakeholder.
Use usecase Analysis to determine scope.
Are the requirement well defined and understood.
Assign requirement risk to first order usecases. Refine highest risk first order usecases.
A good appreciate of OO design and UML is uncommon amoungst Business Analysists, Project Managers and stakeholders.
Project Manager knowledge of iterative development processes is less than universal.
Iterative development processes requires that Project Managers and Business Analysts willing or even eager to buy-in to that approach in preference to the over-the-wall or water-fall development approaches. If the project manager does not support the process it is doomed to failure.
It is common to find Project Managers and Business Analysts reverting to traditional and more comfortably development processes they know best when under pressure. BA's may be reluctant to hand over requirements documents they perceive as incomplete or unpolished. Iterative development processes benefit from early sight of requirements which is typically more important than absolute correctness. Iterative development processes relies on early delivery and continuous improvement to deliver quality and conformance to requirements.
Up-skill PM's and BA's in OO design in general and UML in particular. Obtain early commitment from PM's and BA's to Iterative development / incremental delivery. BA's to operate primarily as business domain experts more than technical authors of requirements documents.
A test to be more valuable than a written requirement in Iterative development considers. A test can be measured and automatically reproduced for regression testing.
Project Management and Business Analyst to facilitate or ideally promote Iterative development and incremental delivery.
Developer Skills Risk
Developers face skills' risks constantly. New technologies, new versions, new standards.
Establish best practices for Training, Specialisation and Mentoring. Encourage and support personal development. 3rd Party expertise Your chosen vendor with expert help
Reactive and Heroic Development Methods
Development culture is often based around an 'Heroic development'. This approach is flexible, adaptable has been used successfully on many projects. However Heroic development is not always successful; it is a high risk strategy for a company, it takes it's a high toll on developers and code base. Heroic effort should be reserved for unusual circumstances, it should not be the staple of day-to-day software development. Resistance is to be expected change this from the current team
Active promotion of a continuous improvement culture must pervades the software development process and methods as well as the software.
Heroics are for Firefighters not Engineers.
Location / Communication / Cross-Training / Cross-Mentoring
The existence of separate development locations using two different technologies presents barriers to effective communication. Inhibit co-ownership, teamwork and present a barrier cooperation. The different nomenclature attached to the different technologies jeopardises communication clarity. These factors may inhibit the transfer of differing skills and knowledge in both directions.
This may prove to be intractable because of political resistant mitigation.
Seek to establish a common nomenclature that cross platforms.
Adopt a clear and concise development process.
Reduce communication barriers through the effective communication and collaboration tools such as email, chat, Wiki's, white boards, flipcharts.
Test driven component development will help reduce communication impedance.
The overall architecture of many projects is ill-defined. A test driven iterative development requires the early availability of a reference platform to work effectively.
Vendor support required to develop a coherent architecture. Vendor support required deliver a reference platform. Ongoing architecture refinement
Requirements capture, development, test strategies appear weak to non-existent.
Adopting a methodology is not the silver built that will instantly solve all development problems. Adopting UML or Design patterns are a single step on a long Road.
Promote a wide support for a process of continuous improvement.
A cohesive environment for development, integration, testing and deployment is essential to minimise the issues, improving speed of deliver while maintaining reprocucability.
Instigate standard cohesive for development.
A stable political environment is essential.
Instigate senior management support to programme.