The IT Project Management Life Cycle - A Brief Overview

---

The IT Project Management Life Cycle — A Brief Overview

All projects evolve through a natural life cycle, from inception and definition to design and construction to delivery and ongoing support. The key to successful project management is to balance the need for control against the degree of risk evidenced in the project's scope. Go for a simple management framework or checklist and rely on published sources to supplement your efforts and to fill in any process gaps when confronting unusual or extremely complex projects. ^[3] As a starting point, consider the model shown in Exhibit 2. This framework assists the IT team in building an appropriately detailed plan and oversight process to deliver a given project successfully. Remember to adapt this tool to meet the particular needs of your project and organization. See Exhibit 2.

Exhibit 2: A Project Management Framework — Part 1

Project Phase	Project Activities	Associated Deliverables	Responsible Parties
Commitment	Obtaining sponsorship, scoping, planning, budgeting, obtaining commitment, defining roles and responsibilities, kicking off the project	Commitment doc Project plan/budget Scorecard; metrics Change process	Project director Project manager Project manager Project manager
Analysis, Part 1	Detailed business requirements gathering; initial involvement of the QA and IT customer services teams	Project coordination Business requirements Functional requirements	Project director or project manager Bus. Analyst Bus. Analyst
Analysis, Part 2	Detailed technical and infrastructure requirements gathering; initial infrastructure team involvement	Project coordination Technical requirements Technical specification	Project director or project manager IT architect Other IT partner providers, especially infrastructure personnel
Design, Part 1	Solution definition and design	Detailed functional specification Detailed technical specification Initial QA scripting CS metrics	Project team Project team QA Customer services
Design, Part 2	System prototype (if appropriate)	Nonworking prototype Focus group(s) input	Project team and partner providers

This framework begins with a reiteration of the various phases of the project management life cycle, including commitment, analysis, design (from both business and technical perspectives), infrastructure readiness, development, certification, launch, release, and sunset. ^[4] For each phase I then provide a summary list of activities, deliverables or desired outcomes, and the parties responsible. Many components of this model will be familiar; others may require a more detailed explanation. For example, the commitment phase, which is often given short shrift in actual project execution, is dealt with in some detail in the next section of this chapter. This chapter also devotes considerable attention to ongoing delivery management, communication, measurement, and reporting. To begin, let us consider each phase of the framework in a little more detail. See Exhibit 3.

Exhibit 3: A Project Management Framework — Part 2

Project Phase	Project Activities	Associated Deliverables	Responsible Parties
Infrastructure Readiness	Finalize requirements for development, test and production environments; order hardware and software as needed	Development environment Test environment requirements Preliminary production system requirements Infrastructure SLA	Project team and partner providers Project team and QA Project team and partner providers Project team and customer services
Development	Develop solution, install application(s), build database(s), develop reporting, design process changes, build test plans, develop training, marketing, and launch strategies	Application/system(s) User/technical documentation Reporting package Training package Testing and delivery acceptance processes	Project team and partner providers Customer services Project team and QA
Certification	QA testing and release management	Scripts Testing Bug fixes Formal release strategy	QA QA Project team and partner providers QA
Launch	Regression testing, formal certification, initial piloting of solution	Pilot process Regression testing SLAs Go-live decision	Project team Project team and QA Customer services Customer
Release	Go live	System in production Customer signoff	Partner providers Customer
Sunset	Application retirement	Products withdrawn	Partner providers

All projects begin with some level of commitment-gathering whereby the stakeholders collectively define the scope of the effort, timeframes for delivery, resources to be allocated, and so forth. For these key players to commit to the undertaking, the commitment phase must include a preliminary roster of personnel, project plans, and budgets. Once consensus is reached on all of these key elements, the project may formally kick off and proceed to the design phase. See Exhibit 4. Depending upon the size of the project, its inherent risk, and the culture and business practices of your organization, the commitment phase may conclude with a formal, written agreement on how to proceed, or the project plan itself will constitute the document of understanding. Again, the details of this particular process phase will be dealt with in detail later in this chapter.

Exhibit 4: The Project Management Process — Part 1

With commitment in hand, the now-empowered project team may proceed with its work. The analysis phase encompasses three critical elements: identifying and documenting the project's business, functional, and technical requirements. Business requirements include a detailed consideration of how the delivered IT solution will address the business sponsor's needs. As such, this requirements document should be sufficiently detailed to capture systematically all of the features and functionality that the customer expects from the envisioned system, as well as business process changes enabled by or required for its implementation. The functional requirements document translates the needs of the business unit into more IT-specific content. For example, the business requirements document may describe how an inventory control system will operate as part of enterprise operations, whereas the functional specifications define the specific functionality of the IT systems required for the desired business outcome. Lastly, technical requirements provide direction to the IT team about related hardware and software performance. Here, the document might address the volumes of data to be moved around the network, storage and backup requirements, operating system and computer platform limitations, and so forth.

Taken together, the business, functional, and technical requirements documents establish the foundation for the direction of all subsequent project activity. Note that my process model calls for both the quality assurance (QA) and the IT customer services teams to get involved in the project during the analysis phase. QA must participate at this stage in the process to better appreciate how its team should approach testing and release management when the time comes and to ensure that the project plan allows sufficient time and resources for QA activities. Customer services should also have advanced involvement in the scoping of upcoming project deliverables to prepare for IT staff and end-user documentation and training and to ready the help desk for customer support issues associated with rollout of the project. ^[5] During the analysis phase, or for that matter any other project management phase, team members may discover something that causes them to rethink the scope of the project or their approach to delivery. When this occurs, they must call together the impacted stakeholders and reconfirm their mutual commitment in light of these revelations and changes.

If the project analysis phase creates the boundaries within which you must deliver your IT project, project design defines the detailed approach and the ultimate outcome. When the project involves the installation of new hardware or software, design efforts may involve mapping the out-of-the-box functionality of these products against the customer's requirements and then addressing the gaps between that desired state and what the products in question actually offer. In this example, design work may also entail defining how best to integrate the proposed IT product into the sponsoring business unit's work processes. As suggested by the framework, more complex projects, involving business process transformation and the integration of various information systems, might be best served by prototyping the solution before proceeding.

Prototypes simulate the ultimate IT experience without incurring the cost, lost time, and risks associated with a full-blown development effort. In the world of Web services deployment, prototyping is a wise approach, especially for first-timers. Similarly, when you are dealing with a customer who has difficulties in articulating and settling on a specific course of action, creating a prototype may be the only way to focus the discussion and win the approval to proceed. At the end of design, the team will have its construction documents. These must be reviewed and approved by project stakeholders before any more work begins. With agreement and closure, the project may now proceed concurrently on a number of different fronts. The team will initiate the development process; it will engage colleagues if there are any networking or other infrastructure considerations; and it will work in partnership with the QA and customer services teams to ensure that these teams are ready to enable project launch and subsequent delivery. See Exhibit 5.

Exhibit 5: The Project Management Process — Part 2

With the conclusion of the design phase, the project team will have firm technical requirements. This information must be shared immediately with those responsible for the IT infrastructure. I include this infrastructure phase to the project life cycle for the very reason that it is regularly neglected. Its primary purpose is to ensure that the IT infrastructure team has an early opportunity to confirm that it can accommodate, from both a server/storage and a network services perspective, any new systems or services that your project will add to the existing enterprise IT complex. Furthermore, this phase reminds the project team to order required hardware and software early as part of project execution. It is amazing how often project teams neglect to order such things as servers before project delivery. Do not assume that your enterprise IT environment can readily absorb your new project's requirements. Even when it can, the infrastructure team must prepare for these additions and will greatly appreciate the advance notice. Finally, the infrastructure phase checklist serves to remind the project team to reserve development, test, and production platform space as required before these resources are needed.

The development and certification phases of the project management life cycle are perhaps the best documented process components. ^[6] Obviously, your team's approach to development will depend on the nature of the project. Make no assumptions about the level of effort required to bring a particular IT solution to market. Unless you have lots of experience with very similar projects, invest heavily in analysis and design, including prototyping, before committing to a delivery date. Remember too that there is an iterative cycle in all development efforts. As your team proceeds, it will uncover problems with the source code or the hardware or the original business and functional specifications that may require the rethinking of your development approach and perhaps the resizing of the project. You cannot always foresee such obstacles, but once they are uncovered you must address their implications before proceeding.

Similarly, do not underestimate the need for, and hence the resource demands of, the testing process. Few project plans allot sufficient time and resources for this essential development life-cycle component. Most experts swear by the benchmark that it takes as much time to test and certify an application as it takes to build it. But what project plan in your memory has ever allowed for a QA commitment to that extent? Obviously, the team must balance its investment in testing against the potential risks. Tradeoffs will inevitably occur. Nevertheless, QA takes time, especially for IT applications that require extensive end-user testing, as do bug fixes and the regression testing that ensures those fixes actually solve the problem. My advice is to work with your QA team early (during the design phase) to script testing scenarios and factor the associated time and resource implications of their work into your plans.

Of the remaining aspects of the project life-cycle model, product/service release should not occur until your sponsor and working clients have reviewed and approved your project deliverables. During the course of the project, the effort's agreed-upon outcomes will change with circumstances. Be sure to reach consensus before the release of the team's work, or it may come back to haunt you later. In addition, make sure that both the IT organization and the customer are ready for delivery. Preparedness may involve operational and technical deliverables, such as ensuring that the project's production code is under version control and that system data is backed up on a regular basis, as well as support deliverables, such as the availability of technical and end-user documentation, well trained help desk and support personnel, and appropriate problem resolution and service request criteria in your call center problem management system. On the customer side of the house, pre-launch work may entail end-user training, business process (change) documentation, and production walk-throughs involving both the customer and IT system support and maintenance personnel. Be sure to publicize your launch plans well before the launch happens. Last but not least, for new or problematic projects, be sure to conduct a lessons learned session with your customers some time within the first two months after launch.

In terms of project personnel, the framework identifies the role of project director and project manager. The project director is the IT party responsible for project delivery and the overall coordination of internal and external IT resources. He or she works hand-in-hand with the customer to ensure that project deliverables are in keeping with the customer's requirements. The project director has final say on decisions within the project team. Preferably, this assignment will fall to the party who will own the IT application or service once it is in production, and therefore someone with a vested interest in the project's success. The IT project manager is staff to the project director. This support person develops and maintains project commitment documents and plans, facilitates and coordinates project activities, carries out business process analysis, prepares project status reports, manages project meetings, records and issues meeting minutes, and performs many other tasks as required to ensure successful project delivery. Many IT organizations merge these two roles, but it is a good idea to separate them and indeed, to establish a centralized project management function (i.e., the PMO) with its own the support staff (i.e., project managers and business analysts).

The framework employs partner provider as shorthand for any technology specialists — internal or external to the IT organization — who contribute to the project's delivery but who are not necessarily involved in day-to-day project operations. For example, network services personnel may serve as partner providers to a development team delivering a new Web site. Working clients are customers assigned to the project by the executive sponsor (i.e., the party funding the project). Working clients bring business process expertise to the process and also serve as operational surrogates for the executive sponsor. Although the participation of working clients is often essential to a project's success, avoid awarding even these customers project manager or project director status because they often lack the necessary technical knowledge and experience in managing IT personnel and vendors.

As the preceding comments suggest, clearly defined roles and responsibilities are critical to the success of any project. However, there is one remaining role: process guardian. Actually, this is not a formal project management role, but it is important all the same. In any IT organization faced with the day-to-day management of multiple projects, there must be a person or office dedicated to overall compliance with best practices. This function would include the design and maintenance of project management forms, reports, and tools. The tracking of project management resources and interproject dependencies (in terms of people, expertise, the time of product and service releases, and so forth) would also fall to this role. Similarly, someone must own the master scheduling and monthly operational reporting activities discussed later in this chapter. Lastly, some party should follow up with project teams before, during, and after their initiation to ensure that they are following the standards set by IT in dealing with customers, measuring performance, and delivering results.

Obviously, I am referring here to the PMO and its manager. No one person can take on the responsibility for all of these activities. Rather, the manager of the PMO will work with his or her team to establish a consensus around best practice. No doubt executive IT management will contribute to and bless these standards. Thereafter, it becomes the PMO's role to embed these practices into the ways that the IT organization conducts its business. Although in some organizational designs, the PMO may staff the project management and business analyst functions within project teams, this may not always be the case, even when IT has its own PMO. However, regardless of IT's staffing design, the PMO's most profound impact is in the area of process management, where the team works to influence behavior across the greater IT organization. Through such practices, the methods and frameworks advocated in this book can work their way into the culture of the IT team and, over time, make a difference in overall team performance.

Lastly, the project management framework identifies process phase deliverables. Some of these, such as SLAs, have been addressed else-where in the text. Others, like project plans and project budgets, are self-explanatory and therefore require no further elaboration. Those few remaining project artifacts that may be unfamiliar include the project commitment document, project scorecards, and monthly operations reports. These particular project management components require special handling because of their unique but highly useful qualities and because they get little or no notice in other authors' treatment of the process. As the reader will learn, these particular elements can add to the quality of the IT project management experience and its successful outcomes.

^[3]In his career, the author has created more than a few voluminous project engineering frameworks, hoping that his project delivery teams would use them when fashioning project plans and as checklists to ensure that nothing is missed during the development and testing processes. Unfortunately, these tools have died of their own weight. No one willingly refers to them, which is behind the more streamlined approach detailed in this text.

^[4]This framework also serves as the starting point and checklist for creating a more detailed project plan. For a more detailed electronic version of the framework, see The Hands-On Project Office, http://www.crcpress.com/e_products/downloads/download.asp?cat_no=AU1991, chpt5~2~project phases~model. For illustrative workflows of the project management process, see chpt5~3~project management process~work flows and chpt5~4~project management process~example with work flows.

^[5]As part of their preparation work, IT customer services and the IT unit's CREs should team up on the implications of the new project on existing service level agreements (SLAs). The framework differentiates between SLAs, which define the terms and conditions of service to actual IT organization customers, and operational service delivery agreements (OSDAs), which define the handoffs and the associated metrics among IT operating units. The purpose here is to separate customer commitments from the internal steps (and commitments!) that the IT organization must embrace to deliver on its commitments to the customer. For more details on the SLA process, see Chapter 4.

^[6]Recommended readings include: Bass, L.., Clements, P. and Kazman, R. Software Architecture in Practice. Reading, MA: Addison-Wesley, 1999; Freidlein, Ashley. Web Project Management. San Francisco: Morgan Kaufmann Publishers, 2001; Kesner, Richard M. Information Systems: A Strategic Approach to Planning and Implementation. Chicago: American Library Association, 1988; McConnell, Steve. Software Project Survival Guide; Richmond, WA: Microsoft Press, 1997; Murch, Richard. Project Management Best Practices for IT Professionals. Upper Saddle River, NJ: Prentice Hall, 2000; Philips, J. IT Project Management: On Track from Start to Finish. New York: McGraw Hill/Osborne Media, 2002; and Project Management Institute. A Guide to the Project Management Body of Knowledge, 2000 Edition. Newtown Square, PA, PMI, 2000.

---