Information-driven project management

Often, project managers struggle with the first steps of project planning—gaining good process logic. While most planning and scheduling tools depict sequence of events, they do not account explicitly for information flow. Much of the necessary information arrives as outputs from other tasks. It is information, in other words, that enables job performance.

Information-Driven Project Management (IDPM) allows managers to visualize, organize and exploit information relationships between tasks. IDPM enlarges a workflow view (managing tasks) with a dependency view (managing information).

Project planning begins with defining information flow, which mandates task dependencies, and then specifying sequences. By emphasizing information needs, IDPM leads to better task definitions and schedules, reducing project risk.

As project managers plan projects, they frequently “hardwire” a particular task sequence. Processes detailed according to how they have been done historically or how they would be done ideally ignore what is actually correct or possible. While task performance and sequence may vary, information dependencies remain stable or constant and a task must consistently produce a specific type of information.

Getting Started

IDPM calls for integrating collective expertise. Project managers must look at information dependencies as the basis for workflow dependencies. What information tasks owe other tasks is critical because it establishes communications, commitments and accountabilities.

Although task managers know what they need, they may not be entirely sure who needs their work or the information they generate. Project managers build an initial project plan from interviews on person-specific and team-specific tasks. This uncovers the direct information dependency pairings between team members. Knowing what questions to ask and how to use answers is critical.

For each task, ask:

■ What essential information do we require to start, update or complete this work?

■ To whom are requests made and what information is required of them?

Key Customer Requirements

By recognizing and managing assumptions, projects can be directed from where they are rather than from where they were expected to be. A distributor to retail hardware stores decided to replace its mainframe warehouse management system with a lower-cost Unix system. The company had some unique requirements but relied on the expertise of the computer vendor, the software provider and the value-added reseller. They all claimed that adding customized features to the commercial software package would meet the distributor's key performance requirement, which was the capability to batch-process up to 10,000 orders within six hours every night, including creating pick tickets and updating the warehouse's inventory database.

The two-year warehouse project used a waterfall model as its plan for software development (Exhibit 1). This process works well for projects where there are stable requirements and well-understood technologies. The next project phase is not started until all questions in that phase are resolved.

Problems first surfaced 23 months into the project when the initial test of the warehouse database batch update took longer than 24 hours. The project was cancelled, but not before valiant rescue efforts. These efforts included the hardware vendor providing (at its expense) a computer with twice the capacity and speed previously available, and senior developers reworking database tables, indexes and code for an extra six months.

The moral? Four major parties in the project all accepted too large a risk by allowing the initial system test to be delayed until everything else had been completed.

A better understanding of the assumptions that had been made and when and how they should be verified was missing. Rework in one task caused a chain reaction of changes that disrupted “finished” and “in-progress” tasks.

For less than an 8-percent increase in the original budget and no stretch-out of the initial completion date, it would have been possible to test base-system capability to handle the nightly batch-processing requirement at the end of the third month. The Information Dependency Map (Exhibit 2) shows this revised sequence, and the complex information dependencies.

In Exhibit 2, the first block (rows and columns representing phases A through E) defines the first development cycle. The block F through J represents full-system testing and any necessary design iterations; that is, if the critical, nightly batch-update processing requirement is met initially with ease, then there is no need to iterate phases F through J. Information feedback from phase J to phase F is high when the total night batch-update time standard is not met. Initially, phase F accepts the results of phase E.However, on subsequent iterations to reduce total batch-update process time, phase F would require information from phase J to enable the project team to choose where to focus.

Using IDPM, it's now possible to determine whether the key system batch-update completion requirement is achievable and, if not, to abort the project in as early as six months.

Exhibit 1. The initial project plan schedules project tasks and progress phase reviews.

Exhibit 2. An H or M in any cell of this Information Dependency Map means there is an input/output information dependency between phases.

In this way, row-by-row, an Information Dependency Map is built. In the map, high and moderate input/output information dependencies between phases are made explicit. If the mark in a cell is below the diagonal, information is fed forward (going vertically down along the column) to the row of the phase that needs it. If the mark is above the diagonal, then information could be fed backward. A later phase may produce information required for earlier tasks.

If this actual value (accurate information generated by a task) is different from the estimates used to continue work (assumptions used to proceed to that point), any previous task dependent on that information must be redone. Once the Information Dependency Map is finished, columns can be used to answer the harder question: What information do others need to do their jobs?

“What do I owe?” and “What do I need?” sound deceptively simple, but the answers take a lot of thought, experimentation and hard work. Because answers are not “forever,” these questions must be asked every time there is a major change in a project.

Stephen Denker, a business process architect, has consulted for more than 30 years for organizations in product design and management. He also is a lecturer in the Operations Management Group at the Boston University School of Management, Boston, Mass., USA.

Hugh McLaughlin is a systems consultant with Keyport Life Insurance Co., Boston, Mass., USA.

Donald Steward is an emeritus professor at California State University and a principal of Problematics, Napa, Calif., USA. He has worked in both industry and universities. His original work on information dependency dates back to the 1960s.

Tyson Browning is staff specialist in the Enterprise Productivity Strategy Group at Lockheed Martin Aeronautics Co., Fort Worth, Texas, USA, where he helps determine continuous improvement strategies and provides consulting on product and process development.