Tathagat Varma

Tathagat Varma Session 8/12: 30-Jun-2010

  Project risks have the following attributes:  They're generally known at the beginning of the

project.  They can exist at a specific point in the project, or

they can persist throughout the life of the project.  They can materially affect the outcome of the project

if they become reality.  There's a reasonable likelihood that they could

become reality.  Risks are extraordinary to what normally would be

managed on a project.

  A sound method of identifying project risks is to look at your assumptions. Assess risks based on three factors:  Materiality  Likelihood  Extraordinariness

  When defining risks, try to limit yourself to the top six to eight things that:  Can seriously hurt the project if they were to occur.  Have a likelihood of occurring.  Are extraordinary to normal project management.

  A risk is an event that "may" occur. The probability of it occurring can range anywhere from just above 0% to just below 100%.   It can't be exactly 100%, because then it would be a

certainty, not a risk.  And it can't be exactly 0%, or it wouldn't be a risk.

  A risk, by its very nature, always has a negative impact. However, the size of the impact varies in terms of cost and impact on health, human life, or some other critical factor.

  Low impact/Low probability   Risks in the bottom left corner are low level, and you can often ignore

them.

  Low impact/High probability   Risks in the top left corner are of moderate importance - if these things

happen, you can cope with them and move on. However, you should try to reduce the likelihood that they'll occur.

  High impact/Low probability   Risks in the bottom right corner are of high importance if they do

occur, but they're very unlikely to happen. For these, however, you should do what you can to reduce the impact they'll have if they do occur, and you should have contingency plans in place just in case they do.

  High impact/High probability   Risks towards the top right corner are of critical importance. These are

your top priorities, and are risks that you must pay close attention to.

  Risk appetite looks at how much risk a company is willing to accept. There can still be deviations that are within a risk appetite.  A.k.a. “Risk Propensity”

  Organizations, projects, stakeholders and even individuals are willing to accept varying levels of risks.

  Risk tolerance looks at acceptable / unacceptable deviations from what is expected.

  The term contingency reserve refers primarily to the amount of quantity of funds or other financial resources that is required to be allocated at and above the previously designated estimate amount to reduce the risk of overruns to an acceptable level for thef inancially responsible organization.   However, contingency reserve need not refer exclusively to

monetary terms. It can also refer to a specific quantity of time in man hours that must be allocated above and beyond the previously determined quantity of hours required to assure that any overtime or other unexpected hours of work required can be properly compensated for.

  Typically the contingency reserves, in terms of both finance and time, are determined at the outset of a project. However, as a project is ongoing, if it appears that the project will require additional funds or time allocation to complete, contingency reserves can be instituted or modified at any time to better prepare the organization for the possibility of their usage at some point in a projects life.

  As per ISO, Risk management should:   create value.   be an integral part of organizational processes.   be part of decision making.   explicitly address uncertainty.   be systematic and structured.   be based on the best available information.   be tailored.   take into account human factors.   be transparent and inclusive.   be dynamic, iterative and responsive to change.   be capable of continual improvement and

enhancement.

  A dual logo IEC/ISO, single prefix IEC, supporting standard for ISO 31000 and provides guidance on selection and application of systematic techniques for risk assessment. This standard is not intended for certification, regulatory or contractual use.

  NOTE: This standard does not deal specifically with safety. It is a generic risk management standard and any references to safety are purely of an informative nature. Guidance on the introduction of safety aspects into IEC standards is laid down in ISO/IEC Guide 51.

  Provides principles and generic guidelines on risk management.   Can be used by any public, private or community enterprise, association,

group or individual.   Can be applied throughout the life of an organization, and to a wide

range of activities, including strategies and decisions, operations, processes, functions, projects, products, services and assets.

  Can be applied to any type of risk, whatever its nature, whether having positive or negative consequences.

  Although it provides generic guidelines, it is not intended to promote uniformity of risk management across organizations. The design and implementation of risk management plans and frameworks will need to take into account the varying needs of a specific organization, its particular objectives, context, structure, operations, processes, functions, projects, products, services, or assets and specific practices employed.

  Intended to be utilized to harmonize risk management processes in existing and future standards. It provides a common approach in support of standards dealing with specific risks and/or sectors, and does not replace those standards.

  Not intended for the purpose of certification.

  If you adjust any one side of the triangle, the other two sides are affected.

  For example, if you decide to adjust the project plan to:   Bring in the scheduled finish date, you might end up with

increased costs and a decreased scope.   Meet the project budget, the result might be a longer schedule

and a decreased scope.   Increase scope, your project might take more time and cost

more money in the form of resources, such as workers.   Changes to your plan can affect the triangle in

various ways, depending on your specific circumstances and the nature of your project. For example, in some instances, shortening your schedule might increase costs. In other instances, it might actually decrease costs.

  http://office.microsoft.com/en-us/project-help/a-short-course-in-project-management-HA010235482.aspx?CTT=5&origin=HA010355888

  http://office.microsoft.com/en-us/project-help/every-project-plan-is-a-triangle-HA010351692.aspx?CTT=5&origin=HA010359477

  In most projects, at least one side of the triangle is "stuck," meaning that you can't change it. On some projects, it's the budget. No matter what, you won't get more money for the project. On others, it's the schedule; the dates can't change. Or it's the scope; there will be no change in deliverables.

  The trick is in finding the "stuck" or fixed sides of your project's triangle. That tells you what you can change and where you can adjust if there's a problem. Phrasing the problem as a statement can help you clarify which side of the triangle is in trouble.

  Knowing which side of your triangle can't be changed will help you know where you can adjust. So when you begin optimizing, consider the following order of decisions.   First, decide which of the three elements is fixed. This is typically

the element most important to the success of your project (finishing on time, on budget, or with the agreed-upon scope).

  Then, determine which side your current problem occurs on. Once you've done that, you'll know what elements you have to work with to get your project back on track.

  Have you ever worked on a project that had a deadline? (Maybe we should ask whether you’ve ever worked on a project that did not have a deadline.) Limited time is the one constraint of any project with which we are all probably most familiar. If you’re working on a project right now, ask your team members to name the date of the project deadline. They might not know the project budget or the scope of work in great detail, but chances are they all know the project deadline.

  The following are examples of time constraints:   You are building a house and must finish the roof before the rainy season

arrives.   You are assembling a large display booth for a trade show that starts in

two months.   You are developing a new inventory-tracking system that must be tested

and running by the start of the next fiscal year.   Since we were children, we have been trained to understand

time. We carry wristwatches, paper and electronic organizers, and other tools to help us manage time. For many projects that create a product or event, time is the most important constraint to manage.

  You might think of cost simply in monetary terms, but project cost has a broader meaning: costs include all of the resources required to carry out the project. Costs include the people and equipment that do the work, the materials they use, and all of the other events and issues that require money or someone’s attention in a project.

  The following are examples of cost constraints:   You have signed a fixed-price contract to deliver an inventory-

tracking software system to a client. If your costs exceed the agreed-upon price, your customer might be sympathetic but probably won’t be willing to renegotiate the contract.

  The president of your organization has directed you to carry out a customer research project using only the staff and equipment in your department.

  You have received a $5,000 grant to create a public art installation. You have no other funds.

  For virtually all projects, cost is ultimately a limiting constraint; few projects could go over budget without eventually requiring corrective action.

  You should consider two aspects of scope: product scope and project scope. Every successful project produces a unique product: a tangible item or service. Customers usually have some expectations about the features and functions of products they consider purchasing.

  Product scope and project scope are closely related. The project manager who manages project scope well must also understand product scope or must know how to communicate with those who do.

  Product scope describes the intended quality, features, and functions of the product — often in minute detail. Documents that outline this information are sometimes called product specifications. A service or event usually has some expected features as well. We all have expectations about what we’ll do or see at a party, concert, or sporting event.

  Project scope, on the other hand, describes the work required to deliver a product or service with the intended product scope. Project scope is usually measured in tasks and phases.

  The following are examples of scope constraints:   Your organization won a contract to develop an automotive product that

has exact requirements — for example, physical dimensions measured to 0.01 mm. This is a product scope constraint that will influence project scope plans.

  You are constructing a building on a lot that has a height restriction of 50 feet.

  You can use only internal services to develop part of your product, and those services follow a product development methodology that is different from what you had planned.

  Project management gets most interesting when you must balance the time, cost, and scope constraints of your projects. The project triangle illustrates the process of balancing constraints because the three sides of the triangle are connected, and changing one side of a triangle affects at least one other side.

  If the duration (time) of your project schedule decreases, you might need to increase budget (cost) because you must hire more resources to do the same work in less time. If you cannot increase the budget, you might need to reduce the scope because the resources you have cannot complete all of the planned work in less time.

  If you must decrease a project’s duration, make sure that overall project quality is not unintentionally lowered. For example, testing and quality control often occur last in a software development project; if project duration is decreased late in the project, those tasks might be the ones to suffer with cutbacks. You must weigh the benefits of decreasing the project duration against the potential downside of a deliverable with poorer quality.

  If the budget (cost) of your project decreases, you might need more time because you cannot pay for as many resources or for resources of the same efficiency. If you cannot increase the time, you might need to reduce project scope because fewer resources cannot complete all of the planned work in the time remaining.

  If you must decrease a project’s budget, you could look at the grades of material resources for which you had budgeted. For example, did you plan to shoot a film in 35 mm when cheaper digital video would do? A lower-grade material is not necessarily a lower-quality material. As long as the grade of material is appropriate for its intended use, it might still be of high quality. As another example, fast food and gourmet are two grades of restaurant food, but you may find high-quality and low-quality examples of each.

  You should also look at the costs of the human and equipment resources you have planned to use. Can you hire less experienced people for less money to carry out simpler tasks? Reducing project costs can lead to a poorer-quality deliverable, however. As a project manager, you must consider (or, more likely, communicate to the decision makers) the benefits versus the risks of reducing costs.

  If your project scope increases, you might need more time or resources (cost) to complete the additional work. When project scope increases after the project has started, it’s called scope creep.

  Changing project scope midway through a project is not necessarily a bad thing; for example, the environment in which your project deliverable will operate may have changed or become clearer since beginning the project.

  Changing project scope is a bad thing only if the project manager doesn’t recognize and plan for the new requirements — that is, when other constraints (cost, time) are not correspondingly examined and, if necessary, adjusted.

  Each phase typically   Has a specific purpose   Accomplishes something unique   Has specific entry and exit criteria, often non-negotiable   Has different ‘intensity’ levels and requires different resource

usage and staffing in each phase   Is separated from another phase by some kind of ‘stage gate’

where it gets reviewed   Might be

o  sequential (previous phase must complete before the next could start),

o  overlapping (next phase starts without the previous one being complete), or

o  iterative (perform multiple activities for a subset of work in each iteration)

  Why do we need project ‘phases’ ? Why can’t we manage a project without phases ?

  The initiation stage determines the nature and scope of the development. If this stage is not performed well, it is unlikely that the project will be successful in meeting the business’s needs. The key project controls needed here are an understanding of the business environment and making sure that all necessary controls are incorporated into the project. Any deficiencies should be reported and a recommendation should be made to fix them.

  The initiation stage should include a cohesive plan that encompasses the following areas:   Study analyzing the business needs in measurable goals.   Review of the current operations.   Conceptual design of the operation of the final product.   Equipment and contracting requirements including an assessment of 'long-

lead' items.   Financial analysis of the costs and benefits including a budget.   Stakeholder analysis, including users, and support personnel for the

project.   Project charter including costs, tasks, deliverables, and schedule.

  After the initiation stage, the system is designed. Occasionally, a small prototype of the final product is built and tested. Testing is generally performed by a combination of testers and end users, and can occur after the prototype is built or concurrently. Controls should be in place that ensure that the final product will meet the specifications of the project charter. The results of the design stage should include a product design that:   Satisfies the project sponsor, end user, and business

requirements.   Functions as it was intended.   Can be produced within quality standards.   Can be produced within time and budget constraints.

  Executing consists of the processes used to complete the work defined in the project management plan to accomplish the project's requirements. Execution process involves coordinating people and resources, as well as integrating and performing the activities of the project in accordance with the project management plan. The deliverables are produced as outputs from the processes performed as defined in the project management plan.

  Monitoring and Controlling consists of those processes performed to observe project execution so that potential problems can be identified in a timely manner and corrective action can be taken, when necessary, to control the execution of the project. The key benefit is that project performance is observed and measured regularly to identify variances from the project management plan.

  Monitoring and Controlling includes:   Measuring the ongoing project activities (where we are);   Monitoring the project variables (cost, effort, ...) against the

project management plan and the project performance baseline (where we should be);

  Identify corrective actions to properly address issues and risks (How can we get on track again);

  Influencing the factors that could circumvent integrated change control so only approved changes are implemented

  Closing includes the formal acceptance of the project and the ending thereof. Administrative activities include the archiving of the files and documenting lessons learned. Closing phase consist of two parts:  Close project: to finalize all activities across all of the

process groups to formally close the project or a project phase

 Contract closure: necessary for completing and settling each contract, including the resolution of any open items, and closing each contract applicable to the project or a project phase.

  A meeting at the beginning of the project or at the beginning of a major phase of the project to align peoples' understanding of project objectives, procedures and plans, and to begin the team-building process.

  A kick-off meeting is typically a workshop type meeting and it may last from 1 to 3 days. It generally include several activities such as a project charter, a business plan review, team building exercises, a team charter, risk analysis...

  A kick-off meeting has four basic functions:   Publicly state the beginning of the project  Outline the project goals as well as the individual

roles and responsibilities of team members  Clarify the expectations of all parties  Create a commitment by all those who influence the

project’s outcome.

  A typical project planning kick-off meeting agenda covers the following aspects of a project:   Build a project framework: what are the project

objectives ? who are the stakeholders ? What are the criteria for successful completion ? What are the business objectives ?

  Update the business plan or business case   Organize the project governance: Who does what? What

are the responsibilities of each member? what are the reporting procedures?

  Build or revise the master planning (key milestones, sequence of activities, dependencies...)

  Initiate the risk analysis   Team building activities   Define the quality management plan, and in particular

the change control procedures

  A formal review held at the end of each project phase to gain consensus that the phase is complete.

  The objectives of the review are:   Verify that phase objectives have been met   Verify phase exit criteria   Evaluate phase performance in terms of:

o Has the schedule been met? o Has the required scope been delivered? o Do planned costs equal actual costs?

  Determine the effectiveness of software development processes used

  Identify process improvements   The required outcome from the review is to receive

authorization to continue to the next phase or close out the project if it is in its final phase.