4.2 Summary

4.2 Summary

Processes not only provide the foundation on which the PO operates, they represent the collective knowledge and insights developed through the work of the organization. The strength of an organization lies not only in the technical knowledge and resources it possesses, but in its ability to make these work together and improve them over time.


  1. NASA System Engineering Handbook, SP-610S, 1996.

  2. Little Yellow Book of Software Management Questions, Software Program Managers Network, 1997.

  3. Taxonomy-Based Risk Identification, CMU/SEI-93-TR-6, Software Engineering Institute.

  4. Sterman, J., Business Dynamics: Systems Thinking and Modeling for a Complex World, Boston: Irwin/McGraw-Hill, 2000.

  5. Saaty, T., Fundamentals of Decision Making and Priority Theory with the Analytic Hierarchy Process, Pittsburgh: RWS Publications, 1994.

  6. Grey, S., Practical Risk Assessment for Project Management, Chichester, NY: Wiley, 1995.

  7. Kitchenham, B., and S. Linkman, "Estimates, Uncertainty, and Risk,", IEEE Software, May 1997.

  8. Garvey, P. R., Probability Methods for Cost Uncertainty Analysis: A Systems Engineering Perspective, New York: M. Dekker, 2000.

  9. Fine, C. H., and D. E. Whitney, "Is the Make-Buy Decision Process a Core Competence?" Cambridge, MA: MIT Center for Technology, Policy, and Industrial Development, Feb. 1996.

  10. Goethert, W., E. Bailey, and M. Busby, Software Effort and Schedule Measurement: A Framework for Counting Staff-hours and Reporting Schedule Information, Software Engineering Institute, CMU/SEI-92-TR-21, 1992.

  11. FDIS 15939: Software Engineering—Software Measurement Process, ISO/IEC JTC1/SC7 N2560, 2002-01-10.

  12. Guide to the Project Management Body of Knowledge, A PMBOK® Guide, Project Management Institute, 2000.

  13. Ericsson Project Management Institute, 2002.

Chapter 5: Tools


A the number of projects managed by an organization grows larger and the projects become more complicated, the existence of an adequate information system to support operations is essential.

Tools for project management have long focused on the scheduling of tasks, but the PO needs more information than that yielded by task scheduling. An adequate information system for a PO must provide, in addition to the traditional scheduling capabilities, explicit functionality to monitor the status of resources across projects, and what-if capabilities to support portfolio analysis.

Although the functionality they offer might seem similar, not all tools are the same, nor can the PO delegate responsibility to the IT department for deciding which ones should be used. Information systems can provide organizations with a competitive edge, not only because they enable them to do things that could not otherwise be done, but because the tools themselves become knowledge containers. Through customization and the encoding of business practices, tools make the experience and insight of your best contributors operational throughout the organization.

This chapter begins with the presentation of an idealized information system for the project-based organization and concludes with a survey, necessarily incomplete, of commercial tools that approximate the functionality described here.

5.1 Information needs

A PO information system (see Figure 5.1) must satisfy the needs of three groups of users: the PO and senior manager, concerned with projects and competencies, the project managers, who deal with tasks and generic resources, and the line managers, whose concern is with tasks and named resources. But whatever the user group, the same basic questions must be answered [1]:

  • What needs to be done?

  • How much will it cost?

  • When can it be done?

  • What resources will be utilized?

  • What are the consequences of doing A instead of B?

  • Where are we in relation to where we planned to be at this point?

  • Is work progressing at an acceptable rate?

  • Where are we going to be a month from now?

click to expand
Figure 5.1: Different stakeholders have different objectives but all can be reduced to four basic information needs: What? When? Who? Where are we?. (After: [2].)

These simple questions define the basic functionality that any PO information system must provide.

By information system we do not imply a single application package provided by a single vendor or a homegrown monolithic application. The PO information system could very well be made up of a mixture of commercial tools and some internal development. What distinguishes a bunch of tools from a system is that in the latter all the tools have the same understanding of what the data represents, they share it, and users are not forced to enter it more than once. If users need to copy and paste between dissimilar applications, or if there exist copies of the same data in slightly different formats to satisfy the needs of different applications, the organization does not have a system.