|
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? | 
Disclaimer
