These risks, associated with short-term projects, need to carry high weight and visibility by the team and must be well understood by the team members to ensure success. Moreover, fast moving projects need to show results quickly to satisfy management, especially for projects that are similar to those attempted in the past. This form of management pressure may force the team to take approaches similar to those past projects, only because of their successful history. This can be good if the approaches are current and apply properly to the project or they can be troublesome if past mistakes are unknowingly repeated. This can all be avoided if lessons learned are properly developed and more importantly, used during risk identification and development. Lessons learned are often over looked in an organization and seldom considered when risk management is conducted on a project.
Risk is often the most difficult part of the project to understand and control. It is the part of a program that combines background, skill, negotiation, and experience all into one package. Risk is defined as the deviation of one or more results of one or more future events from their expected value. Actually, the value of those results may be positive or negative, but it generally tends to focus on potential harm or downside risk that may arise from the future event causing the outcome to fail to attain the intended results. Statistically, risk is the product of quantifiable consequence of the event and the probability that it will occur.
In the past, projects were given to the most experienced engineers to help in controlling project risk because it was thought that experience was the most significant way to deal with risk. Also, technical background was viewed to be the cure-all for dealing with certain types of risk a project would encounter. Today, projects move so fast and resources are slim, it is hard to always put the most experienced people in charge of a program. Technical risk is usually unique and varies from project to project. Program managers with good people skills can leverage limited resources of technical expertise and still be successful. When projects of similar nature are conducted, there may be a pervasive expectation by management, that however fast the last project commenced, the succeeding project should be conducted even quicker.
In many organizations, risk is handled differently. Some organizations do not accept the fact that all engineering projects carry a higher level of risk because of the global nature of companies today. Risk elements such as a need for global communication, unknown global and political practices, and delays in progress due to distant locality are new and did not have to be dealt with in the past. When starting a project and preparing the risk documentation, the team must understand how risk is perceived by the management and stakeholders. It is important to make a short list and keep it visible to the team. Below are a few short rules that will help the team stay positive, no matter how intense the situation gets:
Accept a certain amount of risk but, be prepared for it.
Do not let the high risk elements drag the team down; all projects have risk.
Share the risks with the customer; they have a stake in the project as well.
Try to make the risk visible to the management and be sure they take ownership in the risk management process.
Be willing to be flexible when it comes to schedule and technical risk.
There are several items to be sure the team has in place before analyzing the risk on a given project. Be sure the management is standing behind the project and is ready for it to commence. Projects that are talked about or come with the phrase, “That should have been done years ago,” may have added risk for support and staffing, if the management is not committed to take on the project at that particular time. Make sure the business plan makes sense to the team. Make sure the business goals and objectives are clear and achievable. The stakeholders need to agree with the business approach and have backup plans should the economics not go as planned. Sometimes it is better to consider the business risks first and shared them with the entire team before generating schedule and technical risks.
Project Risk Management is primarily undertaken to improve the chances of the project achieving its objectives. The primary reason for risk management focus is to develop a credible foundation that the project is or is not feasible. Developing a Risk Management Plan using Lessons Learned as a foundation helps avoid making the mistakes of the past and gives the team security to avoid repeat failures. This is particularly important for senior members of the team. In most companies, the concept of capturing meaningful lessons learned is difficult to achieve. Usually they are the last items documented on a project at a time when the team is tired and eager to move on. The items must be expertly documented during the course of the project and given a living document perspective. Only then, will they be useful for risk management. Technical issues need to be documented in a manner that is easily understood, so retracable steps can be taken, if necessary.
Many companies using project management to control costs and drive projects for better success, depend on lessons learned to help cover past projects that either took too long to implement or were unsuccessful. Lessons learned data for past projects is difficult to gather and often the data is not readily accessible for similar projects. When a team sits down to discuss risk, it should start with a discussion of past similar projects and the lessons learned associated with those projects. The lessons learned should focus mainly on the high level successes or failures from the schedule, manpower and information exchange standpoint. From this high level, the team should then drill down into several of the technical issues that are similar to the project at hand and discuss if the failure was from managerial or process issues or if it was truly a technical issue. Most often, the team will find that these high-level management issues may still be present in the organization. The team members should discuss if the project will be affected by these lingering problems or if they need to be solved before the project can show success. By driving the project from a lessons learned mentality, two important project management issues will be addressed: 1) the risk element will have foundation and can rely on past company experience to be dealt with in a full and proper manner; 2) the lessons learned function will gain respect by the upper management and become a strong element requiring overall better documentation by the PMO.
Below is a suggested template for documenting the risks on a given project. The format is somewhat traditional for the risk elements; however, the option to drive the risk from a lessons learned approach, is included. As stated above, the team should start with a visible list of past lessons learned topics that apply to the project at hand when begining the risk identification process. This is also the time for a team to develop such a detailed lessons learned structure for their company, if one is not already in place. The team must identify the risk elements driven from that learned lesson of the past that may still apply to the current project. The team will then categorize the entries by customer, manufacturer, cost, technical, and so forth, to help define the focus area and add discipline to the approach.
Risk Matrix
Figure 1: Risk Matrix
The team should then proceed to accessing the impact and probability of the risk item, using a scale adopted by the team. Generally, a low, medium, high approach is suitable. A color coded scaling approach is suggested for better visibility to the management. The team should focus mainly on the high-impact and high-probability items and discuss them from a mitigation, or acceptance of the risk point of view. A back-up plan should be generated in case the risk is accepted and no action is taken in the beginning phases of the project.
Lessons learned, if developed properly in an organization, represents a library of valuable approaches and documented history that can help a company avert needless and expensive retracement of steps during a project. The greatest fear that results when taking on a new project is fear of unknown risks causing failure. When the project team studies the past issues documented by their predecessors and couples that knowledge to the risk management process, the unknown begins to be better understood and confidence builds amongst the team members.
References:
Identifying and Managing Project Risk, Tom Kendrick PMP, Amacom, New York, 2nd Edition, 2009.
Strategic Project Management Made Simple: Practical tools for leaders and teams, Terry Schmidt, John Wiley & Sons, 2009.
Project Management for Dummies, Stanley E. Portney, Wiley & Sons, 3rd Edition, 2010.
The Definitive Guide to Project Management: The fast track to getting the job done on time and on budget, Sebastian Nobes, Financial Times Prentice Hall, 2nd Edition, 2007.
No comments:
Post a Comment