Project constraints or dimensions

The PMBoK (Project Management Body of Knowledge) lists three entities as project constraints – scope, cost and time. Also known as triple constraints, the iron triangle these elements have come to be classified as project dimensions of late. The term dimension is more suitable as each dimension can act as a lever for the project using which we can guide the project towards the end delivery. Each of these dimensions can be a driver or a contraint or a degree of freedom as explained below. The key to project success is in identifying what dimension is a driver, which dimension is a constraint and which dimension is a degree of freedom and always leveraging the degree of freedom to navigate the project. This article illustrates identifying and classifying the dimensions, leveraging the degree of freedom to respond to requirement changes.

The types of project dimensions:

Driver: A project dimension such as scope, or time or cost is called a driver when that is the reason for the existence of the project. In some projects, special features are critical to its business success and scope will be a driver for such projects. Similarly for some products, the features are common with the features of other competing products, but being the first to market is essential for business success. In such a case, time as a dimension will be the driver for the project.

Constraint: Any project dimension can be a constraint if it cannot be changed. In the above example, when feature is a driver, and there is a fixed time by which the product has to be released, time will become a constraint. On the other hand, for some projects that have a limited budget, cost can be a constraint.

Degree of freedom: Any project dimension which can be increased or decreased, on which the project manager can exercise a certain flexible control is called a degree of freedom. For instance, in a business critical product that is driven by a time-to-market strategy, a certain minimum feature set is a necessity, and the project is well funded, the time would be a driver (the faster the release, the better it is for the business; so the teams are supposed to chase time); feature set and hence scope would be a constraint because it cannot be either reduced or increased. Cost can be a degree of freedom as the project is well funded.

How the project dimension analysis will be helpful for responding to changes will be illustrated in the later sections of this article.

The problem of requirement change managemenet

There are many instances where software project managers are stuck in an unanticipated project situation after which the project slips from their grip and takes its own course.  Quite often, requirement changes are the reason for the project to slip out of control and project managers are at a loss when the changes are too many. The project also goes out of control because the project managers are often unable to respond with the right strategy to the changes and are unable to carry the customer with their requirement change management strategy. This is because, they don’t identify the right degree of freedom for the specific project and devise their change management plan based on the degree of freedom. Leveraging the degree of freedom is a very powerful way to wriggle out of such situations, carry the customer along and keep the project on track. 

Illustrating the use of project dimensions

Consider the following situations –

1. Project is on track, design is underway and the customer comes up with a major additional requirement.  The team responds in a standard way by applying the change control procedure, carrying out impact analysis, reworking the schedule, cost and presents it for customer’s approval.  The customer doesn’t agree and insists that the additional requirement must be accommodated in the existing plan itself.  He would have a number of reasons on his side to demand so.  The team knows that this is infeasible but still agrees with the customer and carries on; however, because of in-feasibility of the current plan, the project drifts off the track and takes its own course.  How to resolve this situation and keep the project on track?

2. Complexity of certain features was not fully understood initially and completion of certain milestones has taken much more time than planned and the project delivery will be delayed.  Customer is approached for extension of schedule, but he refuses.  Project team works with the original schedule, but cannot meet it and the project drifts off course.  How to resolve this situation?

A common perception about response to such situation is to put the onus on soft skills of the project manager – being assertive, ability to convince, ability to negotiate and so on.  The underlying expectation is that a project manager endowed with these soft skills would be able to wriggle out of these situations better.  While the importance of these soft skills is not denied, a flaw in this expectation is that it is team-centric and not customer-centric.  More than the ability to assert a given team’s position, one needs to understand the customer’s position and identify a win-win strategy. The project dimension analysis helps in understanding the customer’s drivers, constraints and degrees of freedom and identify such a win-win way out of the situation.  The soft skills then comes in handy in convincing the customer about this win-win strategy and get his / her concurrence.

In order to appreciate the importance of dimension analysis, one should dig into why it is difficult to get customer’s concurrence to a change of plan.  There could be many reasons as to why customers don’t agree to change of plan and one of the main reasons is that they are constrained by what they have committed to their stake holders.  If the customer finds it difficult to convince his stakeholders about the change of plan, then he would obviously find it difficult to go with the project team’s proposed change.  No amount of soft skills on the project managers part can get customer’s concurrence if the project manager’s proposed change of plan implies the customer to compromise in areas where he is constrained.  For instance, if certain features of an application are business critical and the customer has made commitments to his stake holders and the project manager proposes to drop or postpone implementation of some of these features in order to meet the dead-line, no amount of soft skills can convince the customer because he is constrained by the commitments he has made to his stake holders.  Therefore it is important to understand the constraints, drivers and degrees of freedom of the customer and identify a project strategy along the customer’s degree of freedom so that he finds it easy to carry his stake holders along.  Once the dimension analysis is done, a re planning on the line of degree of freedom stands a better chance of getting customer’s approval.  After convincing the customer about the change of plan, the project manager should have an implementation strategy to leverage the degree of freedom.  To summarize, changing project plan in response to a crisis and getting customer’s concurrence involves 3 main aspects – 1. Dimension analysis, identification of customer’s degree of freedom and a plan revision leveraging the degree of freedom.  2. Implementation strategy to leverage the degree of freedom so that the team can meet the revised target successfully.  3. Soft skills to obtain customer’s concurrence for the change of plan.  The case studies below illustrate the first two points.

Case studies of requirement change management using project dimensions

Case study 1:  A large tax filing app – A large consulting company in the US has a tax consulting business unit and have a corporate tax filing application.  The entire consulting business of the unit is almost based on this application which is also used by their customers who include large multi-billion corporates of the US.  At one time, this tax filing application had serious performance issues on the user interface side and the BU faced erosion of customer base because of this performance issue.  The application had to be redeveloped on a different architecture to resolve the performance issue.  Redevelopment was outsourced and the biggest challenge before the offshore team was to meet the stone-hard deadline.  The redevelopment had to be completed before the commencement of tax season as the end customers would start preparing their filing by then.  A delay meant that the customers would shift to the competitors and there was a risk of large-scale erosion of customer base apart from revenue loss for the current year.

When we analyze the dimensions of this project,  duration was definitely a constraint because 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.

The application being rich in functionality implementing significant domain knowledge, the project team anticipated that there would be many changes that could come at any point in time and had to prepare themselves for it.  As resource was a degree of freedom, the team formulated strategies to bring more resources on board the project as and when needed at short notice.  The team asked question such as

– How to train the new inductees to the team and bring them up to speed?

– How can resources be loaned into the project for short duration and what tasks can be assigned to temporary team members?

And identified features that involved least domain / application knowledge that 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 way, the team could 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, but they also implemented project strategies around this degree of freedom to ensure success.  The customer also was happy because any change of plan due to scope change used to be centered on resources and the customer had no problem convincing his stakeholders on the budget increase due to increased resources.

Case study 2 – Back office application of a travel company – A major web based travel company in UK had to re-engineer their back-office system from Visual Basic stand-alone application to a web based application.  Many functional areas such as hotel booking, airline booking, local travel etc. who were either using the old VB application or a manual procedure using Excel sheets were slated to transition into the new platform in multiple phases.  There was a bit of political situation in the organization and the CIO had a need to prove himself by demonstrating the business value of this back office application.  So he was very particular that the application is released as quickly as possible and outsourced the development to an offshore team.

Analyzing the dimensions of this project, this being a back office application, the organization was not willing to spend liberally and obviously this meant that ‘resources’ (cost) was a constraint and not a degree of freedom.  And the CIO’s keenness on early release meant that schedule is a driver rather than a degree of freedom.  However, coming to scope, there was a room for some freedom 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 and they would anyway get that functionality in the next release.  So, scope was clearly a degree of freedom.

Having identified scope as a degree of freedom, the next step was to identify a project strategy leveraging this degree of freedom and implement that strategy.  The question before the team was, 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 back up 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 back up 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 mover 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 functionality did not have a critical impact on the operations of the organization.  Therefore, 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 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.

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 their strategy and plan change proposals.  The analysis for the 3 case studies is summarized below:

Conclusion

To conclude, one may ask if identification of right degree of freedom is a silver bullet that can ensure that all change of plans get accepted by the customer? May be not.  There could be many more reasons as to why customers may not go along with plan changes. And 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.