Contingency Planning by John-Jan Popovic

Before we start coding
---------------------------
Proactive vs. Reactive
---------------------------
Contingency planning is the process of identifying potential risks to the business and developing a comprehensive plan that enables the company to respond to any threat or disaster and quickly restore normal business operations. Contingency planning is a proactive strategy that emphasizes preparation over response. Crisis management is the process of managing the response to a major incident after it has occurred. It is a reactive strategy that emphasizes response over preparation.


.
Software strategic planning is the process by which the customers and developers envision the future together and set the necessary procedures and operations to achieve the desired software solution.

We think that tracking development milestones is a great way to monitor development progress and see which parts of the software are being developed, improved or fixed.

We can also see which parts of the software have not been planned, designed, coded and tested yet. The hardest single part of building a software system is deciding what to build, and how to approach to difficult problem, decomposing its complexity, by maintaining high development standards.

PLEASE NOTE: The planning process can be viewed as a somewhat spiral flow of topics and action steps, where the results from one step initiate study and action in the next step.

However, the development process does not necessarily always flow in one direction. Issues that arise in a particular solution may cause the planning team to go back to an earlier step to do additional work, implement new features and insert new milestones in the roadmap or refine the application functionality.

If desired, the order of the MILESTONES can even be altered to suit the particular needs of the planning team. The implementation step also does not end the planning process. Analysis of results could easily result in additional analysis or a change in strategic direction. Also, it is recommended that the plan be reviewed periodically, sometimes even on a daily basis in order to verify that all the base assumptions are still valid and that the implementation plan is progressing according to expectations.

REFINEMENT OF THE PRODUCT REQUIREMENTS
“The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult in establishing the detailed technical requirements, including the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the results if done wrong. No other part is more difficult to rectify later. Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements.”
—Fred Brooks