Beyond successful projects--leadership in transitioning IT projects to maintain continued business value



Our projects are chartered to deliver new business value. As project managers, we are skilled at taking the steps to deliver projects successfully to meet scope, schedule, and cost through our mastery of the PMBOK® Guide (PMI, 2004). But to increase our value to the organizations we serve, we must demonstrate exceptional leadership to, not only deliver the projects, but also transition the projects effectively into ongoing maintenance. This is crucial for Information Technology Projects but applies to other type of projects as well. Items covered in this paper work for transitioning an IT project into maintenance as well as transitioning in-house functions to an outsourced service provider.

This is an advanced project management topic because we explore the leadership role that project managers must take to ensure ongoing business value from the projects we deliver. We administer our teams efficiently and manage our projects effectively. We must also show leadership in our actions and holding others accountable for their actions to ensure continued business value after our projects deliver. Who better to fill companies’ leadership roles than project managers?

We will explore the reasons for expanding our focus of leadership and present the Leadership Triangle, defining the role differences between administration, management, and leadership. Then, we will take our leadership skills and offer five practical tasks to include in your project plans to ensure a successful transition into maintenance. The transition becomes a mini project within a main project with clear deliverables and exit criteria. The five practical tasks are:

  • Ensure Receiver of Project is Ready and Capable
  • Develop Well Defined Transition Exit Criteria
  • Develop Method for Knowledge Transfer
  • Define the Right Service Levels
  • Define Controls

Reasons For Leadership Beyond Scope, Schedule, and Cost

Our personal performance as project managers is paramount to our success. We must, consistently deliver project management fundamentals, none the least managing scope, schedule, and cost. But once you have the fundamentals down and are able to deliver projects at consistent quality, then what? Can you stop at this level? Yes, if that is where you want to remain in your scope of influence.

What follows goes beyond your project’s scope. Arguably, you should not venture past this point because it can be construed as “scope creep”, “going beyond your charter”. But what if you not only wear project manager hat, but also wear a company hat, a “big picture” hat? Then the following makes perfect sense and you can bring the concepts back into your project.

To increase our value to the organizations we serve, we must challenge ourselves to be leaders that not only deliver the project, but also help ensure that the project delivers the expected value, (return on investment) which drove the creation of the project in the first place. To do this we must transition the project effectively into the hands of the people who will maintain it for years to come.

This takes leadership to see the bigger picture and perform in our project manager role to the greatest benefit of our stakeholder base. Typically, when our projects end, a company is just beginning to spend the total amount on an IT system. Maintenance represents a significant cost in the life cycle of a system. We can’t just “throw it over the fence” and expect that it is the other team’s responsibility alone to be successful. This is true in a company where employees staff the maintenance team, but even more so when an outsourced service provider will perform maintenance.

As Stephen R. Covey wrote in the Seven Habit’s of Highly Effective People (Covey, 1989), Habit Number 2 is, “Begin with the end in mind”. This is the basis for successful planning. But don’t just stop at the end of the project, look at the end of the full life cycle of the IT system. As leaders, we need to go the extra mile.

Your leadership thinking don’t only benefit your employer, it can place your career on the fast track. Companies search for business leaders that ensure continued business value. Who better to fill these leadership roles than skilled project managers? Demonstrated success in delivering projects combined with leadership in seeing that project benefits are realized year after year are a winning combination.

Leadership in Project Context

Our workday actions and thinking can be classified into difference categorize. For purposes of our project manager role, let’s focus on three levels, Administration, Management, and Leadership, which are represented in Exhibit 1, the Leadership Triangle (Malinowski, 2007). The terms are defined below. Please don’t take exception to the terms if you define them differently. The concepts are more important than the terms used.

Leadership Triangle

Exhibit 1 Leadership Triangle

  • Administration makes sure the team is working
  • Management makes sure the team delivers it’s promises efficiently and effectively
  • Leadership makes sure the promises are for true business value

Let’s start in the middle with Management Level; this is where project management skill normally operates. They are ensuring that the team is producing the desired project quality deliverables with a minimum effort. Project managers all operate part of their time in the Administration Level. There are always administrative tasks that must be completed, but no successful project manager can only operate at this level.

The Leadership Level is a mindset that doesn’t necessarily take additional time, but involves focusing on true business value, and delivering the value years after the project is complete. We use the term leadership to represent the focus beyond just our projects.

  • Leadership is measured in the ability to make decisions, not being indecisive.
  • Leadership commitment is measured in funding it’s commits to initiatives and process improvements.
  • Leadership is making sure all the pieces work, not just your own.

At any given time, a project manager may be operation at any one of these levels. There is nothing wrong with this. Administrative work should not be considered beneath you. You must have a solid foundation of administration, then you can build management on top with true leadership skills being the highest level. That must be done to start managing the effectiveness to meet business needs and delivering business value.

Five Practical Tasks

Thus far we have been talking on a theoretical level. Now it is time to get real! The following five tasks are practical ways of applying leadership in creating business value and increasing the likelihood that the expected value of our projects will be realized.

However, these tasks are only a beginning and don’t substitute for leadership thinking which will drive even greater creative tasks. Leadership can’t be condensed down to a finite number of tasks. This is good news because it means each of us can add our unique significance to our roles.

Think of this collection of five tasks as a mini-project, within your normal project, to transition to the receiver of your project (operations, maintenance, and/or business). We will refer to the receiver as the maintenance team in this paper.

Task #1 Capable

Make sure the maintenance team that will receive the project deliverables is ready and capable to take on all ongoing responsibilities. A leader would not assume. Any gaps on the maintenance team’s part could result in initially missing the expected business value.

The project manager does not have to resolve all gaps, and most likely the project manager shouldn’t. But the gaps and potential solutions should be raised to the appropriate person so they can be resolved, weather it is the IT maintenance team or the business owner.

To address this in your project plan, include tasks where you identify what the maintenance team should know and checkpoints where you have a conversation with the maintenance manager to identify any gaps.

Task #2 Exit Criteria and Transition Plan

Develop well-defined transition Exit Criteria. Your project’s acceptance and closeout tasks are already documented, signifying the completion of the project. But to address the transition to the receiving team, this additional criteria or tasks need to be documented and (to our benefit) many of these tasks may have to be preformed by the maintenance team. These tasks should be approved once they are identified in the plan and again once they are completed.

The exit criteria signify that the final turnover is ready. It is reasonable to expect that the project team would reach a certain level of quality in production before they disband. The exit criteria specify the condition that once met; the maintenance team will take over responsibility for the system. The criteria can include:

  • Specified period of production time reached without incident
  • Specified maximum number of issues open at turnover
  • Specified maximum number of critical defects open at turnover

The exit criteria fit into the project plan. Exhibit 2 (Malinowski, 2007) shows the three phases to transition a system being implemented by a project team to be maintained by a maintenance team. The columns of the plan show the separate tasks of the two parties. The rows map into the project team’s project phases.


Exhibit 2 - Transition

Phase One encompasses all the activities up to the first production deployment. Phase Two begins once the first deployment takes place and includes any additional production deployments and initial system support that the project team is accountable to perform. Phase Three is the wrap-up of transfer activities and primarily focuses on the maintenance team signing off that the transfer is complete and all maintenance activities will be owned by them going forward. Phase Three can be thought of as a milestone rather than consisting of multiple tasks. The majority of tasks should be complete in Phase Two. The task listed as bullets in Exhibit 2 should be included in your project plan.

Task #3 Service Levels Metrics

There are three kinds of people in the world, those that “Know what happened”, those that “Think they know what happened ”, and those that say, “What happened?” “Think they know what happened” people are less effective as leaders than the “Know what happened” people. Service Level Metrics are what enables that second group. We won’t talk about the “What happened?” people. (Malinowski, 2007)

Define the Right Service Levels. Everyone “just knows” what success is until they start defining the details; then it becomes an illusive subject. Documented Service Level Metrics are needed to set the expectation of what is required to deliver business value. With outsourcing contracts, the Service Level Metrics need to be set correctly the first time, otherwise it will take a negotiated contract amendment to fix.

You, the project manager of new development spent a lot of time in designing, creating, and working out problems with the new system. You have spent a lot of time with the sponsor and/or business owners. You have a wealth of knowledge how the system should operate to meet the business needs articulated by sponsors, end users, and business tester. You need to capture this knowledge into potential Service Level definitions.

The following are possible metrics to track:


  • Budget vs. Actual


  • System Availability
  • Hours of Rework to fix Changes to Production (check on quality of testing)

Customer Satisfaction:

  • Trend the Customer Satisfaction survey

Turnaround Time:

  • Average Time to Close a Incident
  • Age of Open Incidents: Maximum, Average

An appropriate question to ask is if each Service Level Metric is worth the effort it take to produce? Some items may not have enough value to justify the cost to measure them. On the other hand, there is a saying that you don’t get what you don’t measure. The metrics must be balanced and focused on business outcome.

Task #4 Knowledge Transfer

Develop a method for Knowledge Transfer from the project team to the maintenance team, which should be planned well ahead of time. Knowledge Transfer can take months and involve many steps: walk-through, training class, and on-the-job training, throughout many of the projects phases. The Knowledge Transfer method should include:

  • Develop expectations, approach, and schedule
  • Determine Knowledge Gaps
  • Develop individual learning plans to address skill gaps
  • Develop tracking metrics

As the project manager of the development team, you have a good understanding of the skills needed to support the system. You can start by capturing these needed skills in a Skills Matrix.

As the complexity goes up and more systems (including system components and interfaces) need to be supported, the more likely a team will need a variety of skills to provide proper maintenance. Producing a Skills Matrix is a simple way of keeping track of this. The matrix lists all the supported components and the needed technical skills. The Skills Matrix is simple but provides an effective way to document what skills are needed for each supported component.

Exhibit 3 (Malinowski, 2007) provides a template for the Skills Matrix. The first column of the matrix lists all the supported components such was systems, interfaces, and reporting tools. The remaining columns are titled with the skills (programming language, database, and operating system). Additional columns can be added for skill in understanding specific applications or systems. Simply place an X in the box where the system needs that skill. This can provide a quick view of what is needed to support the entire scope and help identify any training needs of your team.

Skills Matrix

Exhibit 3 Skills Matrix

Task #5 Controls

What controls need to be in place to ensure the likelihood of meeting the project’s original expected value? Disciplined management that is evident in project management, needs to continue for maintenance even if the management processes need to be modified. The following will address three overall controls (Financial Tracking, Request Approval & Tracking, and Configuration Management) that are needed for maintenance. Some of these could be in place as a standard for your company. In this case, ensure that what your project turns over is in alignment with the standards. In other cases, we, as project managers, can assist the maintenance team in taking over some of our project management processes and modify them to be used for maintenance.

Financial Tracking

Diligence in tracking the cost of our projects helps ensure that we do not exceed our budgets. This is true for maintenance but this diligence also provides a view into the workings of the maintenance team. From the business owner’s (bill payer’s) perspective, they may be expecting a flat rate of discretionary enhancements demand. Even if they approve additional enhancement requests, they may not fully understand the cost ramifications until they see the financial reports. These reports can be a good indicator if the demand management process is working as they anticipated.

From the maintenance manager’s perspective, these financial reports can indicate inefficiency areas that need to be improved. With the right level of time tracking granularity, the manager can see if an abnormal amount of time is spent on one activity such as batch job restarts. If an improvement is made to prevent the need for the restarts, this time can be saved and over time, less people may be needed to staff maintenance, thus saving cost.

Request Approval & Tracking

Scope change management is a process that every project manager needs to diligently manage. A project can only handle so many change requests before the project needs to be reevaluated and rebaselined. However, for maintenance of the system, request for changes are just the normal part of maintaining the system. A similar process for project scope change management needs to be used for ongoing maintenance including appropriate approval steps. The one major difference is that the process needs to handle a lot more requests in maintenance.

Configuration Management

Configuration Management is the last control that we will consider. Below we divide Configuration Management into five distinct controls. Note: You may define these terms differently or combine them. The intent of what each control ensures is important; the terms are of less importance so long as your organization uses the same terms.

  • Version Control – the process and most likely the tool for traceability of version changes
  • Software Change Control – verify changes and obtain necessary approval before migrating
  • Migration Control – ensure only the correct components are moved into production
  • Production Control – ensure the stability of the production environment and minimize business interruption
  • Environment Control – ensure non-production environments are controlled but less stringent than Software Change Control

The controls of Configuration Management must be repeatable for the maintenance team to function properly. Each change should be handled the same. The processes for each control must be well documented and the specific changes must also be documented. The entire process must be able to pass an audit including the retained evidence of changes and their approvals. Your development team may have many of these processes already documented. Pass them along to the maintenance team, if they are not already your companies standard.

Final Word

Leadership is not a new subject for project managers. It takes leadership to consistently deliver projects on time and on budget. But in this paper we focused on leadership beyond our project’s “four walls” and into the realm of the overarching interests of our organizations. We explored what we can do to not only deliver a project but also deliver a project that will continue to produce business value year after year.

Of course this is not our solitary focus. As presented in the Leadership Triangle, we need to operate at all levels including team administration and management. But we also see the value at leading outside our projects.

Learning something that you will never use is “entertainment”. Learning something that you apply is “education”. The difference between the two takes leadership of the basic level, leadership over you. You must first take leadership over your own actions before you can lead others.

Covey, S.R. (1989) The Seven Habits of Highly Effective People. New York, NY: Simon & Schuster

Project Management Institute (2004) A Guide to the project Management Body of Knowledge (PMBOK® Guide) Third Edition. Newtown Square, PA: Project Management Institute

Malinowski, M.F. (2007) IT Maintenance: Applied Project Management. Vienna, VA: Management Concepts

© 2007, Michael F. Malinowski, PMP
Originally published as a part of 2007 PMI Global Congress Proceedings – Atlanta, Georgia



Related Content

  • Project Management Journal

    Servant Leadership and Project Success member content locked

    By Nauman, Shazia | Musawir, Ata Ul | Malik, Sania Zahra | Munir, Hina Employing self-determination and social identification theories, we examined how servant leadership, which focuses on employees’ needs, influences project success.

  • Project Management Journal

    How Servant Leadership Drives Project Team Performance Through Collaborative Culture and Knowledge Sharing member content locked

    By Nauman, Shazia | Bhatti, Sabeen Hussain | Imam, Hassan | Khan, Mohammad Saud This research compared how two distinct mediating mechanisms influence the servant leadership–project team performance relationship.

  • Project Management Journal

    The Effect of Political Skill on Relationship Quality in Construction Projects member content locked

    By Wang, Dedong | Liu, Yang This study aims to investigate the relationship among political skill, cooperative conflict management styles, and relationship quality.

  • Project Management Journal

    How Power Influences Behavior in Projects member content locked

    By Wynn, Conor | Smith, Liam | Killen, Catherine Taking a case-study approach, we traced the thoughts of project managers subject to power, particularly those who resisted.