There is a traditional way of using consultants to do projects that has been around for three decades. It typically involves large-scale planning, large numbers of consultants, considerable complexity, and fairly long time lines. The drawbacks of the traditional approach are all familiar: project creep, cost overruns, benefits that arrive too late or not at all, and user resistance. In today’s fast-paced business environment, such drawbacks can be deadly. But a new consulting methodology is emerging that trims the fat off of the traditional approach and makes implementing a project with consultants more nimble, more expeditious, more cost-effective, and more likely to deliver greater results and benefits. The heart of the methodology is to change how companies view projects. It involves making projects more solution-oriented, working with the resources one has, limiting scope, and creating a sense of urgency. At D.H. Andrews Group, one of the pioneers of this kind of approach, we call it the “Presto” philosophy. The purpose of this article is to look at some of the key elements of the Presto philosophy and how it can change the way companies use consultants.

Traditional IT Project Management

Traditional IT management principles view projects as logical series of carefully planned steps.

The first step usually is to define the scope of existing problems. End users are interviewed, and existing systems are studied and analyzed, often exhaustively. Consultants typically facilitate this step and may even orchestrate the project as a whole. The outcome is a detailed report laying out all the problems with existing processes and systems.

The next step usually is to employ additional consultants to create a system design. This step consists of pulling together users from different parts of the company to define exactly what the company needs and how to create the design. Users are encouraged to think of everything they might want in a new system to avoid having to add features later. Again, the outcome is typically a report that contains a carefully researched set of system recommendations, a set of subprojects to reengineer underlying processes, and an implementation plan. The latter usually lays out a careful product selection process, a process for defining enhancements and changes, and steps for rolling out the new system.

If management approves the plan, the consultants are often hired to oversee its implementation.

Drawbacks

Although some traditionally managed projects produce dramatic successes, it is not unusual for them to take longer than expected, cost more than budgeted, fall short of delivering the benefits originally expected, and use more consulting time than originally envisioned. The reason for this is that the traditional approach makes some unrealistic assumptions:

• A complex set of problems can be solved in one big project. Attempting to solve a complex set of problems in one big step makes projects daunting from the outset and diffuses resources. It virtually guarantees that nothing gets done very quickly. In addition, the longer a project takes, the greater the risk of environmental changes that can disrupt it or make it irrelevant.

• End users can determine in advance what they will want and need in a new system. In fact, asking users to define their needs almost always ensures that the scope of a project will be unrealistic. Users typically don’t know what they want until they’ve actually tried it.

• Perfection is critical. In reality, perfection is seldom attainable. Seeking perfection slows a project dramatically and may bring it to a standstill.

• Project scope should be defined first, then a time frame should be determined to fit it. Defining project scope first and determining time frames later ignores reality. If a project requires a three-year time frame and the company typically changes management every two years, it probably won’t work.

• Applications can be modified to suit individual business processes. Changes to software packages can delay implementation and compromise operability. Added time and complexity naturally increase the number of things that can go wrong.

• End users will embrace system changes. In fact, resisting change is a natural reaction among users. The more complex and time-consuming a project is, the more people are inclined to resist it.

• It is OK for results to be delayed. Not so. Failing to see results reduces commitment. People don’t continue to put energy into efforts that don’t produce tangible benefits quickly. Productivity lags, and projects fall behind.

• Users and consultants should share accountability. Actually, sharing accountability leads to no accountability.

Like life, projects are seldom orderly and logical. The system that users like most may not be the one that IT staff has the expertise to support. Consultants may push the system they have the most experience installing, which may require considerable modification to fit the business. External events might divert staff from the project. Existing equipment might be incompatible with new systems. The company might even be acquired by another company, adding the challenges of merging two totally different systems to the original task of redesigning just one. Complex projects with lengthy time frames, based on assumptions like these, are almost certain to run into trouble.

The Alternative

There may have been a time when the value of the ends could justify the frustrating and inefficient means of the traditional approach. That is no longer the case. Pervasive computing, the Internet, and the ability to create increasingly sophisticated software with less effort are creating opportunities faster than businesses can exploit them. To remain competitive, businesses must change far more quickly than they ever had to, and technology needs to be adapted at a far more rapid pace than ever before to support such changes. In addition, thinning profit margins make it all the more important to deliver results on time, within budget, and with fewer personnel.

Several years ago, D.H. Andrews Group introduced the Presto philosophy to address these needs. We cannot take credit for the basic ideas that make up Presto, although D.H. Andrews Group is somewhat unique in the way it organizes and applies the principles. What is important is that more and more businesses are turning to Presto principles to make important decisions about managing IT projects. The following are some key principles of the Presto philosophy:

• Create a long-term vision quickly, usually in a matter of weeks.

• Limit the scope of the original design.

• Keep design teams small.

• Treat complex problems as a series of smaller ones to be solved one at a time in an iterative fashion.

• Let the time available and the qualification of available resources determine the scope of the project.

• Make speed of implementation the top priority.

• Put major decisions in the hands of the departments that will use the new systems and applications.

• Establish a single point of accountability for the project—internally.

• Judge success of both internal staff and external consultants on measurable results, not on reaching milestones.

• Do as little inventing as possible. Implement existing packages exactly as they are designed, with minimal modifications. Adapt business processes to the package, not vice versa. Innovate only in areas that are most apparent to customers.

• Focus on essentials and changes that promise the greatest payback in the shortest amount of time.

• Do not expect perfection.

• Bring in outside specialists for their unique expertise pertaining to specific problems.

At the heart of all of these principles is a recognition that complex problems are made up of an intricate web of smaller problems and that the web changes all the time. It is impossible to understand every aspect of every problem at the same time or address all of the smaller problems at once. Even if someone does command a grand view of all of the pieces, many will have changed by the time there is a comprehensive plan in place to deal with them.

Implications for Working with Consultants

In traditional approaches to IT project management, consultants typically play a comprehensive role in planning and implementation. They frequently oversee lengthy processes of assessing the scope of a company’s problems and, subsequently, defining system and business process changes. They may also oversee product selection, definition of enhancements and changes, and implementation. They may even manage the entire project.

Businesses that follow Presto principles use consultants differently:

• They view the change process as too important to be left to outsiders. They use consultants to help define project parameters only if the consultant’s motivation is not to create a project of the largest size possible. They look for consultants who can help them define what is realistic within existing time and human resource constraints.

• They manage projects themselves. Consultants may provide assistance and guidance, but the full responsibility—and accountability—is internal.

• They see consultants as a way to leverage limited time and resources. They use them to supplement internal resources, not replace them or expand the project beyond what is realistic.

• They use consultants to get assistance with specific problems and tasks.

• They define everyone’s roles, including those of consultants, in terms of results.

• They cost out specific pieces of a project and pay consultants for successful completion of discrete tasks and measurable results, not for time and materials.

The Presto philosophy continues to rely on consultants as a valuable resource, both in planning and in implementation. Consultants are engaged, however, in a more iterative fashion, to handle selected projects and tasks and produce measurable results rather than remain with a large, complex project throughout an extended life span.

The Old vs. the New

Traditional methodologies work poorly in today’s business and technology arenas because these methodologies encourage excessive project scope and make assumptions that don’t match how people really work. The results of the old way have often been frustrating and inefficient and are hard to defend in fast-paced business environments.

So why do so many organizations continue to use traditional methodologies? One reason is that despite the flaws, a traditional approach has its advantages. It is essential to use organized, disciplined processes to manage the development of new information systems. A traditional approach provides such processes, and the better methodologies can be highly effective once agreement is reached on what a new system should accomplish.

Another reason is that many project managers who choose the methodology prefer large projects. Accolades can be great if a grand and challenging project succeeds.

Yet another reason is that, for consulting companies, selling large-scale services on a time-and-materials basis is lucrative: The more complex the project, the more time they can bill.

Finally, what you see isn’t always what you get. Successful project managers may start out with a traditional methodology but then break the rules to keep things moving. Success often occurs in spite of traditional processes, not because of them.

If that’s the case, though, then why not break the rules up front? Tackling projects in more manageable chunks while still applying disciplined processes (the Presto philosophy) will get you further faster than trying to do everything at once. A staged approach, though not as grand, will almost always lead to the same, if not better, results in a shorter period, with fewer cost overruns, and with better use of consultants. That’s far more important in today’s risky and costly business environment than sweeping plans, as impressive as they may look. You also save time and money by using consulting resources more effectively right from the start of a project.

As we start the next millennium, companies are seeing dramatic changes in the way they do business. Large budgets, extensive development teams, and drawn-out time frames will likely become a dim memory of the 20th century as companies strive to make technology changes more quickly and economically and see a more immediate payback for their efforts. If a Web year is 90 days—and shrinking—complex projects that require extensive resources and a long time to complete will almost always become obsolete before they reach their goals. As you and your company embrace emerging technologies, take some time to think about which project management and consulting paradigms will be the best to take you where you want to go.