Sunday, 02 May 2010 00:00

Keep Maintenance Out of Projects

Rate this item
(0 votes)

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.

  1. 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.
  2. 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.
  3. 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.


[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.]

Read 3034 times

Related items

  • Process Mapping

    Process is at the core of any business. It makes work predictable, repeatable, and transferable. Without it we cannot scale our businesses. However, process can be a bane to making progress. Processes that work for a $10 million company have difficulties supporting a $30 million company. Trying to scale them to a $300 million company will not only fail but not address the issues that larger companies have that were never dreamt of in a smaller organization. Processes need to be discarded, revamped, and built—all of that without creating an overburdening bureaucracy.

    Anytime you need to go someplace, you first have to know where you are. Processes are never static and your company's current state is probably far from where you think it is. Hence, the first step is mapping out you company's current state followed by defining the future state. This is more than a logical map of the process; it must also include physical maps. Whether your process is solely to provide a service (say, website development) or physical (say, manufacturing) there are logistical issues that complicate the process flow. Without fully understanding those nuances, future state processes will not reach the desired efficiencies.

    For more information about process mapping fill out the form to the left and we will get in touch with you.

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • Project Inception - Designing Organizations For Success

    Buy it now!

    A failing project’s fate is destined long before assigning a project manager. Its doom is sealed from the time the customer envisions the idea. Traditionally, project inception is defined as when the customer comes to a solution provider (internal or external to their organization) asking for a product or service. In actuality inception is much earlier. It starts when someone says, “Wouldn’t be neat if I could...” From that point forward the customer’s exceptions are set, changed, and reset as the process of discovery refines the concept. The customer’s ideas change from what they want to what they need, while continually constrained and formed by the realities of an ever-changing business environment. Although people cite unrealistic expectations as major problem during inception, the constant change in expectations causes the real issue—misalignment. For project managers to make a significant difference in a project’s success, they must use a new paradig.

  • Organization Change Management for Project Teams Workshop
    Want to buy it now?

    Ask for more info below, or if you are convinced, just add it to your cart.

    Projects are never a success when they are delivered—their product must be adopted to declare success. Whether you are delivering a process for HR, creating new model of cell phone for your customers, or implementing a new ERP system for your company, if they do not see value in the output of your project, it is a failure. Most project teams, however, are focused on maintaining scope, schedule, and budget, they are far removed from the end-user, and they have little concept on how to persuade someone to use what they are developing. The fact of the matter is, though, that if they are the first people involved in the making a tangible product that their customers can use, adapt, and enhance to create value.

    Organization Change Management for Project Teams helps your project manager, their teams, and their stakeholders:

  • Balanced Scorecard for Project Teams Workshop

    Too often, project managers and their stakeholders lack the visibility into how their project's fit into the business' grand vision. Think how wonderfully your business would run if everyone from the C-suite to the feet on the street understood how to maintain focus executing business strategies.

    Want to buy it now?

    Ask for more info below, or if you are convinced, just add it to your cart.

    Balanced Scorecard for Project Managers helps your project managers and their stakeholders:

    1. Understand what is valuable for your organization.
    2. Reduce miscommunication.
    3. Focus their energies and your resources.

    Organizations the world over use balanced scorecard to define their strategic goals. However, balanced scorecard only works if its information is disseminated throughout the organization. This workshop helps PMO managers, executive sponsors, project managers, and their project teams understand why and how a strategy is defined, the use of activity and strategy maps, and how they apply to the organization's projects.

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References