Most projects follow the principle of “if it ain’t broke, don’t fix it.” As a result, small issues early in a project later become major problems. Risk management quickly transforms itself into crisis management, leading to missed deadlines or over-budget situations. These “crisis” situations generally follow a pattern in which the environment was not initially set for risk management to flourish. If only the benefits of a properly functioning risk management system were seen by business owners, they would begin to understand its necessity in any project, which leads to the number-one mistake.

Mistake 1 — The Benefits of Risk Management Are Not Presented to Business Owners

Business owners want results and many times do not want to be told of the multitude of issues affecting the completion of their project. They just want the project done, regardless of how a project team gets it done. Business owners tend to stay in a passive role when they should be actively operating in the project. Like a homeowner who is having a house built, a business owner needs to see the work site at set intervals throughout the build process, or the investment may fizzle away. It is recommended that a meeting be called in the early stages of the project to present the concept of risk management and to explain the benefits of this process. Below is a list of key benefits of risk management listed in priority order:

- An early warning system of issues that need to be resolved. Risks can be identified either before the project begins or during the course of the project. Once identified, they need to be prioritized, not only as to the effect they may have on the project but also to what level they need to be presented to management for resolution. A properly functioning risk management system can provide a daily assessment of the top ten risks affecting a project for immediate resolution. If the risks are not assessed routinely, the environment is set to allow these risks to fester. In this environment, a small issue can become much larger if not a damning problem down the road.

- All known risks are identified. Being able to sleep well at night is tough enough these days without having to think about all the unknown risks on a project. Through a properly designed risk management system, all probable and potential issues are likely identified. Reacting to this knowledge is key, but in order to act, a risk and the corresponding resolution must first be identified.

- More information is made available during the course of project for better decision making. By identifying all of the problems and projected solutions associated with a project, a deeper understanding of the project’s feasibility can be obtained. Especially early on, this information is invaluable and can provide more confidence to business owners and the project team that the project can be achieved on time and within budget. Further, risk management normally leads to improved communication among the project’s stakeholders, which can lead to improved team management and spirit. For example, a highly challenging project leads people to bond together in order to get the job done, just as passengers on a sinking ship need to stick together in order to save themselves. Finally, this information promotes a learning process for future periods during which risks (and their resolutions) can be reviewed as raw material when similar future projects are underway.

Mistake 2 — Not Providing Adequate Time for Risk Assessment

There is no getting around the fact that risk management provides a layer of management and additional time to the project, which leads to a layer of resources — or does it? It could also be argued that by completing a proper thinking phase up front, there is an application of the rule “Measure twice, cut once.” This phase should not be underestimated inasmuch as many projects tend to work under the principle of “Get it done by a certain date, regardless of the quality of the end product” rather than “Do it right the first time.” In many projects, there never seems to be enough time to do it right the first time but always enough time to do it right the second time. This mistake can be avoided by getting the agreement from business owners that the cost in time to implement risk management is fully outweighed by the benefits.

Mistake 3 — Not Assessing the Most Common Risks in Projects

There are risks that are common to all projects, regardless of the industry, based on various studies and research of past project performance. Three groups of common risks are now reviewed and then summarized to arrive at a final list of common project risks.

One such group of common risks was created by NASA, which sponsored a study of 650 projects occurring during 1960 and 1970 to identify key factors that led to unsuccessful projects. The major findings were as follows:

- Poorly defined objective

- Wrong project manager

- Lack of management support

- Inadequately defined tasks

- Ineffective use of the PM process

- Reluctance to end projects

Another study as to why teams fail, completed by the Hay Group and reported in September 1997 in USA Today, reported the following five factors in team failure:

1. Goals unclear

2. Changing objectives

3. Lack of accountability

4. Lack of management support

5. Ineffective leadership

Now that some failure symptoms have been identified for projects at large, the reasons why IT projects fail should also be reviewed. Rapid Development, a book by Steve McConnell, who spent many years working with Bill Gates at Microsoft, presents several reasons (discussed in the following paragraphs) why IT projects fail. For each reason, some methods of prevention have been prescribed.

Scope Control. Scope in a project can be defined as the range of functionality the end system will provide to the user. Scope is determined by the IT system require ments which, if poorly obtained, can lead to many problems down the road. It must be noted that a scope change of one half could lead to a two-thirds decrease in the project effort. Therefore, the project manager must strive to identify the minimum require ments of the system so as to ensure that minimum level is obtained before adding “bells and whistles” to the system. These additional requirements that are added to the system are otherwise known as gold-plating and have detrimental effect on the project because once they are announced to be completed, the project could be viewed as a failure if they are not delivered. This is true even if the minimum requirements of the system are met. There are many techniques for increasing the chance of obtaining a comp lete and accurate set of requirements while also understanding which requirements are the most critical to the final system.

Prototyping. Talking about system functionality is well and good, but actually seeing the end product can provide a wealth of new knowledge. Many times, the true requirements of the system are not known until a prototype is completed. A prototype could be drawn on a piece of construction paper and have no computerized functionality behind the facade. Regardless, this tool should be used on all IT projects prior to the actual design and development of the system to ensure that a common goal is understood before major work hours are expended.

Joint Application Development. Otherwise known as JAD sessions, this occurs when a cross-functional group of all system end users (and business owners) are gathered to review the business reasons for the functional requirements of the final system (what and how the system will perform). Before a JAD session is held, a working document is completed that summarizes the business reasons and functional requirements, based on interviews with key project stakeholders. This list is then reviewed, discussed, and debated by the JAD participants while a scribe documents the discussions. The goal at the end of the JAD session is to walk away with a final set of business reasons and functional requirements that everyone agrees with (given compromises among the JAD participants). The JAD session, from a deliverable standpoint, achieves the main goal of defining requirements, but it also has some added benefits:

- Increases “buy in” from project stakeholders prior to development

- Removes responsibility from the project team to define system requirements (and gives it to end users/business owners)

- Increases the quality of the product by arriving at a complete and accurate set of requirements

- Improves project estimates by exposing any items within scope prior to the project plan creation (allowing time for proper estimation)

Overly Optimistic Schedules In today’s fast-paced environment, where time is recorded in Web years (which may amount to only a few weeks or months), development speed exacerbates any identified risk. For example, because of the need to meet a predefined project deadline, if a project team rushes the system testing phase, a system may ship with unknown bugs. In this case, the short-term goal of a deadline is reached but the long-term goal of customer satisfaction and company brand image is compromised. In the majority of cases, a predefined date leads to an optimistic schedule. For example, when Microsoft Word was being developed for the first time, it was promised in six months from its initial inception, but took well over three years to finally produce. In this case, a seasoned project manager would submit the three-year plan while the “yes-man” project manager would still be showing a six month plan well into the second year!

Poor Team Dynamic and Programmer Heroics At the start of the millennium, the need for project managers and more specifically, technology project managers, has outstripped the supply, and this gap will only continue in the future. Employees are getting large signing bonuses, stock options, and many other benefits that are making it increasingly difficult to hire and maintain top talent. Some key traits of a solid human resource management system are as follows, in that the project team:

- Is provided challenging assignments

- Meets with a career counselor periodically to discussion long term career progression

- Receives generous acknowledgement of successes (other than more work)

- Is appropriately matched to the resource requirements of the project

- Has a backup for key tasks (for knowledge transfer and to act as a contingency if the initial person leaves the organization)

- Does not work under an overly optimistic schedule, leading to “burn- out” With regards to “burn-out” the project team should be on the lookout for team member heroics when a person is expected to complete a task that would normally require months or extensive additional assistance in a shorter timeframe. These situations may be self-inflicted or imposed by a project manager and may not only burnout the person completing the task (leading, many times, to that person’s departure) but also may jeopardize the entire project.

Picking the Wrong Technology or Vendor Business is sometimes seen as a cold, impersonal activity as reflected in the old saying, “Nothing personal — it’s just business.” Nothing could be further from the truth as human nature does not allow us to easily separate the personal from impersonal. This leads to decisions being made not from the standpoint of quantitative analysis but because “the vendor rubbed me the right way.” Many vendors have surmised that you do not need the best product or service — just great advertising and salespeople. Therefore, project teams should be wary of decisions that are based solely on personal judgment rather than on a quantitative decision analysis using a generally accepted method (e.g., Kepner Tregoe). A due diligence process should have been completed for all major vendor and technology decisions, and for the short list of key vendors, a reference check should be performed and documented.

One example of a technology decision gone sour was a company (that will remain name less) that believed it could settle its Y2K troubles by selecting a package that would, in one weekend, fix the Y2K problem. The cost of the product was high, but it would save months if not years of development and testing — well worth the cost. It was even based on a principle that made sense to even those who were not technology savvy. Months went by, and no Y2K work was completed because a solution was always available — or was it? Once the millenium was near, the product’s capabilities were further analyzed and, more importantly, existing customer were surveyed. It was determined through these interviews that the product did in fact do its work in a weekend. But, it then took numerous other months to reprogram many of the existing programs to understand the change in the system. Without a detailed analysis, these facts may not have been uncovered until the last hour, leading to tragedy.

Mistake 4 — Not Identifying and Assessing Risks in a Standardized Fashion

As presented previously, there are four steps to implementing a risk management system: identify, assess, respond, and document.

Tracking System One popular method of tracking risks is to begin by having project team members submit their issues in a common centralized database. Although this may sound difficult to establish, one such database could be a simple Excel spreadsheet with various columns for the required information.

Monitoring Once the risks have been identified, they should be monitored weekly (possibly even daily in critical times). The desired result of such analysis is to attempt to ensure 100 percent visibility into the project. One benchmark to follow is to ensure that the top three risks are analyzed on a weekly basis (even better if the top ten risks are analyzed). To assist the monitoring process, it is helpful to segregate risks between those that relate to the project (which should mainly be reviewed by the project team with some oversight by business owners) and those to which only the business owners can respond.

REVIEW ASSESSMENT AND CONCLUSION

Given the top four mistakes that are made in maintaining a risk management system, the following questions can be arrived at, asked of the project team, and documented as to the responses to them. In addition to asking the questions, a walk-through should be performed to observe key risk management components. The major questions are as follows:

- Have the benefits of risk management been properly communicated to business owners?

- Has adequate time been provided for a risk assessment phase of the project?

- Has a specific individual been assigned to ensure that project risk management is completed?

- Has project scope been finalized and documented through either a prototype or a JAD session?

- Have project schedules been reviewed by an independent party for symptoms of schedule optimism (e.g., preset deadlines)?

- Based on the tasks at hand in the project, have the appropriate personnel been assigned, both at the project manager level and at the project task level?

- Have employee satisfaction techniques been employed, such as career counseling and acknowledgement programs?

- Have major vendor and technology decisions been based on a quantitative, documented decision analysis?

- Does a risk management tracking system exist?

- If yes, does the system contain all of the critical risk tracking elements.

- Are risks segregated into those that can be resolved by the project team and those by the business owners?

- How often are risks and their proposed solutions monitored?