s potential success. Then, while it becomes costly
in terms of time, money, and effort to resolve these problems, there is still little commitment.
To help generate commitment, team managers can take an inventory of team members, learning not only about their knowledge, expertise, and experience, but also about their maturity and follow-up. This allows the manager to seek their counsel appropriately. Managers can also use public disclosure to attain and sustain commitment. When team members’
input is visible, regardless of perspective, there
is less likelihood of their denying input or reducing commitment. Finally, and this is tied to the last point, team managers should not only gauge a person’
s ability to do a
task, but also his or her enthusiasm. While team members might have the requisite background, they may lack the corresponding level of excitement for doing a good job. Commitment comes from the heart — not the head.
10. SEEK SIMPLICITY, NOT COMPLEXITY, IN GOAL AND
PATH
Simplicity easily yields to complexity. That is, it is always tempting to make a situation or a solution as complex as possible. People make a refinement here and a slight alteration there, and before anyone realizes it, the result is totally different from what was originally envisioned.
Simplicity, of course, is not the same as being simple. While simplicity means identifying the shortest path, with a style that says “that’
s it,” simple is merely paint-
by-the-numbers and lacking in sophistication. Ironically, simplicity can appear the same as being simple because they both share the common characteristic of clarity.
Complexity, however, is quite different. It is sophistication gone amuck, whereby confusion rather than clarity is the guiding rule. And a lot of confusion can drown clarity.
In distinguishing between simplicity and complexity, simplicity is recognizable when seen, but not definable. While projects always tend toward complexity, good projects result in simplicity when completed. These are usually the projects that satisfy the criteria for success in regard to cost, schedule, and quality.
In determining whether a plan is simple or complex, the symptoms are quite obvious.
In the latter, many people request additions, changes, removals, or repositioning, so that the plan becomes full of exceptions and contingencies. Because this complexity makes it difficult to follow the plan, few ultimately do so. In another symptom of complexity, product developers must repeatedly explain their intent or meaning. In yet another indicator, the plan must be continually revised to accommodate different situations. The end result is similar to a rat following a path in a maze.
By contrast, simplicity forces clarity of thought, demonstrating clarity in destination and the path to take. It also requires less time and people resources to execute a plan, and gives people confidence because they know their mission and what must be done.
To encourage simplicity in project management, team members can first try to attain as much experience as possible in different environments; this provides insight on what works well. Also, they can capitalize on the experience of others to gain further insight.
Second, if team members determine that something can be done in two steps rather than four, they should choose the former, ignoring the tendency to believe that because something looks simplistic it must be wrong. More often than not, the correct solution is simplistic.
Third, project teams should ensure that all elements of a plan contribute toward accomplishing the final goal; otherwise, they should remove it. After all, it merely embellishes the plan, and might well increase complexity and confusion, either now or later. Finally, teams should remove biases from a plan. Thus, they should avoid treating an assumption as fact, and blatantly affecting approaches that have no basis in reality. Biases in fact and data only add to complexity.
NO COMPLICITY WITH SIMPLICITY
Typical high-technology firms seldom apply more than a few of the principles cited this chapter. Instead, their staff moves about “helter skelter,” trying to solve a problem with a complex solution that is likely a reinvention of what was been done earlier on another pro ject. However, while few team members agree with the solution, they concede at least temporarily, either because it eases the problem or someone important felt it was the right answer. If the problem remains unsolved, they might wait for someone to do some thing, all the while looking busy doing insignificant work. As this occurs, the schedule slides, the budget is exceeded, and quality deteriorates. Team members both fear and hope that the unsolved problem is caught during testing.
Even if half the ideas in this chapter are implemented on a project, performance will improve. The dismal track record of project success and failure, however, attests to the fact that few use such suggestions. The challenge is to get project managers and team members to embrace the recommendations.
Chapter 2: Nine Factors for Project Success John P. Murray
OVERVIEW
The successful design, development, and implementation of information technology (IT) projects is a very difficult, complex, and, at times, daunting process. However, although developing IT projects can be difficult, the reality is that a relatively small number of factors control the success or failure of every IT project, regardless of its size or complexity. There is nothing esoteric about those factors. The problem is not that the factors are unknown; it is that they seldom form an integral part of the IT
development process.
Of course, the recognition and management of these factors does not ensure IT
project success. Understanding the factors and the part they play in successful project management is one thing; appropriately managing them is something else.
In addition, there is a high potential for project failure in not recognizing the part these factors play, or failing to appropriately manage them.
If these factors are so clearly important and well-known, why do they not form an integral part of every IT project? The short answer is that they should. The issue here is that because they are not used, too high a number of IT projects suffer some degree of failure.
The phrase “IT project failure” often raises a specter of some colossal failure. For example, the project never goes operational, or it is abandoned in midstream after considerable expense. In addition, there are other, qualified IT failures, such as projects that exceed their development time and expense estimates, but ultimately become operational. There are also many projects that move to production status, but do not meet the expectations of internal customers as defined in the project specifications. And projects may be considered failures if the applications take too long to process the data, or if they regularly fail in the operational environment.
In short, many organizations do not have a particularly good track record in IT
project success. However, many IT project failures can be eliminated or mitigated by understanding and managing the nine project failure factors described in this chapter.
These factors should be recognized for the strength they can bring to every project, and accorded the attention they deserve.
THE NINE FACTORS
The following nine factors can and do make or break IT projects: 1. Appropriate senior management levels of commitment to the project 2. Adequate project funding
3. A well-done set of project requirements and specifications
4. Careful development of a comprehensive project plan that incorporates sufficient time and flexibility to anticipate and deal with unforeseen difficulties as they arise
5. An appropriate commitment of time and attention on the part of those outside the IT department who have requested the project, combined with a willingness to see it through to the end
6. Candid, accurate reporting of the status of the project and of potential difficulties as they arise
7. A critical assessment of the risks inherent in the project, any potential harm associated with those risks, and the ability of the project team to manage those risks
8. The development of appropriate contingency plans that can be employed should the project run into problems
9. An objective assessment of the ability and willingness of the organization to stay the project course
The reader will realize that none of the factors has anything to do with technology. In addition, all the factors are straightforward, and can be easily understood by anyone with a business backgro und.
Organizations that recognize and work to appropriately include the nine factors in IT
project development are taking an important step in moving to more consistent IT
project success. However, they will have to do more than recognize the factors’
importance. They must also understand the interlocked nature of the factors, which together form a mosaic of strong project management. If IT project success is to improve, the role and importance of each factor must be understood. A discussion of each of the factors will provide information about how they affect IT projects.
1. SENIOR MANAGEMENT COMMITMENT
When it is clear that a particular IT project has the interest, the support, and the commitment of the organization’
s senior management, everyone involved in the