Leveraging Project Dimensions for Effective Change Management: 3 Case Studies

Leveraging Project Dimensions for Effective Change Management: 3 Case Studies

– Nagaraja Gundappa

Project dimensions namely scope, cost and time can be classified into 3 types – driver, constraint, and degree of freedom. If the project manager identifies the degree of freedom appropriately and chooses to respond to requirement changes based on the degree of freedom, the chances of getting customer concurrence increases thus also improving project success. The following 3 case studies illustrate this principle in more detail.

Case study 1:  A large tax filing app – A large tax filing application with a big corporate customers, had serious performance issues on the user interface side that led to customer base erosion.  The application was outsourced to be reengineered on a different architecture to resolve the performance issue. The biggest challenge before the vendor team was to a hard deadline.  The reengineering had to be completed before the commencement of tax season, as the end customers would start preparing their filing by then.  A delay meant a loss in revenue and customer base erosion as they shifted to using competition services.

When project dimensions are analyzed, duration was definitely a constraint because the consequences of delay in delivery was fatal to the business.  However, this application being a revenue earner, the company was more flexible with the budget and cost (resources) could be a degree of freedom.  Better performance (Scope in terms of non-functional requirement) was the driver of this application.

time for a change 2015164 960 720 min

The project team anticipated and prepared for many changes that could come at any point in time.  As resource was a degree of freedom, the team formulated strategies to bring more resources on board the project as and when needed. 

The team identified features that involved the least domain / application knowledge so that such tasks could be assigned to temporary team members.  As anticipated, the changes did come and the team added resources quickly and trained them by assigning them to test case creation and testing before moving them to functionality development. This process helped the team avoid major delays by strategically adding more resources when faced with requirement changes and the project was completed within two weeks after the agreed upon deadline. In the end, the cost went up by almost 20% due to padding up resources, but the customer was fine with it as his major concern was meeting the deadline.

Thus not only did the team understand the degree of freedom, they also implemented project strategies around this degree of freedom to ensure success. 

Case study 2 – Back office application of a travel company – A major web-based travel company in the UK had to re-engineer their back-office system from stand-alone application to a web-based application in multiple phases.  The CIO who had to prove himself by demonstrating the business value of this back office application, he was very particular that the application is released as quickly as possible.

Analyzing this project, being a back office application, the organization was not willing to spend liberally and this meant that ‘resources’ (cost) was a constraint. The CIO’s push for an early release meant that schedule is a driver rather than a degree of freedom.  However, there was room for some freedom in scope as the functional areas were to transition into the new platform in multiple phases and leaving out certain functionality for one release did not jeopardize operations.

Having identified scope as a degree of freedom, the next step was to identify and implement a project strategy leveraging this degree of freedom. The questions before the team were:

  • If there is a likely delay in the project how to de scope functionality and reallocate resources?
  • What functionality is a better candidate for scoping out and how to determine that?
  • How to reallocate resources from scoped out functionality and speed up application development?

The team worked out priorities for requirements (and functionality) in consultation with the customer and categorized them into 3 levels of priority.  The team then identified resource backup as a strategy for quickly moving around the resources.  Many projects implement resource backup as a risk contingency plan.  That is for each module or functionality there would be primary resources responsible for delivery of that functionality, and there would be secondary resources who are aware of this module by involving themselves in reviews, customer calls and so on.  The idea is that these backup resources (who are actually primary resources for some other functionality) can take charge of the module just in case the primary resources are unavailable for some reason.  In this instance, the project team implemented this resource back up strategy not as a contingency plan for unavailability of primary resources, but for ability to move around resources and speed up development. The resources responsible for priority–3 functionality were marked as back up resources for other priority- 1 and priority – 2 functionalities so that if they were moved to another functionality with a short notice, they could be up to speed quickly.  This strategy enabled the team to respond to changes with scope reduction and reallocation of resources and could carry the customer also along.

Case study 3 – Performance management application: A Large US based manufacturing organization had to develop an employee performance management application and migrated from manual paper-based system to the automated system.  The proposed system touched many functional areas, the main one being automating the performance appraisal cycle that included objective setting, intermediate reviews and annual appraisal.  Other functional areas included employee career planning and development, competency development and training, interfacing with other HR and finance applications and so on.  In spite of covering a number of functional areas, this was still a small application by size.  The system development started well before the next impending appraisal cycle and was outsourced to an offshore team.

Analyzing the project dimensions, as this was an internal application, the budget was not liberal and resources could not be a degree of freedom. As the application was a small one there was not much scope for tinkering with functionality. But, the schedule could be a lenient one for two reasons – the appraisal cycle was still far away and transition from paper-based system to new system had to happen from a functioning manual system in phases and a slight delay of transition of one function did not have a critical impact on the operations of the organization. Therefore, the schedule could be a degree of freedom. The team worked on this and ensured that the project was executed on a time & material basis with a small team so that they did not incur loss if the project got delayed.  Since the team size was small, even though an extension of schedule meant a slight increase in cost, it was still bearable because of small number of resources (Presence of increased number of resources for a longer duration would have had a much bigger impact on cost and hence resources was not a degree of freedom). As this application touched many functional areas of performance management, there was always a chance that a stakeholder came up with a requirement that he did not mention earlier and had to be incorporated into the release. Such requests could be accommodated with extension to schedule.

The dimension analysis for the 3 case studies is summarized in the following table.

Case study image

Thus analyzing project dimensions and identifying the right degree of freedom enabled the teams to identify and implement the right strategy to respond to potential project delays and keep the project on track.  The analysis also helped the team to carry the customer along with their strategy and plan change proposals. 


There are many reasons other than the degree of freedom for which customers may not go along with plan changes. Implementing plan changes along the lines of chosen strategy may be more complex than the situations in the case study.  Nevertheless, identification of right degree of freedom is definitely a simple, smart, and effective way to start gaining better control over the project, carry the customer along and ensure project success.