Risks

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.

Risk management must expect the unexpected (Magritte)

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.

Stakeholder assessing odds

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.

Risk Management

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.

Different worlds, different times, different risks.

One Response to “Risks”

  1. Putcha V. Narasimham Says:

    Excellent! As usual common experiences, conventional wisdom and philosophy are combined to relate things that are known but not seen as connected.

    I have been avoiding study of “risk” but now I find there is a systematic approach to it…….Thanks Remy.

    09JUL12

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

Join 283 other followers

%d bloggers like this: