CHAPTER 2
Project Management versus IT System Maintenance
applying the tools and techniques of project management to systems maintenance is not a straightforward process. Why not? The IT industry benefits greatly from project management best practices when managing projects. Can’t we apply these best practices to other endeavors in IT, such as maintenance? This chapter compares project management to IT system maintenance and answers these questions.
According to the PMBOK® Guide, a project is “a temporary endeavor undertaken to create a unique product, service, or result.” In IT terms, a project is established to deliver a new system, a major software revision, or a new hardware platform. Key project attributes are a unique deliverable and project start and project end dates. A project typically provides one major deliverable. Minor deliverables may also be included, but everyone focuses on the one major deliverable.
Contrast this with maintenance. Maintenance is not unique and has no clear end date. Just ask a manager running maintenance year after year. But the major difference is the deliverables. Maintenance is set up to deliver a service. No one major deliverable dominates everyone’s focus. The service consists of keeping things running the way they have been running and implementing enhancements to the system when requested.
Even though the PMBOK® Guide definition of a project refers to delivering a service, the project aspect of the service is to create the service initially. Once created, the service is not unique year after year.
• Maintenance doesn’t have a well-defined end date.
• Maintenance activities are not unique year after year.
• Maintenance delivers an ongoing service instead of a product or one-time service.
Therefore, maintenance is not a project. Before we discuss methods to take advantage of project management’s best practices for maintenance, let’s explore the differences between projects and maintenance in more detail.
Scope Documents
A project begins with a project charter. The project charter authorizes the project manager to send resources to accomplish the documented objectives. Other project documents, such as the scope statement and the detailed requirement document, clarify and provide more details.
When maintenance began, we had these documents from the project team, but we were not authorized by the charter to spend resources to maintain the system. Instead, maintenance developed a Service Level Agreement (SLA) to take the place of the project charter, scope statement, and detailed requirements document. The SLA identified the services that the IT maintenance team would provide. The SLA served as a contract between IT and the business customer.
Defining Work Tasks
A tool for defining what work a project needs to perform is the Work Breakdown Structure (WBS). According to the PMBOK® Guide, “The WBS is a deliverable-oriented hierarchical decomposition of work to be executed by the project team. . . . The planned work contained within the lowest-level WBS components, which are called work packages, can be scheduled, cost estimated, monitored, and controlled.” The WBS doesn’t work well for maintenance because there isn’t a finite list of work packages that need to be completed only once.
Instead, we modify the WBS to create a Service Breakdown Structure (SBS) that lists the types of services and activities to perform on a routine basis or when the need arises.
Cost Estimate
Traditional project bottom-up effort-estimating based on a WBS will not work well for maintenance. The problem with this approach lies in the assumptions you would need to make about the quantity of each service that will be requested throughout the year.
You can use the SBS activities as a starting point, but you would then have to estimate how much time would be spent on each activity. There may be no accurate way to do this. Other estimating methods are presented later in this book.
Team
Projects and maintenance differ markedly in how the selection of team members is viewed and approached. In both cases, the manager wants quality, reliable people. But what constitutes quality, reliable people? We will look at longevity, skills, and knowledge. We will also look at the number of team members.
Longevity
Due to the fixed-time nature of projects, team members are sought for their availability when needed in the project plan. In some cases, a team member may be involved only for a portion of the project. Team members roll onto the project after it already starts; they complete specific deliverables and then roll off.
Maintenance team members, on the other hand, should have long-term availability. The deliverables they are responsible for are ongoing. Members of maintenance teams can be viewed as constituting the capacity of the team to complete tasks that come up at unknown times.
Skills
Due to the specific-task nature of projects, team members are sought who already possess specific skill sets that are needed to complete specific work packages. There is limited time to train someone to perform these functions.
Since maintenance is a long-term endeavor that will change over time, team members are sought who now possess skills and who are capable of developing new skills in the future. Training existing team members, instead of obtaining additional people with required skills, can be a strategic tool for maintenance teams.
Knowledge
Knowledge of the customer and of the intricacies of the systems is critical for maintenance. Key to contributing value is how well we know our customer’s business and business processes. Team members in maintenance must have appropriate people skills to effectively represent the IT maintenance organization to the customer. They must have in-depth knowledge of the systems so that they can rapidly correct defects and make enhancements.
These knowledge qualities are also useful for projects, but to a lesser extent. Project team members can be specialists in a subject area who have few customer interactions.
A general assumption found in the business world is that all IT people are similarly skilled and can work on both projects and maintenance. This is true in many ways, but it should be recognized that some people with specific personalities and backgrounds thrive on projects but struggle in maintenance.
Numbers of Team Members
On a project, there is more concern about the total cost of labor than there is about the number of people who work on a project. For example, if a project needs skills X and Y for 10 hours each, it should not matter if one person possessing both X and Y skills works a total of 20 hours or if two people each work 10 hours, one with X skills, the other with Y skills. The total cost is the same. The underlying assumption is that these people work in a matrix organization and will be used elsewhere, as is the case in most companies.
For maintenance, the total number of team members is a major cost driver; there’s less chance to shift people onto other projects if there is not enough work for them to perform. Fewer team members are thus sought, but all team members are heavily leveraged and trained as backups for one another.
Work Tracking
On a project, you plan and track your work using the WBS within a project schedule. It is straightforward to track the work performed because it is simply a matter of checking off completed tasks and deliverables. As time goes on, the project manager may add extra tasks due to new understandings, but overall the project manager knows what remains to be completed in order to finish the project.
When maintenance starts, the categories of activities to be performed in an SBS are known, but neither the quantity of these services nor when the services must be completed is known. You will need a different approach than using a WBS or even an SBS for tracking work completed. This different approach is presented later in Chapter 6, “Service Breakdown Structure.”
Customer Care
In both projects and maintenance, customer care is essential. In projects, this takes the form of understanding customer requirements and then translating them into final deliverables. Along the way, the project manager needs to make sure the customer is comfortable with the project’s status.
In maintenance, there are many other dimensions to address. The customer needs methods for contacting the maintenance team at any time of day or night with production issues as well as change requests. Effective status reporting is more challenging due to the need to communicate a clear picture of what the maintenance team performs for the customer. Overall, the relationship will last a long time, so extra care and time should be given to it.
Metrics
Metrics for projects focus on the deliverables (scope), when the deliverables are completed (schedule), and the cost to produce the deliverables (cost). This is straightforward and easy to understand. Project management uses metrics such as earned value to determine if the project’s deliverables are on track related to cost and schedule. The customer wants the answer to the question, “As of today, is the project going to deliver what I need on schedule and on budget?”
Metrics for maintenance focus on the quality of the service as well as its timeliness and cost. For maintenance, the customer asks a different question: “As of today, has the maintenance team delivered the application availability in the SLA and satisfied the needs of our users while providing good value for the cost I am paying?”
Risk
Risk management must be applied to maintenance, just as it is applied to any project. The only difference is in taking a longer view on risks for maintenance. There can be more outside factors affecting the desired outcome of maintenance due to the time exposure of many years.
Conclusion
This chapter highlighted some of the differences between projects and maintenance. Due to these differences, project management techniques, which helped advance the IT industry, do not easily apply to maintenance.
This fact is what drove the need for this book: it’s necessary to modify project management’s best practices, tools, and techniques to meet the needs of maintenance and to achieve new advancements in the IT industry. Read on to see how it’s done.