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.

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.

[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 7078 times

Tagged under

Related items

Filling Execution Gaps: How Executives and Project Managers Turn Corporate Strategy into Successful Projects

What Filling Execution Gaps Covers

Filling Execution Gaps

by Todd C. Williams
ISBN: 978-1-5015-0640-6
De G Press (DeGruyter), September 2017

Project alignment, executive sponsorship, change management, governance, leadership, and common understanding. These six business issues are topics of daily discussions between executives, middle management, and project managers; they are the pivotal problems plaguing transformational leadership. Any one of these six, when improperly addressed, will hex a project's chances for success. And, they do—daily—destroying the ability companies to turn vision into value.

Check it out on Amazon or the Filling Execution Gaps website

Without the foundation of a common understanding of goals and core concepts, such as value being critical to success, communication stops and projects fail.

Without change management, users fail to adopt project deliverables, value is lost, and projects fail.

Without maintaining alignment between corporate goals and projects, projects miss their value targets and projects fail.

Without an engaged executive sponsor, scope increases, goals drift, chaos reigns, value is lost, and projects fail.

Without enough governance, critical connections are not made, steps are ignored, value is overlooked, and projects fail.

Too much governance slows progress, companies cannot respond to business pressures, value drowns in bureaucracy, and projects fail.

Without strong leadership defining the vision and value, goals are not set, essential relationships do not form, teams do not develop, essential decisions are not made, and projects fail.
Process Mapping

<p>Sorry, your browser cannot display frames!</p>

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 hesitate to 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 symptoms 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.

Select Workshop Options

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: