The following list has been conceived as shared tool available to all stakeholders. It is the first step toward the full (balanced) involvement of anyone in the effort of delivering the successful project.

The choice of using the same registry for managing Risk and [...]]]> “Bureaucracy is not an obstacle to democracy but an inevitable complement to it.”

The following list has been conceived as shared tool available to all stakeholders. It is the first step toward the full (balanced) involvement of anyone in the effort of delivering the successful project.

The choice of using the same registry for managing Risk and Opportunities comes from the idea that any variation shall be analyzed from the most “neutral” viewpoint. While it is foolish ignoring the risks, the worrisome attitude toward them creates friction. This wastes a lot of people’ energies, who fell pressed for hiding the reality.

1. Risk ID – It is part of the Registrar Section (see post)
2. Issue ID – If available, it means that the Risk has been detected after the release of the Plan (more to come in the next posts)
   1. Impact Report ID
3. Item ID – the reference to the Product Breakdown
4. Risk Plan ID – the reference to the most specific item in the mitigation plan(s)
   1. Exception Report ID – the reference to the document describing the proposed actions (when the proximity is very small or the event has been triggered – see pending status)
5. Version – The versioning (see post ) it is not only the best way for tracking changes; it offers the possibility to understand the (d)evolution of the current situation.
6. Sign – Is it a Risk or an Opportunity (see post )? Using the same register makes possible to catch and adjust any possible occurrence.
7. Risk Category – See Category Risk’s list
8. Description – It is a key value. The reason for this lies in the clarity and then the understandability of the threat to the outcome.
9. Cause – It could be a sensitive topic. It is not only a problem of “savoir faire” with the involved people. Sometime the complexity of the argument requires the usage of Fishbone diagram.
10. Event – It is the situation that triggers the occurrence that influences the outcome. The event cannot be analyzed without explicit references to the Cause.
11. Consequence – Its description cannot be limited to the financial costs (impact). Again the importance of a clear and fully referenced description represents a huge asset for the project.
12. Impact – This topic has been discussed in that post . In essence, it is the cost to be paid if the event had it full effect on the output.
    1. Inherent – It is the main part of the analyzed risk.
    2. Residual – It is the remaining part left by any action to be taken (mitigation etc.). The term remains meaningful only if it is still indicating an acceptable risk. See DAU definition.
13. Probability – AKA likelihood. While it definition is quite easy; its application presents a lot of challenges. Especially when the history (e.g. team productivity) is not available.
    1. Inherent – It is pointing out the main “flow”.
    2. Residual – It indicates the collateral situations. Sometimes, after a careful investigation of the “Causes” it is possible that these two values are reversed.
14. Expected Value – It is the correspondence of the Impact when we are dealing with the Opportunities
    1. Inherent
    2. Residual
15. Proximity – As discussed in the previous posts, this value gives the timing. However, there are some scenarios where the time is not a calendar value; it is created by other factors, for example: production rhythm.
16. Risk Response Categories (see post). It is one of the following type of action:
    1. Risk Response
    2. Assumption – the risk is positively accepted
    3. Transferred – any action that moves the responsibility toward an entity able to tackle it better (e.g. insurance)
    4. Mitigation – an action that reduces the impact. It could be a workaround.
    5. Avoidance – When the root of the problem can be eliminated
17. Risk Owner – The person who is responsible for monitoring the event. He/she has to be just one for each risk and directly involved in the production.
18. Risk Status – It states the condition of the process. These can be some useful labels:
    1. Discovered – it has been classified, but it is still not assessed.
    2. Analyzed – there is a “price”, but the Owner is still to be assigned.
    3. Allocated – The Owner have been assigned.
    4. Active – The event is not yet happened.
    5. Pending – The event has been triggered, operations are undergoing.
    6. Closed – The event did not happened.

More readings

http://www.bmpcoe.org/library/books/rmg%206th%20edition/2.html

At the project’s definition, this value is associated to well define the threshold. It is the boundary that fixes the boundary on the Risk Matrix.

On the daily basis, this [...]]]> Cultural risk attitude is the value for gauging the proclivity toward a possible event that, if it happens, can modify the single output or the whole outcome.

At the project’s definition, this value is associated to well define the threshold. It is the boundary that fixes the boundary on the Risk Matrix.

On the daily basis, this limit has to be understood and evaluated by each risk’s monitor; the person (mostly senior producer / technical leader) who is responsible to look at the actual trend. Once the proximity has been reached, a quick and clear statement shall be sent to the Project Manager, who will start the defined procedures (usually an Exception Report, where the actual scenario and the possible actions are presented to the Sponsor).

People are the most important asset

“According to HBS professor Teresa M. Amabile and doctoral candidate Colin M. Fisher, “People will be most creative when they feel motivated primarily by the interest, enjoyment, satisfaction, and challenge of the work itself—and not by external pressures.” This insight is explored in their book chapter “Stimulate Creativity by Fueling Passion” in The Blackwell Handbook of Principles of Organizational Behavior.”

In Risk Management reading viewpoint, the key word becomes “
challenge” to be intended as the ability of daring; in other words, a bias influencing the judgment.

Previous experiences (either success or failures), familiarity with the specific issue and personal attitude (and many other factors) form the pattern used for making the decision.

Understanding the pattern

To be useful, any law needs to be known and accepted by most of the community’s members. Stakeholders are a community that shares a “special” set of rules that usually are derived and adjusted from the company.

Laws (formalized into processes) are produced by the dominant culture and shaped on the existing environment. In IT this corresponds to the technology. However, laws just ideas with some force behind. These concepts need to be interpreted for becoming effective.

The process of interpretation makes the difference between success and failure.

The personal maturity and risk hazard

It does not require huge bonuses and poor understanding of math for taking risks that are not accepted by the project’s charter.

Maturity or adulthood is a state of being conscious of most of the traits forming our personalities. The mosaic of patterns that help us in the process of taking decisions and then communicate the result for coping with it.

Usually the concept of maturity is applied to the whole organization. It serves for gauging the company’s ability for performing the stated processes. More these are carried through within the given allowances, more this grade is higher. Nevertheless, companies are made by single human beings. An honest (based on the humble and continuous process) assessment of the capacity to measure the gap (if any) between the personal pattern and the project’s standard is an essential requirement.

Managing projects includes the crunching of a lot of data. A well working system could provide a steady flow of information that, given the reliability grade, offers a picture of the actual situation and then possible scenarios.

This model remains valid for most of our activities. Sources and kind of data can vary a [...]]]>

Drawing symmetry

Managing projects includes the crunching of a lot of data. A well working system could provide a steady flow of information that, given the reliability grade, offers a picture of the actual situation and then possible scenarios.

This model remains valid for most of our activities. Sources and kind of data can vary a lot (from figures to facial expressions) and the logic of the whole process does not chance.

The power similitude

There is a good book from  du Sautoy “Symmetry: A Journey into the Patterns of Nature” about the importance of symmetry in our ability to read and understand the nature.

There is a particular idea that fascinating me, it is about the need of our brains to recognize items based on their common factors.

On the Wired magazine, there is a nice article focused on the fallacious interpretation of a very scientific and technological result like a fMRI. In essence, this very powerful machine was “accused” to produce an image of the though of a dead salmon.

Looking for confirmation

Our attitude to interpret facts (and figures) is naturally conditioned, not only with our biases (caused by the adoption of determined patterns), but with less professional want for assurance.

Like most (if not all bloggers) I am interested about the figures produced my “colleagues”. The results are extremely different. It depends upon the chosen values (assuming that used tools are working with the same rules).

Clearing the field

Any time, starting from the negotiation of the project’s mandate, the understanding (if not sharing and accepting) common values make much easier the communication.

In French (like many other languages) there is a common phrase: “Plus la ça change, plus c’est la même chose”. My guess, we are using this concept when dealing with other people old ideas. It could be a good policy to adopt this rule for understanding our biases.

Conclusion

What can sound like astonishing good (or bad) needs much more attention (i.e. using different – perhaps more sophisticated – tools). A sudden change in the temperature of our emotions can be read as a signal that something is very close to a red herring.

Since the leadership is classified as source of risk, it is essential to understand it and then find, if possible, a simple way for measuring its efficacy through the evaluation of results. Merriam Webster’s definition: “capacity to lead”. In a project environment, this should be focused on the stakeholders’ relationships. In particular [...]]]>

Leading is about direction

Since the leadership is classified as source of risk, it is essential to understand it and then find, if possible, a simple way for measuring its efficacy through the evaluation of results.
Merriam Webster’s definition: “capacity to lead”.
In a project environment, this should be focused on the stakeholders’ relationships. In particular to the team; when the production is carried out on the site.

The role of communication

Accepting this viewpoint, the most important, if not the only tool made available to the manager is the communication (on this subject, there is a very good post of JD).

Communication is implicit in the manager’s job nature. Whatever is the decision taken, it has been based on incoming information and then – much more important – to find the clincher for selling it, either to the team or other stakeholders.

“Know thyself“

It is one of the three phrases written on the Apollo’s temple in Delphi.
This approach can help ourselves in the process of acknowledging the drives and reasons that entered in our decision and then in the plan. Therefore, the execution of delivering it.

Living in an “illogical” world made of numbers

Whether you are Panglossian or not, our world is far from being subject to rational laws.
However, the results of our projects are measured with figures.
Leadership seems the art of understanding how it works the murky, flawed and semi-primitive nature of our own decision-making, including the heap of uncertainties. Then, using “black arts” convincing our fellows that the proposed act is matching with their personal and professional values; It therefore, will increase their well-being.

A balance between standards and innovations

There is a nice Crossderry’s post about the difference between leaders and managers.

An organization needs governance. Managers are set for checking that the rules are applied at their best. However, people who strive for growing personally and professionally can find difficult to abide to all of them, in particular when external challenges are pressing for new and better solution.

Leadership as source of risks

The previous paragraphs introduce two possible sources of risks:

1. Lack of ability to buy-in the required resources
2. Unbalanced response to the pressures, which could damage the project outcome and the company discipline and/or image in front of the customer.

These keys could suggest an indirect method for measuring the impact of a poor leadership on the project’s output.

Conclusion

Good managers come in all flavors. This matches with the multifarious nature of project’s needs.

In essence, the chances of success are strongly increased when the right group of managers (sponsors, project managers and team leaders) are able to develop an environment, whose rules can work with the global governance, that allows every stakeholder to give his/her best.

Sometimes, problems like disloyalty, kicking back etc. can be made worse – if not caused – by the lack of an environment that does not allow a proper leadership.

Managing risks is about to remove the root of possible problems. In this case, there are some actions to be planned and executed:

1. Being sure that everyone knows and accept the “Responsibility Assignement Matrix”
2. Checking that within the project’s management team there is a good “team playing spirit”
3. Whenever an “order” is issued, be sure of attaching a list of KPIs.

“Leadership is unlocking people’s potential to become better.”

More readings

• http://herdingcats.typepad.com/my_weblog/2009/08/20-reasons-managers-fail-and-ways-to-fix-them.html
• http://www.projectmanagementguide.org/project-management/when-good-teams-go-bad
• http://alistair.cockburn.us/Neurons+with+legs+-+How+wideband+social+media+is+changing+the+world%27s+cognitive+structure
• http://www.greatleadershipbydan.com/2009/08/new-leaders-pocket-guide-to-improving.html

Risks are (measurable) future uncertainties that influence the project’s output.

Issues are already happened facts that reduce the project’s benefits. At the best, in terms of decreasing the available resources; those put away for dealing with the risks’ consequences.

Risks are “potential” issues. The formers, if not properly dealt with, can generate the latter. Once [...]]]>

Watertight bulkhead

Risks are (measurable) future uncertainties that influence the project’s output.

Issues are already happened facts that reduce the project’s benefits. At the best, in terms of decreasing the available resources; those put away for dealing with the risks’ consequences.

Risks are “potential” issues. The formers, if not properly dealt with, can generate the latter. Once it has happened, the issue shall be managed with specific techniques, then they will be registered as “Learned Lessons”.

Properly sterilized of any chance of “pointing the finger”, they will be “dissected” in the following elements:

1. Nature: in which area has occurred the event?
2. Source (root cause) understanding the specific scenario (methods, conditions  and their application).
3. Event: what has triggered the problem .
4. Likelihood: how many similar situations has escaped the problems?
5. Impact: which type of resources were required for avoiding/limiting the damages.
6. Which has been the winning strategy to reduce the damages (e.g. hiring an expert, removing the clear and unique/major cause of the problem, improving the needed skills).

These four elements are needed for improving the efficiency of the Risk Management.

Nature

The importance (impact) of risks depends upon the project’s scope. It could range from delivery time to performances or costs. Varying the importance imposes different strategies, for example:

1. Establishing the threshold’s value.
2. The specific resources dedicated for setting and monitoring the trigger
3. The kind of action to be used for reducing the impact

Source

Understanding the surrounding conditions which brought that effect has the same value as finding the cause of it.Like an explosion, the most important factor remains the presence and quantity of inflammable materials.

Event

This element does not vary so much. However, it is extremely important to understand and clearly stated the specific reason that created the problem. This requires to frame the action (or the lack of it) in the proper scenario.

Likelihood

It is just a figure, usually produced by math tools. This number is strictly related to the estimations – especially in the way these are worked out.

Impact

How much “money” did total the damage? From the answer, it would be easier setting the weight of the “potential” damage on the budget.

Winning strategies

The result shall be chosen among these elements:

• Avoidance
• Mitigation
• Transference
• Acceptance

The limits of crises management

When the risk has been actualized, most of the available resources are absorbed by the efforts to limit the damages. This reduces the range of options, either for the sense of urgency or lack of solutions obtainable within short time.

Fire-fighting is an activity that could be emotionally rewarding, a sense of heroism can pervade the whole team. This could increase the sense of cohesion, that will be paid with a high price. Gung-Ho attitude in a commercial enterprise could seriously reduce the ability to deal with other stakeholders (to be perceived as enemies).

Conclusion

Risk Management is a fundamental part of the Project/Program Management. Instead of thinking in terms of silos, it is better to reason using “watertight bulkheads” method. Once the crisis has been solved, the issue shall be sanitized and each of its parts, used for improving the management of risk.

“Take calculated risks. That is quite different from being rash.”

Thanks Craig. You got right about the need for frequent and more specialized controls.

By the way, originally “milestones” (in the Roman roads) were set every mile (0.91% of the Imperial mile). Every day-long leg (15-18 miles) there were structures serving both passengers (divided by categories) and animals. An interesting point was that [...]]]>

Titanic in dock

Thanks Craig. You got right about the need for frequent and more specialized controls.

By the way, originally “milestones” (in the Roman roads) were set every mile (0.91% of the Imperial mile). Every day-long leg (15-18 miles) there were structures serving both passengers (divided by categories) and animals. An interesting point was that all measurements were taken starting from just one point.

In essence, all the territory was divided in smaller units for making possible and easy any comparison.

Milestones and BDUF

In many fields, in order to obtain the needed money, customers want to see “detailed” specification both in time and features.

These types of situations needs that controls are set in two different and complementary ways:

1. Consider the check point as a tool for setting guidelines (assuming that big projects span over long periods. Therefore, impending modifications are difficult to be avoided).
2. Once operational details are left to the team, controls have to focus on its capacity to deliver up to the specifications, both in terms of “quality” and “quantity”.

Some organizations, which rely on “functional model”, view in the BDUF a way to reduce risks. This viewpoint obtains a huge increase in threats to the output. A rigid structure is fragile. Titanic offered a terrible example, how a fragile structure was dealing with uncertainties.

For their nature, milestones are there for measuring results.

Any change is a result. Assuming the need for controlling performances for business reasons, there is a list of questions that could help us in the definition of what is measurable (and why):

1. Who decided and approved what shall be measured?
2. When controls should be activated? Where a trade-off between frequency and costs has to be struck)
3. What is the standard value for comparing so different items? For example, analysis and development need different approaches for measuring results. If money, it has to be actualized using parameters that are based on common and shared values)
4. How can we evaluate the stakeholders’ importance (and priorities)? Either in evaluating results vs. committed efforts.
5. Which is the reference for measuring the direction (thinking in terms of polar coordinates)

Some technical concerns

Regarding the analysis, controls can easily verify the business area covered.

Whether the outcome complies with developments and then the business viewpoint or not, is a much more difficult task. The evaluation can be done after the successful execution of functional tests.

At a development level, for customers’ viewpoint the GUI offers much more room for appraisal within shorter periods, than an enterprise business logic or databases developments.

When milestones can be conceived?

In my opinion, they should be produced by a “logical system”, either during the issuing of WBS or Product Backlog. It will be the project’s nature to dictate the frequency and type of milestones. The concept of making them repeatable is a huge bonus. A partial solution could be finding in the automation of the data collection, the rest remains up to each project manager’s ability to deal with stakeholders.

Conclusion

I am conscious that the concept of “done” has been left out from this post. It seems easy to establish rules on pure technical matters. However, it cannot be limited to a checkpoint list (although it is necessary).  “Done” should be enlarged until it includes the idea of “sold”.

“My life is full of mistakes. They’re like pebbles that make a good road.”

More readings

http://svprojectmanagement.com/are-you-organized-for-success

Photo from http://www.nordikfolk.com-a.googlepages.com atitanicstorybymike&ernstulrikpersson  May 4, 2008

In the Business Case, Risks are future occurrences that could reduce the ability to respect Costs and Timescale (and Performance).

The risks are shaped by “Options” and the resources needed for reducing their impacts should be found within the “Benefits Expected”. If the strategy for tackling a risk is based on its [...]]]>

Finding the right connections

In the Business Case, Risks are future occurrences that could reduce the ability to respect Costs and Timescale (and Performance).

The risks are shaped by “Options” and the resources needed for reducing their impacts should be found within the “Benefits Expected”. If the strategy for tackling a risk is based on its acceptance (yesterday’s post) , “Reasons” should be strong enough for sustaining the (potential) damage for the ratio that has not been covered by any form of hedging.

Risks in relation with contract’s type

PMI supplies three forms of contracts:

Fixed price:

A lump-sum amount will be paid for the delivery of well defined outcome (either product or service).

Cost reimbursable:

The seller will receive the corresponding amount of the incurred expenses plus a fee representing the seller profit. Costs are categorized in direct one (those incurred  for the exclusive benefit of the project) and indirect one (the company’ overheads).

Time & Material:

The seller makes available resources, whose costs are categorized by professional skills. In this case there is no incentives related to meet or exceed selected project’s targets.

Whatever is the chosen contract’s type, the basic risks remain the same. They could be resumed in few questions:

1. Are the estimations (likelihoods) “good enough” for allowing the people with the right skills and means to match the requirements?
   1. What does mean “good enough?
      1. If estimations are too optimistic create a situation where less money available reduces the possibility either to hire the people with right skills, or they do not have time and “machine” sufficient for delivering the “product” with the stated properties and qualities (either features or performances)
      2. If estimations are too large, the buyer would find difficult to accept a price beyond the market value.
2. Is the concept of “Quality” shared among all stakeholders? It shall encompass all aspects of the project. These are some important topics:
   1. Clarity and feasibility of requirements.
   2. Criteria for evaluating the importance of each feature (i.e. bluntly: how many users will benefit from it?)
   3. Is the chosen architecture (COTS) near to the product’s needs?
   4. Is there enough familiarity with the proposed technologies?
   5. What can be considered properly “done”?

Productivity is not enough

Reducing the process of producing software to the development (perhaps with the collaboration of a “special” stakeholder) offers a good chance of  “if you build it, they will come” situation.

Whether the project covers all step of the product’s implementation, or it is limited to the production, the Business Case has to supply valid interfaces for the remaining processes.

This is a simple list, just for reminder:

1. implementation
2. functional tests
3. documentation
   1. for users
   2. maintenance
   3. learned lessons (best source for next estimations)
4. training
5. maintenance

Conclusion

Considering the “Reasons” as questions and “Options” (with Costs and Timescale) as answer could improve the role of “Risk” as first test for the project’s feasibility, in first instance and then to probe the organization’s capacity to deal with the uncertainties.

Collaboration remains the key value.

“A ship is safe in harbor, but that’s not what ships are for.”

More readings

http://johnastrello.com/?p=124

http://shapingsoftware.com/2009/06/22/patterns-and-practices-of-lean-software-development/

http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts

D/load PDF version

Thank to Glen (Herding cats) for introducing this important topic. The standard formula used for calculating risks (that is presented in most Project Management manuals) shall be presented in a less trivial way.

There are at least two areas for improving the usage of the formula (and derived matrix):