Software Systems for Project Management

A vast amount of project management software is available today in a wide variety of capabilities, applicability, platform requirements, and prices. These software products significantly enhance the PM’s job of managing a project in almost all aspects, including selection, planning, scheduling, execution, control, risk, and communications. PMs should therefore be aware of the types of tools available and the features and applicability of those tools. In this chapter, types of software products and some specific products are identified and discussed.

Developing the Schedule and Cost Plan

The Project Management Institute (PMI) project management process groups include initiation, planning, execution, control, and closing. In practice, however, the initiation processes of a project are often not part of a project for budgeting and control issues, but rather are charged to management and administration (M&A) or operations and maintenance (O&M) general ledger accounts. In some organizations, these charges are later reversed back to a project after it is decided to move forward with that project. Thus, only the planning, execution, and control processes become part of the project for accounting purposes; sometimes detail planning is part of a project but not overall planning. Similarly, the closing process group may or may not be a formal part of the project, and sometimes those processes are performed by an independent organization. This chapter is concerned with detail project planning, particularly the schedule and cost plan.

The Software Engineering Discipline

Software engineering is vital for the proper planning of IT projects, although it is not a formal part of project management. The software engineering embedded in the acquired products will significantly affect long-term project success factors, even for IT projects that primarily involve software acquisition and integration instead of software development,. In this chapter I review software engineering and its relation to IT project management.

The Project Management Discipline

Professional organizations that have developed around the world to foster the project management discipline (Morris, 2001) have recognized that a distinct skill set is necessary to ensure successful project managers, and these organizations are devoted to assisting their members develop, improve, and keep these skills current (Boyatzis, 1982; Caupin, Knopfel, & Morris, 1998). In this chapter, I discuss the methods, techniques, and standards that these organizations have formalized.

Stakeholder Management

The identification and management of a project’s stakeholders is vital to the complete success of a project. Well-planned and properly-executed projects often can still fail due to a lack of or inappropriate relationships between the project manager and various stakeholders. This chapter discusses matters related to the human side of project management, including stakeholder relations, communications, and project team management.

Change and Closeout Management

Change is a fact of life for most projects, particularly IT projects. The biggest single cause of project overruns is changes in scope (Hallows, 1998). Change can be for the good or the bad, but change is to be expected, and change has to be managed. This chapter is concerned with that management process.

Critical Success Factors for IT Projects

A key factor leading to the continued failure in IT projects is the lack of identification and appreciation for all the major components of project success. Critical success factors are those things that must be done or handled properly for a project to be successful. A comprehensive model of critical success factors for IT projects permits the development of better management plans, processes, and metrics, particularly for risk, quality, and performance control. In this chapter, general critical IT success factors are identified and techniques for the management of those factors are introduced; later chapters then detail those techniques.

Performance Reporting and Earned Value Analysis

A PM must report on the project’s performance to the upper management of the performing organization and perhaps also to the benefiting organization. Upper management usually realizes the complexity and rapid dynamics of IT projects, however, it still needs accurate projections of project completion time and cost so that interdependent business activities, including product release/migration can be planned. Traditional methods of progress-performance reporting are often inaccurate and misleading. Earned value analysis (EVA) has proven to be an extremely effective tool for project time and cost management providing good estimates of actual project completion cost and date. EVA is also is a good early indicator of project problem areas, so that appropriate corrective action can be initiated. The effective use of earned value in IT projects, however, is still low, particularly outside of the U.S. government and its contractors. The application of EVA in IT projects is neither trivial nor straightforward because earned value requires careful planning and reporting in regard to work-packet specification, progress measurements, and actual cost determination. In addition, mechanisms to obtain all this information must be integrated into the organization’s project management, software engineering methodology, and financial reporting systems. This chapter discusses and illustrates effective ways to integrate EVA into an organization’s methodology and financial systems, and also presents specific techniques to deal with associated EVA complexities.

Managing Quality

Quality is defined by PMI as conformance to requirements, specifications, standards and fitness for use (PMI, 2000). Part of this definition is mostly quantitative, namely the requirements, specifications, and standards (assuming that these three things have been carefully and correctly itemized), but “fitness for use” is mostly qualitative. Because of this qualitative portion of the definition, the quality of the product which is the subject of the project may be an area for potential conflict between the performing organization and benefiting organization. In fact, as a project proceeds, quality is the most difficult area to keep on track, not because of its complexity, but because the project team may compromise it when a crunch arises (Hallows, 1998).

Project Execution and Control

In fairy tales and traditional romance movies, the story ended when the prince found his soul mate, married her, and rode off with her into the sunset. The ending caption said: “They lived happily ever after.” Well, we know that real life is not quite that simple; after the marriage comes the most difficult (and, one hopes, interesting) part. Similarly, a great project contract and plan is of little consequence without constant monitoring and control. Once the project is planned and underway, the project manager cannot simply ride away and assume that everything will go according to plan. To insure success, many project matters need to be monitored; if a matter deviates from the plan, then some form of control must be exerted to bring the situation back in line with the plan. In this chapter I discuss the many matters that need to be monitored for IT projects, how best to monitor each matter, and what type of control actions may be appropriate for each.