Changing how IT projects are viewed can help improve the odds of success. Consider this: If the definition of a successful marriage was that the couple never had a disagreement, then the odds of success would be close to zero. It is equally absurd to define the success of projects by how closely they adhere to plans created in the early stages. On the other hand, it would be absurd to define a successful marriage as one in which neither spouse killed the other. Similarly, a project is hardly a success if its barely breathing carcass is dragged across the finish line long after the reason it was initiated has been forgotten.

Managers should view projects as chess games. Good chess players start with a general strategy and a detailed plan for the early stages of the game. After a few moves, the plan needs to be constantly revised in reaction to the opponent’s moves. The strategy remains the same, but the moves change. IT projects likewise need to be constantly adapted to changing conditions while remaining faithful to the overall goals. Success at IT projects and chess is defined by the end result and not by the degree to which the original plan was followed.

Organizations are in much better position to succeed when realistic assumptions underlie the mental picture of success. These realistic assumptions include:

• It’s impractical to attempt to understand every aspect of a problem.
• Complex problems are made up of an intricate web of smaller ones.
• The nature of the problem will change over time.
• The more time passes, the more change will occur.
• Any complex design will be imperfect.
• There will not be enough human talent available to create the optimum solution.

The Better Approach

Not all information technology projects fail. What separates failed projects from successful ones are six things. These are:

• Strong leadership. As the talent, motivation and experience of project leaders increase, so does the chance of success.
• Time control. Time is a project’s worst enemy. Successful projects are those that are manageable but subject to time pressure.
• Resource limitation. Successful projects limit the number of people involved.
• Scope control. Limit the scope, and chances of success increase.
• Staged evolution. Successful projects break what needs to be done into manageable parts. They follow an evolutionary path.
• Concept recycling. Successful projects invent as little as possible. A highly innovative system can be constructed from proven components where a small number of totally new ideas are included. Successful projects borrow ideas and building blocks from any legally available source.

The foundation for a better approach to projects is iterative development. Mother Nature has been using this design philosophy for billions of years. Evolution has been shown to be a simple and powerful way to develop systems of incredible elegance. The logic of evolution is to create something new, try it in the field, introduce variations, incorporate those that are successful into the design, and reject what doesn’t work.

The essence of evolution is incremental improvement. Evolution teaches us that iteration is the best way to develop a great design. Innovations are tested incrementally under real-life conditions, and those that represent a true improvement become part of the design. An iterative and incremental approach to projects incorporates this concept by encouraging the testing of new concepts, one at a time, under real-life conditions and keeping those that actually work. The way that projects proceed under this approach includes the following steps:

• Create a long-term vision. But don’t spend a lot of time making it perfect. Expect that no vision is flawless.
• Evaluate the environment. Estimate how much time will pass before the next major environmental change will occur.
• Break down the problem. What are the most important goals of the effort? Are there opportunities to quickly make high-impact, near-term improvements?
• Plan the first step.
• Iterate activities as needed. Build and test anything new in manageable increments.
• Make it happen! The first operational deployment needs to arrive quickly and create positive momentum.
• Evaluate and adjust. Once an increment of the ultimate solution is operational, re-evaluate.
• Update the vision. See how it stacks up to what has happened and update as needed.
• Plan the next phase.

Using this approach, the first step is to assign a task force to examine the issue and formulate a high-level view of the issue and how it might be solved. This approach is based on the principle that the best plans are made rapidly by a small group of people. Less than five is ideal, fewer than 10 is essential. They should understand that plans will be imperfect regardless of how much time or resources are invested. The task force should be encouraged to come up with solutions that can be put into place immediately. They need to know that a project isn’t the only possible outcome. If they do conclude a project is needed, they must first develop a broad view of the ultimate solution — the long-term vision. Then they decide what the first steps toward that vision will be.

Control Project Scope and Establish Accountability

The propensity for projects to grow in scope  is a major cause of failure. There is nothing wrong with systems becoming highly complex as long as it occurs in stages. What needs to be resisted is the desire to strive for a high level of sophistication all at once.

Let time determine the project’s scope. The problems and opportunities that need solving refuse to remain constant while we fix them. Economic conditions change, customer preferences evolve and competitors disrupt the market. None of this can be controlled or even accurately predicted. The only thing you can do is to limit the damage by shortening the time between concept and realization.

Let resource availability drive project scope. Just as time is an enemy, so is lack of resources. Instead of looking for the optimal solution, find the one that fits the resources available. That doesn’t mean you should expect too little from your people. Most do their best work when challenged.

Limit the size of the design team. The ideal size of a design team is three to seven people.

You must also gauge the organization’s ability to absorb change. Only a few organizations have established a culture where frequent change is the norm and stability is considered boring. In most organizations, change is feared. Today you have no choice but to make constant, constructive change an accepted part of the culture. Just don’t do it all at once. The right question is not how much change the organization will comfortably accept but rather how much it will reasonably tolerate. Slowly increasing tolerance for absorbing positive change needs to become a goal for every organization.

Imitate, don’t invent. That doesn’t mean violate copyrights or patents. It does mean you should take into account best practices and use available technology, such as packaged software, to your benefit.

A Single Point of Accountability

Create a single point of accountability. In an effectively managed entity, all participants have a clear understanding of their role and what is expected of them. Those who are accountable cannot make excuses. If things go well, they are rewarded, if not, they pay a price. It works because it motivates a single person to see that key goals are met even in the face of adversity.

You must select one person to be accountable for the project, and that person should not be someone from IT. Instead, make it someone from within one of the functions what will use or benefit from the resulting system. Those who use systems should be totally accountable for them, including their design, creation, cost, quality, functionality and value. No project should be launched before someone appropriate is chosen to be the project leader.

The project leader isn’t expected to personally handle the details of project management. An experienced IT professional should perform that function. The role of the IT leader is to support the project leader in a cost-effective and professional way. In other words, IT professionals are resources under the control of those who will use the resulting systems. Those in IT are accountable for satisfying the needs of those who use their services.

Using Packaged Software

In the early days of computing, applications were usually homegrown. Now, most are packaged software; IT projects revolve around the selection, customization, deployment and integration of packaged software. Packages are used because they reduce the time spent trying to conceive of new ways to perform necessary functions. They also reduce the risk that custom designed software carries — the risk it will fail in practice.

The traditional way to select a software package was to develop system requirements and create a Request for Proposal (RFP) documenting those requirements. When responses came back, the organization picked the one that seemed the best match and created enhancements to overcome any package limitations. That may seem logical, but it isn’t. There are several traps in the traditional approach, including:

• Asking users to articulate what they want before they have seen what is available.
• Believing that the RFP really represents what’s needed.
• Encouraging modifications that may turn out to be unnecessary.
• Taking a long time to reach a decision.

A better approach is to adopt a new attitude about packages. A package contains the combined wisdom of many other organizations. Their collective wisdom is likely to be better than whatever a single organization can develop. Good packages have used an evolutionary process to arrive at their current state.

If many organizations similar to yours use a particular package, it is likely that it will be a good fit. In fact,there should be a good reason to not adopt the most widely used approach before you reject it. The best approach is to visit one or two sites similar to yours to see the software in action before the vendor makes a formal presentation. Once you select a package, encourage its use exactly as intended. Invest heavily in training, especially after the package is online. It will take time before the software’s full capacity will be appreciated.