Source & Time frame
Since risk management must deal with expected as well as unexpected events, it is fundamentally a matter of time and therefore can only be achieved if events’ sources and causes are set against a properly defined time-scale.
And time, from an engineering point of view, is structured by events and decisions. On the other side, projects are governed by objectives, expectations and commitments.
Since system engineering involve different layers and different perspectives, projects will have to arbitrage between risks beaten by different rhythms:
- Business events can be grouped along two frequency waves: short, for market opportunities, and long, for an organization’s continuity.
- System architectures are meant to evolve in synch with organization continuity; unfortunately they also have to adapt to unexpected changes in corporate structures subject or technological environment.
- Component implementations should heed market opportunities and fit system architectures. Within that envelope project management has some latitude to set its own schedules depending on resources and development constraints.
No divine intervention could guarantee that those time frames would coincide. More to the point, the true purpose of engineering processes is the explicit management of independent time frames, for business objectives, technological capacities, and development capabilities, each with their own scales, rationale and constraints. The name of the game is risk management, and that can only be achieved if risks are properly identified.
Whether fate or fortune, business affairs are driven by external forces. For chance, shorter schedules make for better odds. Otherwise a business must take into account the changing panorama of available technologies and the capacity of its organization to translate technology advances into quality and costs.
While decisions have to reckon with the whole picture, each perspective has its own specific timing and constraints. Since decisions are ultimately based upon risk assessment, the solution is to keep apart the respective time frames depending on the risks involved:
- No risk: changes in computation rules and scale requirements should be supported as they come if systems were properly designed.
- No risk taken: business organization and system technologies are not sure bets. Neither are they open to compromise. Hence, those risks are not meant to be priced: once taken, decisions must be scheduled and implemented regardless of what happens.
- Managed risks: even if market developments and their project’s counterpart belong to different time frames, respective objectives and schedules can be priced and weighted by risks. Decisions are therefore meant to arbitrate between costs and benefits.
That understanding put the onus on the dual aspect of risk, which is decision: on one hand risks must be taken, ie eventually decisions will have to be made. On the other hand one should wait for the “last responsible moment”, i.e until not taking side could change the possible options.
Applied to project management that means:
- Maximize the time between requirements and commitments, i.e never decide today if it can be done tomorrow.
- Minimize the time between commitment and delivering, i.e don’t think twice once a decision has been taken.
Risk & Development Processes
Those principles can be applied by combining iterative development with architecture driven modelling: iterations are used as sieves, taking away easy pieces and fencing off hard choices. Easy pieces are no-risk options, which can be developed and modified at will; forced choices are set in stone across layers; in between are managed risks for which decisions once taken must be implemented as soon as possible lest new circumstances make them obsolete.
As a consequence, development processes should be designed along risk fault lines, i.e work units should never be exposed to different kinds of risks. Assuming transparency and traceability across model layers, projects could then manage objectives, expectations and commitments across business, technology, and engineering perspectives.