Venice view from Canaletto

This post is a small contribution to a great presentation from InfoQ.com pointed out by Herding Cats. Moreover, there is a nice comment from Better Projects.

Where Up Front Design (long terms technical plans made at project’s beginning) are conjugated with all possible cases:

1. Big design. All roots of risks (in particular changes in requirements) are carefully reduced. The OBS –and related financial support – shall be strong enough to supply the necessary workforce that would cover any possible issue.
2. No design at all. The gap between the requirements and available resources tends to nil.
3. Relative design. Strong foundations are well entrenched for allowing tactical adjustments.

Criticizing the big design

James Coplien & Kevlin Henney are smart and experienced developers (and leaders as well). Their ideas are based on the “Agile” concept of organizing the production for making easier to accept modification until the latest moment.

This viewpoint will find strong advocates in those customers, who need short time-to-market approach. Therefore, risks related to increasing budget can be reasonably accepted in view of maintaining unchanged the delivery date, scope and quality.

The limits of “beautiful” design

The idea of designing all details (RUP), leaving the simple act of coding to the developers, could be considered as an evolution of the “Big design”. In fact, there should be more interactions with customer, who should be enabled to judge the correspondence of designs with their requirements. To support this viewpoint, they cited L.B. Alberti – who warned architects about the risk of drawing a “would be” reality, instead of spending energy on “mechanical” concepts (those which make a structure working).

In their viewpoint (confirmed by my experience) this approach has two big weaknesses:

1. This is based on the assumption that the customer can read and go through scores of even more complex diagrams.
2. The creativity of developers is nullified, increasing the chances of risks either caused by lack of adherence of the design to the “hard” reality of coding; or different results produced by misunderstanding between analyst and developers due to the lack of intelligent human interaction.

No design at all

The only reasonable scenario offered is produced when developers have experience (technical skills and domain’s knowledge) enough for dealing with the “new” project without the need of a plan produced by an “external” analysis.

Missing this condition, the result is a failure.

Strong pillars, smaller creativity and continuous interaction

After a “short” period of inception, the architect (senior developer) starts to write down the necessary (working) code for creating the fundamental (abstracts) classes. Once, these objects are tested for responding to the major customers’ requirements. This enables the (junior) developers to work within a working and dedicated frame where they can tackle the details and accommodate the changes requested during the development.

Conclusion

Given the uniqueness of the projects, this classification offers a good system for understanding the correct (technical) approach. However, the choice shall be taken considering the real options available.

A thorough and impartial assessment of the available resources (that starts from the senior management) is the unavoidable process that shall precede and strongly influences the organizational and then technical choices.

“All generalizations are false, including this one.”

More readings

http://alistair.cockburn.us/Notes+on+the+writing+of+the+agile+manifesto

Stakeholders are the major sources of risks.

A good chart remains essential

1. A future root cause (yet to happen), which, if eliminated or corrected, would prevent  a potential consequence from occurring,
2. A probability (or likelihood) assessed at the present time of that future root cause occurring and,
3. The consequence (or effect) of that future occurrence. [3]

This is a compelling reason for thinking the “Risk Management” as an activity developed in partnership with stakeholders. Here below are listed some common misconcepts and attidudes that could undermine the correct Risk Management approach:

1. Flexibility (either in requirements or quality) can reduce the risks.
2. Avoiding strict criteria for measuring success, could increase the margin for manouvring each outcome for improving the output quality
3. Change Management, a key tenet of Risk Management, could be intended as a limitation to the commercial freedom from (Sales and Marketing people) [4].
4. Informal approach (based on mutual trust) would avoid, quicker solving most of the critical situations (i.e. among friends it is easier to find an agreement).
5. Risk management budget could frighten customers and senior management.
6. Assuming that everybody is familiar both with the chosen technology and methodology.
7. Not linking the properties of quality to the customers’ satisfaction.

Some (possible) answers

1. The definition of risk assumes the existence of a baseline. Any variation can be measured only from an established reference. By the way, it offers a solid ground for building the foundations.
2. The “Iron Triangle” values shall be integrated (it is difficult to substitute them) with customers’ values (e.g. quality)
3. Change Management is an established procedure for evaluating the feasibility and impact of any variation
   1. The control of change means the assessment of the impact of potential changes, their importance, their cost and a judgmental decision by management on whether to include them or not. Any approved changes must be reflected in any necessary corresponding change to schedule and budget.[5]
   2. It is not only a set of skills (mostly based on negotiation and a good versioning system). It shall be a structured process involving the stakeholders:
      1. Customer / Product Managers presenting a Business Case for each modification required
      2. Developers / testers who can approve the feasibility (e.g. security, maintenance) and then estimations (costs and time)
      3. Sponsor (Project Manager) who chairs the board
4. Important projects involve big organization (and put at stake a lot of money). It is extremely difficult to base all agreements solely on a “gentlemen’ agreement”. Yes, mutual trust is an essential ingredient. However, left alone is not sufficient.
5. The budget (raw figures) shall be shipped with the criteria used for producing it. These criteria, presented like concepts, can be form a good basis for a strong negotiation. The common pitfall is to surrender on figures without changing the premises.
6. The deepest root of any risk is an unchecked assumption.
7. The definition of “Quality” has to be translated into operational topics, like:
   1. Resource management. How much in percentage developers will be involved in these activities (i.e. Unit Test and Peer Review)?
   2. Which are the areas that can be considered worth enough for being tested?
   3. Are the meaningful and correct (updated) data available for testing the key features?
   4. How much time of “final users” is allocated for (functional) testing?

Conclusions

Risk Management is an essential part of the PM and it is the activity that mostly involves stakeholders. This statement should be strong enough for dedicating it the necessary resources and training.

More Readings and references

1. PMBook Guide 2000 Edition
2. M_o_R Guide 2007
3. Risk Management Guide for DOD Acquisition – Sixth edition
4. Software Project and Process Measurement – Dr. Christof Ebert – Vector Consulting Services
5. Prince 2 manual (2005 Edition)

http://sourcesofinsight.com/2009/08/04/clarify-meaningful-results/

Image courtesy of: http://www.touregypt.net/featurestories/treaty.htm

From a Risk Management viewpoint, before preparing a “contingency plan” (perhaps together with the “fall back plan”) it is essential to establish and allocate the correct amount for risk budgeting (as explained in previous posts).

A oxymoron to be pondered

Contingency: something liable to happen as an adjunct or result of something else. [2].

Plan: an orderly arrangement of parts of an overall design or objective [2].

In essence, the idea of spending energy for reducing the effects of an uncertain event could seem a waste of resources.

“Contingency / workaround plans”, or “Exception plan” [3] should be viewed as a stem of the Risk Plan. A bud, which can sprout quickly and strongly, because it has all the information (DNA, if you have a boy who loves biology) is contained in the trunk.

For post reasons, the PID[4] (Project Initiation Document) is reduced to the Master Plan. Therefore, any reference to Quality, Acceptance Criteria etc. are included in this document.

Using Gantt for preparing the Risk Plan

As described in the previous posts, it is insane to think Risk Management as a marginal activity of Project Management.

The Main Plan[3], which includes all work-packages without details, should be used as blue-print for entering all structured information produced during the Risk Analysis (this requires that all risks – excluding the Critical Path – have been identified). Obviously, this process shall be repeated for each work-package, which could be deemed worth it (especially if it is on the CP).

MS Project offers all the features for setting a good Risk Tracking system and then attaching all necessary documents for preparing the various “contingency plans”.

The “resources” named beside each task could be the natural “monitor” for checking the triggers’ status. Therefore, for each point that can touch off the event, then a threshold value shall be assigned alongside the method to verify it. All these items will be taken as notes and attached documents, to become integral part of the whole plan.

Contingency Plan is not enough

Hospitals are indispensable institutions. This is not a valid reason for a reckless behavior.

The Risk Analysis shall include the Risk Quantification and the Control / Response.

The forms of response are:

1. Avoidance. When the root of the potential problem can be eliminated.
2. Acceptance (it is not about ignoring the event, just keep it monitored for controlling the if the impact is within the set tolerances)
3. Transference. Any form of hedging, including the outsourcing of the item.
4. Mitigation. When the magnitude of the impact can be reduced within tolerances.

This means that the first issue of the Main Plan shall be reviewed on the basis of the information produced by the Risk Analysis.

This is the first action classifiable as “Mitigation”; others will be implemented during the review of the Gantt chart (e.g. “Leveling resources”).

“The budget evolved from a management tool into an obstacle to management.

Conclusion

I suppose it is in the blog’s nature leapfrogging from one topic to another that should be placed ten chapters later. For me is a wonderful discover, the chance for tackling issues on the spur of the thread.

More readings – References

1. PMBook Guide
2. Merriam Webster
3. Prince2 – 2005 Edition
4. Prince2 – 2005 Edition (see link)