PMI Sites
CEO Corner
Register
Project Management Institute
Search

    Information-driven project management

    Article Strategy, Lessons Learned September 2001

    PM Network

    Denker, Stephen P. | McLaughlin, Hugh | Steward, Donald V. | Browning, Tyson R.

    How to cite this article:

    Denker, S. P., McLaughlin, H., Steward, D. V., & Browning, T. R. (2001). Information-driven project management. PM Network, 15(9), 50–53.
    images

    by Stephen Denker, Hugh McLaughlin, Donald Steward and Tyson Browning

    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?

    Meeting Fixed Delivery Requirements

    Using IDPM, a software company based in the United States reexamined its release process and significantly reduced cycle time. The company provided product updates and enhancements to service-contract customers on a six-month recurring basis. Each cycle, it shipped a CD-ROM containing bug fixes, version releases, upgrades and new documentation. These assembly, test, and production processes required more than 80 steps and an 18-month completion cycle. Using project schedule charts, teams met over several months trying to reduce the 18 months to six months. Their objective was to keep the CD-ROM creation-fulfillment process cycle synchronized with the customer commitment cycle. Because project members were too close to the existing process, they only saw task sequence—not the interdependency of information.

    Starting with the original task list, they threw out their old schedule's workflow predecessor-successor dependency logic and used IDPM to create an Information Dependency Map. They interviewed key players and asked what information was necessary to make a decision or start, update or finish work.

    By recognizing the information dependencies that drove workflow dependencies, they quickly saw several ways to reduce the 18-month process with no risk. They increased throughput with concurrent tasks and saved time by avoiding unnecessary, low-value tasks. In addition, the team reduced rework and iterations caused by missing tasks or misaligned tasks. This rearrangement also streamlined the review process. With further refinement and by managing creation-fulfillment sequences with a long-term planning process, the company achieved six-month cycle times.

    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.

    images

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

    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.

    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 September 2001

    Advertisement

    Advertisement

    Related Content

    Advertisement