The Project Management Corner

Scope creep is the bane of many project managers. It can impact the timeline, cost and quality of a project as well as the morale of the team. In software development, scope creep is a leading cause for project failures. Project managers have to get a handle on the scope of a project from day one, to prevent it from spinning out of control.

Scope creep refers to uncontrolled changes which causes the scope of a project to grow continuously. The only way to prevent this from happening is to maintain constant vigilance from the start of the project to manage and control all changes throughout its lifetime. For an IT service provider, this is especially important with fixed priced contracts where the costs have to be tightly controlled. For an organization that is implementing a new system, scope creep can impact business critical timelines and cause customer dissatisfaction.

Project managers should keep in mind that scope creep is inevitable in any project and preventing it altogether is not realistic. The goal of a project manager should be to control and manage the changes systematically and not let it get out of hand. Control the scope before the scope controls you. Be aware of the all changes proposed by the client, the stakeholders or the team. Ensure that impact analysis is done even for the smallest change, identify the effort, factor in the financials, follow the change management approval process and update the plan.

Scope creep is a popular topic in project management and there is a lot of content dealing with the subject. Following are some of the articles that I came across which offer useful tips on how to prevent scope creep. If you are looking for methods or best practices on how to manage the project scope, I encourage you to read through these.

1. Taming the scope creep by Brett Harned
2. How to Manage Scope Creep—and Even Prevent It From Happening by Tim Clark
3. 5 Steps to Preventing Scope Creep (and Still Keeping Your Clients Happy) by Tom Ewer
4. 4 Ways to Prevent Scope Creep from Base36
5. 7 Proven Ways To Control Project Scope Creep from Project-Skills
6. Trapped in Scope Creep: How a Contractor Can Avoid Common Mistakes in Fixed-Price Externalized IT Projects by Dominika Chambon

To summarize, here are my key takeaways from these sources.

• Have a well defined scope of work. The agreement should be written clearly. Ensure that all parties understand what is and isn't included in the scope.
• Do your due diligence at the start of the project. Read and understand the scope, create a plan based on that scope and review it with your team and your clients.
• Understand the project objectives and the requirements. Know the deliverables and their functionality and what the client wants to achieve. This will help you to spot unplanned changes that may pop-up.
• Baseline the first version of the plan and use it to present your case for more time or budget when the scope starts to increase.
• Make the requirements very explicit. Go into the details to ensure there is no ambiguity.
• Keep track of all the changes religiously and document everything. Make sure all the relevant artifacts are updated with version control in place. 
• Do the impact analysis for each and every change and discuss the impact to timelines and budget. The conversations will help everyone to understand what is affected.
• Have a well defined change control process and communicate it to the team, stakeholders and clients. Make sure that the changes go through the required approvals so that everyone agrees. The change control board should include key members from all disciplines.
• Don't be afraid to say 'no' if the scope changes are unreasonable. Be wary of changes to the critical path. Discuss the risks and issues openly.
• The customer is not always right. Don't be a passive service provider. Collaborate with the client to establish what they want to achieve and use your expertise and perspectives to guide the client. Question the changes that are requested to make them think critically. Ask how it contributes to the overall objective.
• Expect scope creep to happen and include contingencies in the effort and pricing. This will be an insurance policy. Clients don't always know what they want and requirements will change during the elaboration and review.
• Define a clear sign-off process and follow through on it. Make sure that the client understands the process,
• Have a flexible design that can accommodate changes. This will help to reduce the effort and cost required to change or enhance the system.
• Communicate often and don't worry about over communicating. Make sure that the changes and resulting impact are communicated and understood by all parties. 

If managed appropriately, scope changes can be a positive and they can bring in more revenue to the organization.  If you can keep your client happy and increase revenue, you will be a project management hero!

Creating and maintaining a requirements traceability matrix (RTM) is not a simple task. It is time consuming and requires a considerable amount of effort and commitment from the project team. In my experience, the RTM is one of the artifacts that is frequently out of date and constant reminders are needed to ensure that it is updated by the team. The RTM has its uses, but I find that project teams rarely use it. The sheer effort that is required to maintain the document deters the team and if it is not a deliverable to the client, the traceability matrix is usually ignored.

For organizations that follow enterprise quality management systems such as CMMi, it is compulsory to have traceability procedures. As a result the RTM becomes a mandatory artifact for software projects. However, whether it is actually used by the project team for its purpose is uncertain. Stakeholders generally view the RTM as something to be implemented to comply with standards. Consequently project teams spend less effort on traceability leading to an artifact that is not useful.

What are the key components of a RTM? A comprehensive requirements traceability matrix should include the following.

• Business objective
• High-level Use case / Use case #
• Requirement ID / Description / Type of requirement / Source
• Risks
• Dependent requirements #
• Design reference #
• Implementation class / module
• Unit test cases
• Integration test cases
• Implemented release / release #
• System test cases
• User acceptance test cases

Most RTM templates will not include all of these components. Organizations can customize the template according to their needs and may choose to add or remove certain elements. However, for the RTM to be complete and useful, I believe that all of the above components are required.

Given the amount of information that has to be included, it’s easy to see how cumbersome it can be to maintain the document, especially in large, complex programs. Not surprisingly, there will be resistance from the project team to keep the RTM up to date.

Here are some of the advantages and disadvantages of the RTM.

Advantages:

• Maintain forward traceability to ensure the completeness of the implementation.
• Requirement changes can be traced forward to associated requirements and all the work products that are impacted by the change.
• Reduces the effort required to do a thorough impact analysis.
• Reduces risk that one of the affected work products is forgotten which may result in an incomplete implementation of a change.
• Maintains backwards traceability to ensure that the product remains on the correct track with regards to the requirements.
• Ensures that the scope of the project is not expanded by adding design elements, code or tests that are not specified in the requirements.
• Implementation changes / new technical solutions can be traced backwards to the requirements and the business objectives to ensure that it is within the scope of the product.
• Defects can be traced back to determine if it is a code, design or requirement defect and what other work products might be affected.

Disadvantages:

• Additional effort required to create and maintain the RTM and update it regularly.
• Capturing requirements traceability becomes complex and expensive as the product grows in size and complexity.
• Maintaining traceability through changes to the system can be challenging as all changes have to be updated in the RTM.
• Manual traceability methods can lead to incorrect requirements traceability data.

In my view, the benefits outweigh the drawbacks. Investing the additional effort and cost to maintain the RTM will help to prevent problems arising from lack of impact analysis, incomplete implementation, expanded scope etc. during project execution. If the benefits of the RTM are clearly understood by the project team and other stakeholders, there would be less resistance to implementing it. I believe this can be achieved through proper training regarding the importance and benefits of the RTM. As projects become larger and more complex, maintaining traceability becomes more vital.

Have you implemented a requirements traceability matrix in your projects? What are the pros and cons that you have experienced? Please share your thoughts in the comments.

References:

1. Requirements Traceability Matrix - http://www.tutorialspoint.com/software_testing_dictionary/requirements_traceability_matrix.htm
2. Why Software Requirements Traceability Remains a Challenge - http://static1.1.sqspcdn.com/static/f/702523/9188499/1288392919397/200907-Kannenberg.pdf?token=0cOV5UTB4kPtIijp6g16fgqSAlo%3D
3. Why is it necessary to use a traceability matrix? - http://www.chiron-solutions.com/chiron-professional-journal/2011/01/27/why-is-it-necessary-to-use-a-traceability-matrix/

Recently I was involved in setting up a production support team during the transition phase of a project. Once the implementation was completed and the application went live, the production support team needed to be ready to take over the support activities. The usual practice is to ramp down the team during this phase and have a smaller team in place for support. While setting up the team we realized that it would be helpful to have a checklist in order to ensure that all prerequisites are covered and the team was ready to take over.

This checklist was created specifically for a production support engagement. However, it can be customized for any type of project setup. We didn’t have a proper checklist in place for this part of the transition. I believe the reason for this is that production support is an area where we don’t put in a lot of emphasis. The whole team is focused on the deployment and go-live activities that the post production support gets little attention. However, it is part of the service that we provide to the client and deserves equal consideration. Clients start using the product after the implementation and deployment are over, so we can’t afford to breathe a sigh of relief and walk away. We must have the same amount of focus in continuing to serve the client to make sure that they gain the business value of the application.

This checklist will help project managers to complete the tasks that are required to setup the post production support team successfully. This transition should also be part of the overall project plan and the tasks have to be included in the schedule.

• The signed contract is in place for the production support phase. This could be part of the application development contract or a new work order.
• The scope of work, roles and responsibilities are clearly identified for L1, L2 and L3 support as applicable. This is spelled out in the contract.
• Production support resources are identified from the existing team.
• The team understands the scope of work given in the contract. If the scope involves after hours or weekend support ensure that the team knows this and are comfortable with the working hours.
• Compensation / allowance policies are in place if after hours and / or weekend support is part of the scope. There should be an organizational policy for this.
• Knowledge transfer plans are created to transfer knowledge of the full application to the production support team. It is likely that they have been engaged in working on a subset of the application modules during implementation.
• Training plans are created to provide training of the support ticket system and the process / workflow.
• Knowledge transfer and training sessions are planned to be completed before the go-live date.
• Identify metrics to be tracked. Metrics should be defined in the contract. If not, use organization or industry metrics for similar scope of work.
• Templates / systems are in place to track metrics from day one.
• The project level process suitable for production support is defined.
• The governance structure and the escalation process are defined.
• Required templates for weekly / monthly status reporting are created.
• Client and team kick-off presentations are created.
• Kick-off meetings are planned before the go-live date.
• E-mail distributions lists are created.
• All team members have appropriate access to environments and applications which are to be used.
• Hardware requirements (telephones, data cards, laptops, etc.) are identified and hardware is allocated to the team.
• The shift schedule is created (minimum 3 months), if applicable, and published to the client. Include contact details, leave plans and holiday in the shift schedule.
• The project is setup in the internal systems. This includes all project management systems, billing systems etc. if this is a new work order.

In addition to the above, if the team is expected to support the production migration of the application, the training plan must include a walk-through and review of the deployment plan. The production support team should understand their responsibilities during the deployment process.

I believe this checklist covers all the actions / prerequisites that have to be completed before kicking-off the post-production support. Is there anything else that should be included? Please share your thoughts in the comments.