IT project closeout--the maintenance factor
Of the Process Groups (Phases) defined in PMI's Guide to the PMBOK® (Project Management Body of Knowledge), Project Closeout can be the most forgotten process -- not to say that project managers intentionally ignore Closeout. Many have good intentions but find themselves on a new project before the current one ends.
But for Information Technology (IT) projects, Project Closeout also includes the critical transition from the development team to the maintenance team. This transition can be weak with the maintenance team operating inefficiently for months while they receive fragmented information from a development team who has already disbanded. Anticipated benefits to the organisation/company can be delayed and users can become frustrated to the point of rejecting the system. Good project management does not end when the IT system is deployed.
This paper focuses on six additional activities to include in your next Project Closeout Phase (Exhibit #1). These activities can also be referred to as a Transition Plan. As usual, planning is your best ally. During the project's planning phase, you can include these activities in your work breakdown structure and schedule them with complete dates. The good news is that your development team does not have to perform all six activities; the newly formed maintenance team can help complete many of them. An effective transition to maintenance will help the business realise the project's predicted Return on Investment (ROI) and will help the maintenance team operate smoother from the start.
The following sections describe six milestones and related activities to include in your project schedule under the Closeout Phase. The completion milestones should be in the Closeout Phase but some of the tasks to reach these milestones may be in previous phases. This paper assumes you are either starting, or currently running a system development project. Exhibit #1 shows the additional tasks to include in your schedule beyond the tasks you already have defined.
1. Complete System Documentation
Your team will be completing many documents during the life of the project. The point here is to look at and define which documents are needed from an ongoing maintenance point of view. The following describes two important documents. These can be combined into one document but all the sections still need to be addressed. Useful documentation is an effective way for the maintenance team to mitigate the risk that they may not know where to start when a bug or enhancement requests arises. Two key documents are suggested here -- the Operations Guide and the Maintenance Manual.
The purpose of the Operations Guide is to address all the necessary operational procedures, requirements, and information needed to keep the applications running. The focus of this Guide is for the continued running of the application as it currently exists and how to prevent or minimise down time caused by any kind of incident. The following is a suggested outline.
- Overview - Describe system operations including application(s) and technical architecture.
- References - Reference documents created during system development and vendor manuals.
- Assumptions - List assumptions about the operating of the system.
- Contacts - List key clients, users, or subject matter experts.
- External Agreements - List agreements with other groups to provide some of the support functions.
- Production Diagram - Depict the production environment. “One picture is worth a 1000 words.”
- Directory - Clearly define where the files reside.
- Configuration Management - Define how the system pieces are maintained and fit together.
- Shutdown and Startup - Define procedures.
- Backup and Recovery - Define procedures for application, database, and any data files.
- Disaster Recovery - Define plan to reduce the impact of a major system problem.
- Data Archiving - Define business rules. Specify how long data will be online in the system.
- Performance Tuning - Define monitoring and tuning procedures as system usage increases.
- Security - Address administration procedures for adding new users, changing rights, and auditing.
The purpose of the Maintenance Manual is to provide information to support enhancements and fixes of the application or interface. This document should address everything needed to find source code, compile the programs, and configure the system. The manual should include considerations that were addressed when the application was first built. The following is a suggested outline.
- Overview - Describe what is included, and not included, in the system.
- References - Reference documents created during system development and vendor manuals.
- System Diagram - Depict the interconnections within the system and interfaces to other systems.
- Directory Structure - Clearly define where the source code and other files reside.
- Developer and Production Environment - Define environments including needed security rights.
- Instructions - List necessary instructions specific to this system such as compiling the system.
- Tools - List tools such as compilers and debuggers used to build and maintain the system.
- Migration Flowchart - Show complete process for starting with code change through deploying.
- Communication - List who needs to be informed of any new software deployment or any bug fixes.
- Error Message - List any known error messages and the appropriate problem resolution.
2. Develop Skills Matrix
The systems we deliver today can be quite complex. The more system components, applications, interfaces, and reports your team delivers, the more likely your team will need a variety of skills to successfully deliver the project. Equally so, the maintenance team will need the same skill set. Who better than the development team to define which skills the maintenance team will need. A simple matrix of the system components and the needed skills will help communicate these needs to the maintenance team. (Exhibit #2).
This matrix can be used to spotlight any gaps, which can then be addressed by training. The development team will be in a good position to train the maintenance team. Better still, is to have the maintenance team involved early on in the project so they can see first-hand how the system was built, issues that arose, and thought-out solutions.
3. Develop System Ownership Matrix
For complex systems, there may not be just one business individual who “owns” the system and can authorise changes. The ownership of the system components may be distributed among many individuals. These owners are the key stakeholders and the ones who reap the benefits from the system. They ultimately know how the components support the business needs.
Instead of assuming that the maintenance team will know who these owners are, you can take the step of listing them in a simple matrix. The Ownership Matrix Template in Exhibit #3 documents the relationship between the components and owners. Creating this matrix is a quick task to complete when you already know this relationship.
Besides the owners of the components, there may be Subject Matter Experts (SMEs) as well. These are the additional business people who have extensive knowledge of one or more components. They can be included in the matrix for further information to the maintenance team.
4. Define Metrics
Your development team's measure of success is to deliver the project scope on time and on budget. You can use tools like earned value, schedules, and budget-to-actual comparisons to determine the project's status.
But for maintenance, the measure of success is different, and the development metrics previously listed will not work. Maintenance is a service where the client does not necessarily have expectations on what the maintenance team should provide next month; however, the client can tell you clearly what the maintenance team should have delivered last month.
This highlights the difference between projects and non-projects. PMI defines a project as “a temporary endeavour undertaken to create a unique product, service, or result”(PMBOK®, 200, p. 204. But system maintenance does not meet this definition of a project. Maintenance does not have a clear end date and the work is not unique year after year. “Is maintenance a project?” This can be an interesting debate -- but here we just want to highlight the differences. Exhibit #4 compares Development versus Maintenance.
The conclusion is that we need appropriate metrics for maintenance. As the development project manager, you probably have heard the client indicate what is important to them about the system. So you are in a good position to draft the list of metrics. Exhibit #5 can be a checklist to consider. The final list of metrics needs to be agreed upon by both the client and the IT maintenance team.
5. Define Scope of Maintenance
Your development team started with a project charter to define the initial scope. During the first phase of your project you completely documented the scope. But the charter and additional scope documents only authorise resources to implement the system. They do not authorise resources to maintain the system once the system is in production.
The controlling document for maintenance is the Service Level Agreement (SLA). The SLA identifies the services that the IT maintenance team will provide to the Business to keep the system running. The SLA serves as a contract between the IT group and the business owner of the system, thus replacing the project charter.
Who writes the SLA? It is fair to say that the IT maintenance team should write it since they will be the ones delivering the services. But as proactive project managers of the development team, we can help this process. We can include in the closeout phase a task to complete the first draft of the SLA. We can assign this task to the maintenance team or to our development team. The final version should be the responsibility of the maintenance team, but in order for the development of the SLA to be meaningful, the business owners of the system should be intricately involved throughout the entire process. The business owners are the ones who will judge if the maintenance team is successful, so their thoughts should be captured in writing in the SLA.
The SLA document should address all the services to be provided by the IT maintenance team as well as all the services that will not be provided. The business' responsibility in the arrangement must be spelled out to avoid confusion. The following paragraph describes the purpose of the SLA. This paragraph can be included right in your next SLA.
The purpose of this Service Level Agreement (SLA) is to define the scope of services that the ____ business will contract with the ____ IT Team. Included in this document will be the breakdown of the specific services provided, the list of components included, the list of response times, metrics used to track the success of the service delivered, services not delivered under this agreement, and functions that the business will perform. The costs of these services will also be broken down.
Service Level Agreement Outline
- Space for signatures of approval
- Timeframe services will be provided
- Purpose of agreement
- Overview of maintenance
- Constraints of maintenance
- Service activities included and excluded
- Response and escalation times based on different severity levels
- Maintenance team contact information & escalation
- System components included and excluded
- Cost of the services
6. Tracking Database
The last subject we will cover is the use of a tracking database. This is a subject that can apply not only to the maintenance team but to your development team as well. Many new development project managers find it challenging to track the number of issues that arise while managing a project. Taking a systematic approach to this can help track the issues' status, who owns it, targeted completion date, and any notes about it. If you don't have a formal process, consider this section a recommendation. If you have a formal process, consider sharing it with the new maintenance team.
Specifically for maintenance, it can be an overwhelming nightmare to track all the questions, requests, bugs, enhancements, system admin changes, database changes, and migrations after the system is implemented. Communicating the status of each type of incident to stakeholders outside the team is a challenge, let alone ensuring that only tested fixes/enhancements are migrated to production. Each type can have different attributes, but setting up one database to track “everything” is the solution. The database or tool you use for tracking must be workable for the volume of data and for the number of people accessing it -- but beyond these, any tool should work. A spreadsheet most likely would be too limiting. A database system or even a test defect tracking system works well.
The following are attributes to record for each incident:
- Incident reference number
- Type of incident (bug, enhancement, data fix, sys admin)
- System component
- Status (new, analysis, working, testing, complete, canceled)
- Person assigned to work the incident
- Date entered
- Date completed or canceled
- Short description
- Long description
- Working notes
With this information being available, it is easy to report status and manage the team with greater effectiveness. The manager can mine data to see where potential internal processes could be improved to increase the performance of the team. Reporting the volume of incidents by type to the business owners can open their eyes to how much it really takes to maintain the system.
Successful implementation of Information Technology Projects does not always lead to the projected return on investment year after year. This may be due to problems maintaining the system that can also lead to users rejecting the use of the system. As the development project manager, you can help by adding these additional six tasks into your closeout phase to insure a smooth transition from development to maintenance of the system. Developing a reputation for yourself as someone who sees the full lifecycle of a system can only enhance your career as a profession project manager.
We know the importance of quality project documentation, but we must not forget to complete the Operations Guide and Maintenance Manual. We need to pass along knowledge to the people maintaining the system for years to come. Providing a simple Skills Matrix and System Ownership Matrix will document some of this knowledge. As the development of the project continues, we will hear what the client considers successful operations of the system. That feedback forms some of the key metrics to document in the Service Level Agreement (SLA). A well-written SLA should eliminate any misunderstandings of what IT will provide as a service to keep the system performing year after year.
Lastly, both your development team and the maintenance team should have a method of tracking issues and incidents. If you have a method already, sharing this with the maintenance team will provide them with a jump-start on delivering.
These are some of the reasons not to ignore the Project Close Out Phase. It is your job to insure your project's success. Don't miss this opportunity to smoothly transition the system into the hands of the maintenance team and help your organisation realise all the project's benefits.
Project Management Standards Committee. (2000). A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Upper Darby, PA: Project Management Institute.