Keep Maintenance Out Of Projects

Maintenance does not belong in projects. Combining the two violates the definition of a project, mixes deliverables with opposing triple constraints, and sets the stage for scope creep. Maintenance needs to be performed by a dedicated group that can quickly implement changes. Project teams should focus on completing enhancements that will provide additional value to the customer.

The Problem with Maintenance

First, maintenance fails to meet the definition of a project. Maintenance has a beginning; however, it never ends. Systems are evolutionary. Users discover bugs and business requirements change necessitating quick updates. It is a never-ending cycle that continues long after the product has been officially declared to be at the end of its life.

Second, maintenance work has different triple constraints. To illustrate, reflect on any bug or minor enhancement. The primary goal is to fix the issue—scope is paramount. No one wants half of a bug fixed or a quarter of a feature. If an accounting system is truncating the pennies on a transaction, the customer will not settle for a fix that will correct the problem most of the time. It needs to be completely fixed.

The next most important constraint is the delivery date. Serious bugs must be fixed immediately; less severe bugs may wait a little longer. Neither can wait the nine months it takes to complete a full project.

Last is the cost. Most often customers will not even paying for a bug fix. The cost does not matter, since without the fix money is being lost. These constraints are invariant and they never match with a project's constraints simply due to the project's timeline. There is no place in a project for product maintenance, remove it.

The Genesis of the Practice

In the past, the predominant method of maintaining systems was to have dedicated groups of people assigned to a product. Resources with in-depth knowledge would work on a single system. This practice had numerous issues. It was expensive, inefficient and precluded cross training on other systems. This practice is often referred to as a stovepiped organization. This has largely been abandoned for a matrix management style. In a matrix structure, work is accomplished by pulling resources into projects teams. However, this too has its problems. It is difficult to retain the collective knowledge of systems that is present in a dedicated scenario. The tribal knowledge of the system is lost. The assumption that systems can be documented well enough to allow any group of people to maintain it is incorrect.

In addition, there is no group to perform routine maintenance tasks—a project team must be assembled to do the work. The temptation is to take maintenance tasks and put them in the next upgrade project for the system. This results in mixing dissimilar scope and frustrating customers due to the slow turnaround. For this reason, customers push for more bugs to be fixed and minor enhancements to be included in the project. Scope is impossible to control since everyone is sensitive to the length of time between project releases.

The Solution

The pendulum has swung too far in the direction of doing work in projects. Small specialized teams must be maintained that are familiar with each system. Core competency must be preserved and resources trained in the tools required to maintain the system. This is an investment to ensure the system's continued viability. It is no different from changing oil, rotating tires, and tuning up an automobile.

There are three prominent solutions to this problem.

Re-establish the product maintenance group. Dedicate them to the product at a fixed level. Have this team meet on a regular basis to assess the system's issues and make recommendations on approaches to fix the problems.
Create small bug fix projects to correct problems and deploy fixes on a periodic basis. The response time is slower than with a dedicated group, but this removes issues with moving maintenance into a project with conflicting goals and waiting for the resources to create the project.
Outsource the maintenance. If all else fails, subcontract the maintenance to an outside firm. Due to version control issues, this is only effective if there are no other upgrades going on to the system. In addition, it should not be considered an option if the system being maintained is a core part of the business. Core knowledge should never be outsourced.

Next week I will discuss how to recover a project where a large portion of the scope is bugs and minor enhancements.

Delicious

[Side note: Sorry for missing the blog last week I have been busy with my daughter and granddaughter, Kennedy Elizabeth. The latter of whom will hopefully get out of the NICU by mid-week. Thanks to all of you that have sent best wishes.]

Tags: IT Failure, Project Management, Maintenance