Risks (negative and Opportunities as positive) are occurrences of an event that would modify the project’s outcome.

Only when the hypothetical course has been set, it is reasonable to evaluate the possible events that will have an impact on the output.

Each “Option” has different risks. [...]]]>

Like squirrels, reserves are essential

Risks (negative and Opportunities as positive) are occurrences of an event that would modify the project’s outcome.

Only when the hypothetical course has been set, it is reasonable to evaluate the possible events that will have an impact on the output.

Which are the risks’ sources?

Each “Option” has different risks. Deeper the digging into the details, more accurate will be the output. At a Business Case level, everything can only be evaluated at a high level. This requires that attention shall be paid to the possible effects generated by applying the chosen “Option”.
All risks are calculated with the following formula:

Risk = importance x likelihood.

1. The importance’s value is supplied by business vision and confirmed by cost/benefit’s analysis. It is expressed in money (costs and windfalls).
2. The correct amount should be worked out using the method chosen for the “Investment Appraisal” (following section) Capital budgeting.
3. The likelihood is expressed in percentage (100 represents certainty). The input will be supplied by analyses of similar situations. Working in a familiar environment, where the events had formed a history is a huge bonus for the reliability of the “Risk Analysis” (to be considered as a branch of the “Risk Management”).

Finding the correct values

The quality of every analysis depends upon three factors:

1. The reliability of the used formula(s) for retrieving and confirming the incoming data– its acceptance in academia and/or industry.
2. The number (quantity) of data and the correctness of their sources.
3. The intelligibility (and subsequent acceptance) of each risk’s label.

For the Business Case, these three rules can be easily respected.

1. In the logic of using “fractals” for producing the logic that sustains all projects’ documentations, these formulas will be used throughout the whole project. Those features that were considered “important” will receive more attention (i.e. resources). The figures forming the vectors (e.g. significance, costs, stakeholders’ quantity and importance) will be used as input for the formula for building the “Impact Matrix”.
2. The data to be used are coming straightforward from the document itself. This operational condition offers the opportunity of maintaining sound connections between the data used for taking decisions and the criteria adopted for applying them. Giving certainties creates a solid ground for mutual respect and comprehension.
3. The list of projects’ risks offers a broad view of the potential sources. However, managing a diagram composed of five categories for a total of forty-five items it is not an easy task. Furthermore, some categories are fitted for Sponsor (Snr Managers); others are prone to be considered as blames, more than just hypothesis. This does not reduce the importance of each item; the remark is focused on considerate way to propose the risks’ label.

How to present the risks’ impacts

The ubiquitous matrix (where impacts meet likelihood on a Cartesian Plan) offers a good entry point (good site)

However, the power of this tool is a bit overstated. The essential questions about Risk Management are to be focused on resources (people’s commitment and money available)

Who will be responsible for what

Starting from the categorization of the risks, it is obvious that some elements shall be addressed by Senior Manager(s) in conjunction with stakeholders.

How much can be spent

Other as much as important the allocation of budget for a global (administrative) support of the Project Manager, otherwise the outsourcing to external professionals.

Setting the reserves

The money to be put aside, are destined to finance all operations that would be activated if the event occurrence has overcome the threshold value.

Cultivating controls

The system relies on the ability of each person responsible for spotting the increase of danger and understand (at managerial level) the importance and reliability of this signal. People remain the powerhouse of the project.

Fixing the ceiling

Quite often the amount resulting from the matrix (the financial reserves) is astonishing high. It looks like the project is too riskier. The amount to be left as project’s reserve will work as cursor. Only the work-package(s) on production shall be covered . It would be better to close the project, saving what has been done to start with another “Option”, than do not start at all.

Conclusion

The Business Case is produced within a small circle of people: Senior Management, major stakeholders, architect/SME and the PM in charge. Everyone is called to take decisions that will form the guidelines. In situation like these, the quest for accuracy could hamper the process. Otherwise, documenting each proposal offers a solid ground for building the framework.

More readings

http://www.projectsatwork.com/article.cfm?ID=250401
Image courtesy of: http://ahmandishere.blogspot.com/2006/12/squirrel-intentionality.html

D/load PDF version

The “Options”  should be in the number of three; these are the main properties:

I am proposing the analogy between project’s documents and fractals, because geometrical rules could help in the process of introducing common methods of measurement. It, therefore, makes easier to set up and manage a PMO and then a program. Hard facts, emotions, little dirtier secrets (previous mistakes), interpretation of marketing, analysis, new [...]]]>

Sustaining and pressuring forces

I am proposing the analogy between project’s documents and fractals, because geometrical rules could help in the process of introducing common methods of measurement. It, therefore, makes easier to set up and manage a PMO and then a program.
Hard facts, emotions, little dirtier secrets (previous mistakes), interpretation of marketing, analysis, new legislations are among the real drivers for the projects. However, all these elements, sometimes a mix of them, shall be transformed in something rational.

Focusing on “rational” aspects

Ratio is based on comparison. All different and multifarious elements forming a project shall be counted and or measured using a common standard. It could be money and days.
The usage of geometric shapes could improve the production, recognition and subsequent approval of documents based on graphs (e.g. Gantt).
This approach leaves out a lot of issues that are classified as “soft-options”. These have to be dealt with maneuvering space within the budget allowance and a close monitoring from the Sponsor (a good post from Ron Rosenhead)

How to “design” a Business Case

In my previous post, this document has been presented as a self-sustained list of topics describing the project’s motivation.
Henceforth a series of posts will be dedicated to develop each element (Reasons, Options, Benefits Expected, Risks, Costs, Timescale, Investment Appraisal, and Evaluation) using the fractals’ concept.

Reasons (Business needs)

Maintaining our hypothetical CRM project, the questions proposed on the previous post have to be focused on this environment:

1. Where are located the salespeople?
2. Do they deal with the same line of products?
3. Is there just one currency used?
4. Which is the existing workflow after the order? (Assuming is JIT)
5. Which is the actual system for recording calls and developing follow-up?

A suggestion how forces can creates shapes

Behind each of these questions (this is an extremely small sample of the real set), there are the stakeholders. The rules that form the organization are wired in the persons’ behaviors. This is one of the “soft-options” elements that shall be considered, much earlier than the simple plans for training. The users will form a jury that can condemn a technical good result, just for not having being properly sold.

We can assume that the most important driver is the standardization of procedures through different countries.
In this situation, the technical issues (e.g. networking) shall be blended with financial aspects like currency markets.

Getting the picture

In the previous post, it has been hinted how to transform requests into more “visible” lines. The whole lot can take the form of a “complex” figure.
The concept could be explained using vertex for representing each “Reason” that will be connected – for example, to create a star. In this way, there are two “geometrical” elements for each “Reason“:

• Height – can be easily associate to importance (impact to the business) that dictates the priority.
• Steepness (angle between the base and the slope) – would measure the base (i.e.  support from stakeholders). This gives an idea about the number and urgence/importance of required functions.

In our example, each “Reason” takes the shape of a triangle (the basic geometrical figure). Its area can lodge the capacites; these are to be viewed as vectors :

1. Direction: offers the compatibility of the “request” within the “Reason”
2. Magnitude: it could be the added business value or the impact on the workflow (saved costs)

The magnitude’s figures be easily ordered for further analyses.

Conclusion

The picture of the business environment, in terms easily connectable with figures, makes easier to present the subsequent hypothesis.

“My subject enlarges itself, becomes methodized and define, and the whole, though it be long, stands almost complete and finished in my mind, so that I can survey it, like a fine picture or a beautiful statute, at a glance.“
Wolfgang Amadeus Mozart

More readings

http://www.ogc.gov.uk/documentation_and_templates_business_case.asp
http://austega.com/florin/ALGEBRAIC%20FRACTALS-FRACTAL%20VARIETIES.htm

Image from: http://weblab.open.ac.uk/firstflight/images/forces/forces.gif

A natural application of fractals

A mathematical fractal is based on an equation that undergoes iteration, a form of feedback based on recursion.

This could be roughly translated with the following definition: The same structure can be scaled into the smallest dimension, maintaining [...]]]>

A natural application of fractals

A mathematical fractal is based on an equation that undergoes iteration, a form of feedback based on recursion.

This could be roughly translated with the following definition:
The same structure can be scaled into the smallest dimension, maintaining the same pattern using the feedback.

A project is formed by the interactions (synergies) among the following areas:
Business Case (why)
Organization (who)
Planning (when)
Progress assessment (how much)
Risk management (what if)
Quality (whereas)
Change management (whence) http://www.merriam-webster.com/dictionary/whence

Each different (Prince2) “theme” inherited peculiar aspects from its major actors. From the Sponsor (and customers’ approvers) to developers, every person who will work on the project needs to share a common logic. The aim, to be understood and convincingly shared, shall be clearly presented and associated with a “logical logo”.
From the beginning, these shall be considered threads, which will be woven in order to create a seamless banner. It will be the project’s flag.
Some links could appear more natural than others. Listening to the major stakeholder in a meeting that involves all key-players can facilitate the search for the items that will form the knots.

The pattern, that will be shown in every decision and embedded in each document, shall be built in a unique way.

An example

In order to create a project about improving the coordination of work-force using CRM. If the main aim of the project is about increasing the follow-up yielding, there are some essential topics to be investigated:

1. Which are the business drivers that support these features?
2. How these requests are developed into a topic mature enough to be encased in a project?
3. Which are the other important features or benefits?
4. How the latter are connected to the main one?
5. Are there available analyses of the company’s workflow?

Focusing on the meta-information (i.e. how, where, who, why, when) it should be possible to catch the logic of their connections. The way they have been collected, can offer a good hindsight about the company’s culture; a key for preparing the pattern to be shared by all stakeholders.

In order to render pictorially the relationship among the features, it is fundamental to understand how they were picked up. Again some questions could make the process easier:

1. Was it a “one person” intuition? How had been that pushed through the (group) of approvers? If so, how the approvers took their decision?
2. Did it come from an external audit? If so, how had been it perceived by the stakeholders (users)? Or were “users” proposing the issue?

The intrinsic value of these questions consists in the possibility of drawing the shape of the decision’s process.

1. Is it a sharp vertex?
2. Is there just one apex or are there many important drivers?
3. Are the other items on the same priority’s level?
4. How many people (stakeholders) are pushing for each of the points?

The results’ of above analysis could easily help to draw the first draft of the pattern.

However, this pattern – to be in working conditions – has to contain (at least) the following elements:

1. One vertex for each “Benefit”
2. The steepness of the slopes for showing the impact on the business (sheer slopes show the priority)

Drawing and then counting

Just using the whiteboard, it is possible to pinpoint the sources that supply the “Reasons” (those will be stated in the Business Case), connecting the points with lines a geometric figure will come out. It could be complex. However, all the stakeholders can find their own expectations and an introduction of these outlined requirements. In a certain way, Risks, Cost and Timescale can be figured out.

In the next post, this concept will be refined and tested through the application to the Business Case.

Conclusion

Finding a design for the project helps it in many ways. People can more easily understand the logic and so joining the common effort with more consciousness.

One image is worth thousand words (N. Bonaparte)

More readings

http://crossderry.wordpress.com/2009/07/12/our-relocation-project-capabilities-vs-specs/
http://www.gantthead.com/article.cfm?ID=250051
http://austega.com/florin/ALGEBRAIC%20FRACTALS-FRACTAL%20VARIETIES.htm

Complex products are composed by different parts kept together by an unique logic. If, sometimes, it is possible to release prototypes with some “visible” features; [...]]]> The project has to answer to a (reasonably) well defined need. This answer, to be useful, has to be centered in only one logic that will be transformed into a product.

Complex products are composed by different parts kept together by an unique logic. If, sometimes, it is possible to release prototypes with some “visible” features; it does not mean that the whole product can always be split into separate objects, where each of these parts can be delivered to the customers for their approval.

Another kind of business case

From this starting point, the want for single documents that contains the whole logic is essential.
Everything starts with the Business Case. It is the first and most important baseline for an evolutionary process that includes some iteration.
It belongs to the Sponsor (aka Executive) and forms the guidelines for issuing the Project Manager mandate.
The reasons, for repeating these concepts during the Gantt’s analysis, stem from the need of creating a solid frame for referencing the workflow. The latter will be adapted to each company’s organization necessities.
These are the elements that compose the Business Case:

Reasons:

The drivers as presented by the “external” stakeholders.

The main outcome’s features are presented (possibly in order of priority). Whenever possible an estimation of their stability has to be included. This will influence both the estimations’ validity and the Change Management)

The customers’ organizational aspects have to be briefed highlighting the approvers and influencers.

It is fundamental to set clearly the type of output (e.g. product or service). Any reference to further maintenance and/or evolution is a key point for the choices to be taken in the next sections.

Options (listed subsequently)

The available alternatives have to be produced for the following areas:

1. Technical architecture
2. Approach (e.g. COTS, from scratch, prototype etc.)
3. Managerial strategy
4. Stakeholder’s analysis
5. Communication & Collaboration plan
6. Schedules imposed by external factors
7. Quality
   1. Test strategy
   2. Frequency and type of reviews and reporting
8. Procurement strategy
9. Contract type
10. Outsourcing
11. Vendor list
12. Documentation
    1. Future maintenance
    2. Handover to implementation team
    3. Communication among various stakeholders (from requirements to accomplishments)
    4. Manuals destined to training
    5. Administration chores
    6. Meeting minutes

Benefits Expected

The Business Case is owned by the Sponsor, but it is “used” by PM as well.

This requires including the “business vision” and then its strategical application to the project.

From the PM’s point of view, the strategy has to be focused on delivering the outcome as chartered in the stakeholders’ agreement (something subjected to be change at happenstance).

A solution for improving the success’ opportunities can be offered by linking benefits with the corresponding final product feature (Kano Model). This approach could offer a stronger lever for dealing with customers asking for lodging further requests (unsupported by an increase of budget / delivery time).

Risks

In this preliminary phase, it is possible to outline their nature. The list can help the PM and Sponsor to exclude those do not represent a menace to the project’s survival.

Other two essential sources for laying out the Risk Analysis come from:

1. Stakeholders’ analysis
2. Design walkthrough

Usually a narrow range of choices is a potential source of risk. This is due to the supposed indispensability of the “supplier”.

Costs

Available budget. This amount shall be confirmed by WBS results and should include tolerances (reserves). These have to be differentiated between those available to the PM and those requiring the Sponsor approval.

Timescale

Delivery date(s). Again the values provided by the estimations have to confirm the feasibility of the enterprise. The nature of the outcome and the customers’ interest could favorite the schedule of various releases.

Investment Appraisal

This is a topic to be tacked at two levels.

• The (beneficial) impact(s) of the project on the business shall be stated by sponsor and/or stakeholders.
• While the Project Manager has to be aware of the influence of the project on the whole business, he/she must keep the focus on the daily management of all tasks that allow the delivery of needed outcome.
  At PM’s level the project’s value is the budget made available.

Evaluation

This section pertains to the Sponsor. It contains the results of the “Investment Appraisal” (financial) benefits to be weighted against the costs.

Conclusion

The project is a complex enterprise. It requires the strong and clear willingness of participants to spend their resources (money and energy) for delivering an outcome that fulfills their expectation.

The adoption of a common pattern (as distilled sum of previous learned lessons) renders this operation easier. It has to be flexible enough for responding to each specific environment.

A business that makes nothing but money is a poor business.