Web application maintenance projects
an emerging frontier for project managers
Effective and consistent project management is required to tolerate the growing rate of diverse changes in web technology. Management Service Providers (MSPs) rely heavily on project management to run cost-effective projects that reap long-term business relationships. MSPs, specifically in the area of web application maintenance, are gaining acceptance among Information Technology (IT) departments and other clients who develop and manage their own software technology.
An MSP is a company that customers outsource some or all of their IT management on a subscription basis (Gillooly 3). The appeal of an MSP model is that it eliminates the need for companies and individuals to buy, maintain or upgrade IT, and network infrastructure management systems. Outsourcing to an MSP reduces major capital expenses, the need to hire highly technical experts, and a considerable investment in time. MSPs also provide an alternative to traditional management techniques, transferring performance monitoring and measurement and full management responsibility to an external service provider. The Meta Group believes that the MSP market will grow by $10 billion by 2004 (Internet Infrastructure p. 10).
Managing a web application maintenance project requires the project manager to be prepared to step into various roles and carry out responsibilities that are not easily measured in relation to project success. Some of the roles that application maintenance project managers must execute include sales representatives, business analysts, legal council, and information analysts. The responsibilities associated to these roles include writing contracts, securing the transfer of intellectual capital from web developers, identifying and implementing critical processes, and providing reports to the client and internal executives.
The success of an application maintenance project is determined by the manner in which the roles and responsibilities described above are juggled, in conjunction with managing the project requirements process. Juggling various roles and responsibilities complicates simple project questions such as “Who has signature authority over the project?”“Who must be notified of project status?”“Who can make a decision?” The project manager must maintain a clear understanding of who has authority, responsibility, and accountability to help put the various roles and responsibilities into perspective. On the other hand, the project requirements process “… includes all the work required and only the work required to complete the project successfully,” according to A Guide to the Project Management Body of Knowledge (PMBOK® Guide p. 47).
This paper demonstrates the differences between maintenance projects and traditional system development projects, identifies project elements that influence the success of application maintenance projects, recognizes the direct effects of the identified project elements on the project requirements process, and points out project management techniques that can be applied to limit the negative effects of project elements on managing the requirements process.
How are Maintenance Projects Different From Traditional Systems Development Projects?
Application Maintenance projects differ from traditional systems development projects in three ways: life cycles, project issues, and the estimation process to determine the cost of the project. First, the maintenance project life cycle differs from that of a systems development project. An application maintenance project life cycle typically has the following four phases.
Needs Assessment Phase—This phase provides the project manager with a high-level view of the application or portfolio of applications. This phase is similar to a typical IT requirements gathering phase.
Engagement Planning Phase—The project manager and project team drill down to exacting levels of discovery and detail of the application. During this four to six week phase, the engineers analyze the physical code of the application. A maintenance plan is created and delivered to the client during this phase.
Transition Phase—The goal of the transition phase is to ensure the project team is well positioned to provide ongoing services to the client. During the transition phase the MSP test the software configuration processes, change management processes, and the identified communication and escalation procedures. This phase lasts three to six weeks depending on the size of the application.
Ongoing Support Phase—The MSP assumes responsibility for the performance, reliability, functionality, and security of the application. The length of this phase is dependent on the contract between the MSP and the client.
In comparison, traditional systems development projects follow a project life cycle with a sequential and iterative set of phases. These phases include define, analyze, design, produce, optimize, and implement. Exhibit 1 compares the life-cycle differences between a traditional systems development project and application maintenance project. Notice that the application maintenance life cycle levels off at ongoing support. Often the project manager inherits the roles and responsibilities of a customer service manager. This is different from a traditional systems development project in that a project manager phases out of the project entirely at the end of the life cycle.
The second difference between application maintenance projects and traditional system development projects is the types of project issues that arise. Project issues associated to application maintenance include the transfer of intellectual capital, communications with the developer, communications with the user, formal application turnover processes, training, speed of transition, and the cost of transition. Traditional IT project issues focus more on requirements gathering, user-acceptance testing, demonstration software that becomes an end itself rather than an eventual application, and implementation and roll out procedures.
Finally, the third difference between application maintenance projects and traditional systems development projects is the estimation process to determine the cost of a project. For an application maintenance project, the costs are purely a function of the scope of the maintenance services. That is, full maintenance is more expensive than limited software configuration management. Whereas the costs associated to traditional system development projects are valued by striking a balance between the cost of developing an operating system, and the benefits derived from that system (Whitten 1994).
Controlling Factors That Influence Application Maintenance Projects
There are many examples of project elements that are considered controlling factors. For the purpose of this paper, a controlling factor is defined as, a restraining or limiting measure that actively contributes to an accomplishment, a result, or a process. Examples of project elements that are controlling factors and affect maintenance project include: preexisting contracts between ISP‘s and clients, and identifying the maintenance support requirement of an application and compromising the support level to fit the client's budget.
A controlling factor, such as a preexisting contract between an ISP and a client, will influence the development of the application maintenance plan. An application maintenance plan should be prepared during phase two, Engagement Planning Software Development, and should specify how users will request modifications or report problems (Pigoski 1996). The existing contract between the ISP and the client, may limit the service offering that an MSP can offer to a client in areas such as application monitoring and setting level objectives. This type of controlling factor will affect the scope of the project and possibly the success of the relationship with the MSP.
Another example of a controlling factor is the current level of support that the application environment requires and how the price of that support level fits into the client's budget. Typically, the scope of a web application maintenance project falls into one of four support levels: full maintenance, corrective maintenance, limited corrective maintenance, and limited software configuration management. Explaining the limitations of each of these support levels to the client and which level the client can have access to, based on their budget, is crucial. If the support limitations are not explained to the client, the effect may be detrimental to the project and the business relationship.
For example, a client that signed a contract for a project that offers corrective maintenance will need to understand that only corrective actions will be performed throughout the course of the project. Requests for application enhancements, call center support, or application monitoring are services that are out of the scope of the project. One technique used to define the project parameters is to present an estimate of the application's life-cycle costs to the client. The cost model should reflect the costs for the functions defined in the level of support in which the client is interested. Other factors to be included in the model are expenses for travel, training the application maintenance staff, hardware costs, and software licenses.
Are Controlling Factors Important to the Project Requirements Process?
The impact of a controlling factor such as the preexisting contract between the ISP and the client has the potential to directly affect the requirements management process of a project. The lifespan of the first three phases of an application maintenance project is short, approximately 8–10 weeks. For this reason, it is important to understand the impact of all project elements that are considered controlling factors prior to the Engagement Planning phase.
In the example presented in Exhibit 2 concerning the preexisting contract with the ISP, the direct effect is that the project manager will need to analyze the approach of the maintenance plan. This reevaluation will concentrate on clearly defining the roles and responsibilities of all project stakeholders involved in the maintenance of the application. Exhibit 3 illustrates the direct effect relationship between a preexisting ISP contract and the need to reevaluate the requirements life cycle.
The preexisting contract with an ISP, or in other words, the controlling factor, has a direct effect on how the project manager controls the requirements process. The project manager is forced to take on the role of a sales executive and legal council to reevaluate the maintenance plan. For example, the client may identify that the MSP will be the primary point of contact for the ISP. This requirement may be considered scope creep if the project assumption was made that the client would act as the primary point of contact for the ISP. Essentially this new requirement may alter the cost and statement of work that is provided to the client.
David Frame, the author of Managing Projects in Organizations, defines the following requirements life cycle for project managers.
• Phase one—needs emergence, which is a change that can be driven either by internal or external events.
• Phase two—needs recognition. This phase addresses the procedures needed for the systematic identification, anticipation, and gathering of needs.
• Phase three—needs articulation. Needs articulation is an appreciation of deeper needs as well as surface needs.
• Phase four—needs to satisfy the opportunity. The functional description of requirements needs to satisfy the opportunity.
Exhibit 4 presents a sample of controlling factors and the corresponding roles and responsibilities the application maintenance project manager assumes as a result of these controlling factors. The requirements life-cycle phase, as defined by David Frame, impacted by the controlling factors are also documented.
Project Management Techniques that Limit the Effects of Controlling Factors
Project managers should consider the importance of the following five tips when trying to limit the negative impact of controlling factors.
• Be aware of the common problems associated with defining needs. These problems include:
1. Inherent fuzzy needs—which are needs that are not fully understood by end-users.
2. Identifying solutions prematurely—the expression of needs often have a specific imbedded solution.
3. Addressing the needs of wrong end-users—project managers bring biases into the needs determination process.
• Understand the present application in its total context, including political dimensions.
• Identify multiple customers and prioritize their needs.
• Organize a needs-defining task force, which includes customers.
• Educate the customers regarding customer responsibility for defining needs, technical aspects of needs definition, and rudiments of project management.
• Carry out research to understand the need better. (Examine business records, report formats, and the specific history of relevant operations.)
• Formulate an initial statement of need.
• Encourage the end-user validate the statement of need and revise as necessary.
In addition, project managers should be conscious of refining effective requirements gathering traits. These traits include the ability to deal with and understand customers, exercise good political skills, demonstrate technical competence in terms of the ability to match needs with solutions, maintain an open-mind and possess a good imagination, and the ability to tolerate ambiguity in conjunction with mixed and conflicting signals (Frame 1994).
Project managers who are responsible for the implementation of an application maintenance project are challenged with juggling various roles and responsibilities due to the direct effect of controlling factors. Understanding and managing the authority, responsibility, and accountability of the various project roles is complicated by the need to manage the project requirements process. A project manager who is adaptable to carry out many roles is able to better control the scope of an application maintenance project. The general refinement of rudimentary requirements gathering techniques, in conjunction with an awareness of controlling factors and their direct effect on managing the requirements process, aide the success of an application maintenance project.
Internet Infrastructure Services. 2001. New York: Raymond, James & Associates, Inc.
Kerzner, Harold. 1998. Project Management A Systems Approach to Planning, Scheduling, and Controlling. Bera, Ohio: John Wiley & Sons.
Frame, J. Davidson. 1987. Managing Projects in Organizations. Jossey-Bass.
Frame, J Davidson. 1994. The New Project Management. Jossey-Bass.
Gillooly, Caryn. 2000. MSPs: A Market Segmentation. Framingham, MA: Hurwitz Group.
Pigoksi, Thomas. 1996. Practical Software Maintenance. New York: Wiley Computing Publishing.
Project Management Institute. 2000. A Guide to the Project Management Body of Knowledge. Newtown Square, PA: Project Management Institute.
Whitten, Jeffrey. 1994. System Analysis & Design Methods. Burr Ridge, IL: Irwin.
Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville, Tenn., USA
Hurricane Katrina decimated thousands of buildings in New Orleans, Louisiana, USA, in 2005, including a U.S. Department of Veterans Affairs (VA) medical facility that served approximately 40,000…
Federal Project and Program Management Community of Practice (FedPM CoP) – How Sharing Best Practices Can Lead to Success
Recognizing the value of a community focused on project practice capability and how such a community could help improve the performance of departments across the U.S. federal government, the leaders…
Developing a Project Management Office in the Department of Energy, Energy Information Administration
This case example, a supplement to the report, PMIAA: Strengthening the Government Delivery Foundation, highlights project and program management capability building within The U.S. Energy…
Commissioned and supported with research from PMI, MIT’s Consortium for Engineering Program Management, and others, this report distills how many government agencies have been leading (and continue…