Project Management Institute

A 30-60-90-day approach to planning IT projects

by G. Tom Chaudhuri, PMP, and Leigh Hardy

SUCCESSFUL BUSINESS MANAGERS, faced with ever-increasing competition and more demanding customers, respond to these challenges by deliberately setting business strategy to take into account new realities and address them with timely business solutions.

These business solutions can take many forms, such as product pricing or a new internal organization structure. Often, however, the business solution depends on information technology (IT). The IT-based solution may involve a new application of existing technology or the use of a brand new technology. Both are plentiful in the rapidly evolving world of IT, and today's business manager is increasingly comfortable with the use of IT to support the business.

Most often, business managers understand the value that the IT solution can deliver. Usually, they will also have considered the organizational impacts and other implementation issues related to the IT solution. Also, they have a notion of the cost and time required to implement. With this as background, business managers typically involve a project manager to begin the project.

img

To the project manager, this business manager is the “client.” To deliver the solution, the project manager thinks in terms of the project plan necessary to create the solution that is being requested. The traditional approach is first to carefully define the project scope. Once agreement is reached on scope, the project's time and budget is estimated.

The complexity of many IT-related projects yields time and budget estimates that cause initial client disappointment because the time and cost is generally higher than anticipated. Response to this disappointment varies. Some clients look for other ways to get the IT solution, such as outsourcing or hiring contract programmers; others bite the bullet and go along with the proposed project plan.

Another source of disappointment in many IT projects results from the length of time required to deliver significant business benefits. During this time, many factors may cause the project to change drastically or even to be abandoned midstream. If the project does survive the duration, changing environmental factors may cause the benefits to be diluted or the solution to require major modifications to be effective. As a result, by the time the IT solution is delivered, the client will likely be disappointed.

To avoid such disappointment and to reduce the risks inherent in IT-related projects, we suggest a different approach to project planning: we call it the “30-60-90-day” approach. This approach requires subdividing a project into modules to deliver meaningful business results over time. Let's contrast this approach with the traditional approach to project planning.

Traditional Project Planning. The starting point for the project plan is careful definition of scope. Enlightened clients will spend considerable time with the project manager to ensure an accurate and complete description of the project scope. After all, it is the delivery of the functions defined within the scope document that will determine the success of the business solution.

“Show me the money” might be the unofficial motto of the IT project client. Project managers must tailor the planning and the presentation of the plan to offer a timely return on investment

Exhibit 1. “Show me the money” might be the unofficial motto of the IT project client. Project managers must tailor the planning and the presentation of the plan to offer a timely return on investment.

In our example, in-depth discussion with the client reveals that, of the seven functions required of the deliverable, only four are top priority. Understanding the business case behind the requirements helps the project manager to devise alternative plans that deliver the most valuable segments of the deliverable first

Exhibit 2. In our example, in-depth discussion with the client reveals that, of the seven functions required of the deliverable, only four are top priority. Understanding the business case behind the requirements helps the project manager to devise alternative plans that deliver the most valuable segments of the deliverable first.

Scope definition provides the base for defining the IT deliverable. This includes all necessary software, hardware and other components required for the eventual operation of the business solution. The project manager sets up a work breakdown structure to identify the project effort associated with creating the required deliverable. The WBS is used to identify tasks, sequence the tasks, identify resources for each task and estimate their duration. This helps develop the project schedule as well as the project budget. Considerations of buy vs. build are included in the tasks and related resources.

Once the planning work is completed, the project manager can present the project plan to the client for approval to proceed. In addition to the project schedule and budget, a completed project plan generally contains details such as the project justification, scope, objectives, constraints and assumptions. However, the client usually focuses only on the project's schedule and budget as these are the key parameters that affect the delivery of the business solution (Exhibit 1). Informal surveys of project managers have shown that the client is usually disappointed with the schedule and budget offered by the project's plan and the search for alternatives begins.

Alternatives that help cut schedule and cost include reducing the scope by eliminating parts of the deliverable; squeezing the schedule estimates (work harder, cut vacations, reduce contingencies); outsourcing to contractors who may be able to do the work faster. These responses, while understandable, often yield less than desirable results. The project team is under pressure even before they get started and the probability of successful on-time/on-budget delivery is vastly impaired.

Planning for Alternatives. A review of this scenario reveals that a key issue with the traditional approach is the focus on a single end project deliverable. Both the client and the project manager have a common interest in the project: to obtain business benefits from the project deliverable. However, under the traditional approach, the client's usual position is that the project should produce the deliverable all at once. The project manager's response is to create a plan to deliver this monolith, and a single schedule and budget is developed. If the client is unhappy with the project schedule or cost, it becomes difficult to negotiate an alternative that serves the common interest.

In anticipation of this situation, we suggest that the project manager carefully understand both the client needs and the rapidly evolving environment within which they are operating. The proposed approach uses this knowledge to subdivide the monolithic project deliverable into meaningful “chunks” that can be delivered over time. To do this successfully, the project manager segments the deliverable into modules and assigns priorities to each module. A separate plan is then built for each module; the overall project plan is a consolidation of the plans for each module.

Building this plan has two critical aspects: creating meaningful modules and prioritizing the modules. To do this successfully, the project manager has to work closely with the client to ensure that meaningful business benefits can be obtained from the subdivided deliverables. It is normal to experience resistance to this approach, because the client may feel that business benefits are in jeopardy. The project manager must emphasize that this approach will, in fact, better serve the client's interests, and get buy-in so that the client will actively support the definition of the modules and setting the priorities.

“30-60-90-day” Approach: An Example. Consider a project that calls for an IT application with seven functions to serve two types of customers (personal and business). The client has indicated that the deliverable must deliver the following seven functions to support the two customer sets: create servicing profile, produce power of attorney, create net worth statement, create net worth summary, create cash flow statement, create cash flow summary, and maintain contact history.

The traditional approach to project planning would call for developing a plan that would deliver the functionality as requested, in a single deliverable. In the alternative approach, we suggest that the project manager engage the client in a discussion regarding the relative priorities of the functions. A result of the discussion would be to categorize the functions into “medium” and “high” priorities, as shown in Exhibit 2. Another finding that surfaces in these discussions is that customer segments are known to be 10 percent personal and 90 percent business.

With this information, the project manager can proceed to subdivide the project into modules, as shown in Exhibit 3. Module A is high priority and includes two related “net worth” functions for both customer segments. Module B is also high priority and is similarly constructed. Module C contains the three medium-priority functions.

An alternative way to “chunk” the deliverable would be by customer segment. Module D delivers all seven functions for the business segment. Since the business segment is 90 percent, this would likely have higher priority than Module E, which supports the personal customer segment.

Project planning then proceeds as usual, except that three alternative plans are built. This requires creation of work breakdown structures for each module as well as developing a project plan for each module. This results in three alternative plans:

Alternative 1. All seven functions for two customer segments delivered at once (the traditional approach).

Alternative 2. The project delivered as Module A, then Module B, then Module C.

Alternative 3. The project delivered as Module D, then Module E.

Grouping the high-priority functions allows the project manager to formulate a plan that delivers business value sooner. An alternative way to group the functions into modules would be by customer segment (business or personal customers), indicated here as Modules D and E

Exhibit 3. Grouping the high-priority functions allows the project manager to formulate a plan that delivers business value sooner. An alternative way to group the functions into modules would be by customer segment (business or personal customers), indicated here as Modules D and E.

The project manager then discusses all three plans with the client. Alternative 1 is the plan created in the traditional approach. This is the base case that matches the client's one-shot position, and produces a monolithic deliverable. If this plan is acceptable, there is no need to go further; but such acceptance is rare.

However, thanks to the alternative modular plans, the project manager has room to negotiate a more acceptable plan. Alternative 2 delivers the functions in three modules. The first two are delivered before the base case deliverable, the third is delivered later. Likewise, Alternative 3 delivers the functionality in two modules, one before and one after the base case deliverable schedule.

Presented with these alternatives, the client may choose one or suggest changing the order of module delivery. In any event, there is a basis for readily tailoring the plan to meet the business needs, which makes it significantly easier to negotiate a plan acceptable to the client.

Pros and Cons. One obvious drawback of the modular 30-60-90-day approach is that the overall project may cost more and take longer due to the extra work involved in planning, integrating and regression testing as new modules come on-stream.

A major benefit to the client, however, and one which often outweighs the additional cost, is that the project delivers business benefits earlier. Admittedly, these are only partial business benefits; but if the modules are carefully chosen, then the ones with the biggest bang-for-the-buck can go on-stream first to yield significant benefits early.

The client can also see the results of the unfolding project in action. This allows the client to fine-tune subsequent modules to avoid the “I didn't get what I wanted” scenario. At best, it allows the client to obtain even better results than envisioned on paper.

Also, in the event the project is discontinued for any reason after one or two modules are implemented, then not all the cost and effort is lost. The business is able to obtain at least part of the benefit that was intended, even though the project was prematurely terminated.

A key benefit for the project manager is that the subdivision of the project into modules reduces the level of resources required concurrently, compared to the monolithic approach. For example, when the design team finishes designing Module A, the build team takes over, and the design team can begin on Module B. This cascading of project resources from one module to the next helps reduce the demand for project resources. In addition, this approach helps lower project risk by dealing with a series of smaller deliverables rather than a single large deliverable.

The client can see the results of the unfolding project in action, allowing the team to fine-tune subsequent modules to avoid the “I didn't get what I wanted” scenario. At best, it allows the client to obtain even better results than envisioned on paper.

The proposed approach also provides the ability to get client feedback on the modules as they are delivered and helps the project manager deliver modules targeted to the changing environment. This enables the project to track more closely to client needs in a dynamic setting and improves client satisfaction with delivered results.

By delivering in a modular fashion, the project manager avoids the megaproject risk of nondelivery. This also avoids the organizationally demoralizing effects of a project failing to deliver, with resultant cynical attitudes, wasted effort of staff and wasted career effort.

How is this approach different from phased rollout? While it is a type of phased approach to project delivery, it varies from other types of phased approaches in that it requires the forced chunking of a project into doable components delivering business value. Other types of phased approach typically deliver parts of a project as they become available over time, or progressively roll out the geographic implementation of a project over time.

CAN ALL TYPES OF PROJECTS fit into the 30-60-90-day mold? The proposed approach depends on being able to divide a project into doable chunks that can deliver business value. The 30-60-90-day name is meant to be a shorthand way of saying “… deliver in chunks, and do so reasonably quickly.” However, the term should not be taken literally; obviously, the timing of the module delivery must be tailored to the project. The “chunking” will vary from project to project and will require creativity of both the project manager and the client to sensibly subdivide the deliverables.

There may be instances where it does not make sense to divide a project into chunks; but in our experience, almost all medium- to large-scale projects can and should be structured to allow progressive delivery of meaningful components. ■

Leigh Hardy heads up the Project Management Office at Newcourt Credit Group, one of the largest international asset finance companies in Canada. Tom Chaudhuri, PMP, is a senior consultant with a diversified Canadian financial services institution. Both authors have worked extensively in the project management and consulting fields internationally.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

PM Network • July 1998

Advertisement

Advertisement

Related Content

Advertisement