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.
Summary of Common Risks to be Assessed in Projects From the three lists (and the author’
s experience) of common project risks, a correlation can be seen, which leads to the top five risks affecting project success (see Exhibit 1). These risks should be reviewed on all projects to ensure they are being appropriately addressed.
Exhibit 1. Common Project Risks
Top Risk
Quick Response Description
Unclear or
Complete prototype and JAD sessions to ensure proper
changing goals
requirements are gathered
Lack of