CHAPTER 9

Monitoring and Controlling the Project

Tracking Requirements

You may think now that the requirements are approved and baselined and that the work of the business analyst is done. Sorry! In reality, there is still much to do. The business analyst needs to support the project team in a number of ways. The first is to ensure that the requirements presented to the development team are “suitable for use”. This means that the developers, testers, and any other readers of the requirements will have enough information to implement the requirements. This will often require more analysis and modeling of the requirements to provide needed detail and clarity. Business analysts and project teams are often challenged at this point. The result of analysis and modeling may mean new requirements are written, but is it a new requirement or needed detail to support an existing requirement? The Traceability Matrix will help identify new versus elaborated requirements by noting the relationship between requirements. If the requirement is an additional detail to a higher level requirement, it is an elaboration. If it does not directly relate to the higher level requirement, then you have scope creep. It looks like Liz and team have such a case.

There is an approved requirement that “the system will provide sorting of lists displayed to the user”. Dave, the lead developer, asked Liz to provide more information on what data needs to be supported and what the preferences are for sorting. Liz reviews her notes from the requirements gathering sessions, and sees where the users specifically called requirement ID, status, owner, and date modified as items they would want to sort on. Liz provides this information to Dave and also states that sort default is in ascending order. The ability to sort in descending order is also required for date modified field. Liz further updates the Requirements Traceability Matrix with these changes and additions, and traces them to the original requirement.

As you can see from this example, sometimes an elaborated requirement really becomes more of a technical design. Generally, we want to leave the design to the designers and developers of the system, but often these people would like more direction from their business analyst to make sure that their design supports what the users will need and expect. How these items are addressed will vary from project to project and from team to team. What is important is that the roles and responsibilities are clearly defined early in the project and followed so that no toes get stepped on. At the minimum, the business analyst will need to review the design to ensure that it actually will meet the requirements as intended and stated.

Another responsibility of the business analyst at this point is to ensure that the requirements are being adequately addressed in the design, development, and test of the solution. This means reviewing design documents, the solution, and test results to verify that each requirement has been adequately addressed. This is tracked in the Requirements Traceability Matrix. The Traceability Matrix includes columns for each of these references, as outlined in the Traceability Matrix. The business analyst will update the Traceability Matrix to indicate where the requirements have been addressed. This helps ensure that each requirement is met throughout solution development, test, and implementation.

Change Control

Projects experience change. Projects take time and things change over time. Months or even years may have passed since we first started the project. We need to be able to accommodate changes in our projects in order to stay relevant. The project plan and the approved requirements are not the final say, or at least they should not be if we want to ensure that our project is meaningful to the business. Instead, we need to control how changes happen so that we can adapt without exposing the project to unforeseen risks. I often use the phrase “plan to re-plan”. It is easier to adjust a plan and understand the impact of a change than it is to predict a shot in the dark.

Business analysts and project managers are continually asked to add scope to projects. Understanding the project cost benefit and assumptions can help in determining those changes that should be considered or not. To do this, we need to trace our features and requirements back to the project goals and objectives. Trace the project goals and objectives to the organization goals and objects. Each change request presented should be evaluated to ensure it continues to support the goals and objectives of the organization and of the project. Going back to the business case is the best way to ensure alignment with the overall goals. If the change request does not directly contribute to these goals as outlined in the business case, then it does not belong in our project.

When we accept changes that are not in direct support of the goals of our project, we end up with “scope creep”. The changes will require more time and money to implement, yet not contribute to the project meeting its expected outcomes. This is a major contributing factor to our 65 percent challenge and failure rate on projects. Think back to your last project that was late or over budget. Was consistent change control a strong practice in that project? Did all the features delivered contribute to achieving the expected outcomes? A good idea does not necessarily mean a good idea for this project. Initiatives that do not support the business case of your project need to find or develop a business case of their own. This will ensure the investment decision for that initiative is held up to the same standard as the investment decision for your project.

Todd C. Williams, in his book,²⁰ shares the story of one project audit he performed:

… I asked for the change request log. The project manager replied that there was no formal list because this was an informal process established by him and the customer’s project manager. He assured me that the change orders’ net result would have no financial impact, since he was trading scope out for anything added …. After generating the change request log, I found a strong bias in the customer’s favor constituting a significant amount of scope creep. In addition, it showed multiple outstanding change requests that would take significant amount of time to evaluate, adding even more work to an already overburdened team (page 51).

The first rule of change control is to analyze each change to ensure the value to the solution outweighs the cost to the project. The second is to track all change requests and the overall impacts of each approved request to fully understand the impact of change requests on your project.

Each project should have a change control plan in place to ensure processes are used throughout the project consistently. The plan should include the following:

      •     The process through which change requests get submitted, including a standard request form

      •     The process through which change requests are logged and tracked

      •     The person responsible for analyzing the business impacts on the solution and solution requirements

      •     The process through which project impacts will be determined and measured

      •     Indication of how the recommendation by the project team will be developed

      •     The timing and process through which change requests and the recommendation get presented for decision

      •     The person responsible for the final decision: project sponsor or change control board

      •     The process through which requirements will be updated and re-baselined

      •     The process through which project plans will be updated and re-baselined

Just as with the project plan, in change control, the business analyst is responsible for understanding the impact on the solution and requirements, and how these impacts align with the business case for the project. The project manager is responsible for understanding the impacts on the schedule, budget, resources, and risks. Together, they can make the best informed recommendation on the change request to ensure value added to the project.

Matthew approached Liz and Mary with a request to make a mobile application for the Requirements Management System. Liz agrees that this would be a nifty feature, but has her doubts as to whether there is value in the change. She begins the Change Request form, while Mary goes to talk to the development team about the additional time and money that would be needed to see this through. Liz probes Matthew for more information as part of her impact analysis. The value of this project was assumed to be centered on more time for business analysts to do analysis. Matthew indicates that he assumes a mobile application would further speed up the work of business analysis. Liz runs this idea by a few of her business analyst subject matter experts, and they agree that while cool, the likelihood of them using the system through their mobile devices is very low. Liz includes this in her change request analysis. Mary provides the development estimates, and the completed Change Request is reviewed with Matthew. Upon seeing the costs and the assumed lack of benefit, he agrees that this feature should not be developed, and the Change Request gets filed as “rejected” for this project, but they all agree it may be a worthwhile investment in the future as a system enhancement project. Matthew files the Change Request away to possibly be the basis of a future business case.

Changing Business

When Kathleen (Kitty) Hass spoke at IIBA Seattle Chapter, she highlighted that we need to continually go back to the business case to make sure that the project overall will still bring value to the organization and that the change decisions made continue to support the business case. Have the assumptions stated within the business case changed? Have there been changes in the organization and industry that negate or enhance the value we can achieve?

In rare cases, we may find that the business case no longer makes sense. The organization cannot achieve the value originally expected due to changes in the environment, industry, or technology. This is where it is important to recognize the concept of “sunk cost”. Sunk costs cannot be recovered. In looking whether to continue a project or not, the evaluation need be on the additional cost to complete the project compared with the value to be achieved. To use an old cliché, “don’t throw good money after bad.”

In Strategies for Project Sponsorship, we provide the following example:

Your organization has chartered a project for a new customer relationship management (CRM) system to be developed inhouse. The project team spent three months planning the project, while the business analysis group elicited requirements. At that point, you had spent $50,000.

Eventually, the business analysts came back with the prioritized requirements, and the project team expended significant effort in estimating the work needed to meet the requirements. The refined estimates indicate that the project will take 50 percent longer and cost 50 percent more than provided in the early order of magnitude estimates. In the meantime, you hear of a competing organization that has implemented a cloud-based software as a service CRM solution with great success.

In this example there is $50,000 in sunk cost. In determining the best course of action, we no longer care about that $50,000. Our evaluation will be based on what additional investment it will take to implement compared with the overall benefit to be achieved. In this case the business analyst will complete an analysis of the cost-benefit of completing the current homegrown development project or stopping development in favor of buying offthe-shelf software looking only at future spending. You won’t be doing your organization any favors by continuing the current project if it is more cost effective to change direction. The point of our projects is to maximize profitability to our organizations, and here we have a chance to do just that.

It is more cost effective to cancel the development project and move to implementing the cloud solution. Forget the original $50,000. It’s gone! You cannot get it back!!

We also need to continually go back and look at the value of the projects that we were working on today. What was once going to bring the business value may have changed due to circumstances. For instance, new technology may make our project obsolete before we even get it out the door. In this case we need to do the valuation on whether to continue the project, adjust the project, or cancel the project in favor of a new investment. If we can no longer prove that it is of value to the organization, then we need to seriously consider canceling the project in favor of company profitability. It is far better to have spent $50,000 on something that we now determine not to be of value later and let the funds go than to spend $500,000 to finish it, wasting ten times the money.

Your Assessment

For the selected project …

       1.   Could a list of requirements be easily produced to accommodate a variety of needs?

       2.   Was the original business case referenced in making recommendations regarding requirements and scope change requests?

       3.   Did new requirements get evaluated against the original business case to determine the value to the solution against the cost of the project?

       4.   Were new requirements formally signed off by the project sponsor or change control board? If not, what was the overall impact on the project schedule and budget?

²⁰Williams, T. (2011). Rescue the Problem Project a Complete Guide to Identifying, Preventing, and Recovering from Project Failure. New York, NY: American Management Association.