Leveraging Project Dimensions for Better Requirement Management
- Nagaraja Gundappa
What are Project Dimensions?
The PMBoK (Project Management Body of Knowledge) lists three entities as project constraints – scope, cost and time. Also known as triple constraints or the iron triangle, these elements have come to be classified as project dimensions off 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 completion. Each of these dimensions can be a driver or a constraint 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.
Illustrating the 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. For instance, in some projects, special features are critical to its business success and scope will be a driver for such projects. Similarly for some products, being the first to market is essential for business success. In such a case, time is the driver for the project.
Constraint: Any project dimension can be a constraint if it cannot be changed. In the example above, when feature is a driver, and there is a fixed time by which the product has to be released, time is a constraint. In cases where the budget is limited, cost can be a constraint.
Degree of freedom: Any project dimension on which the project manager can exercise a certain flexible control (increase or decrease) is called a degree of freedom. Let’s analyze a case of a business critical product that is driven by a time-to-market strategy, has a minimum feature set that cannot be reduced, and is well funded. Time is a driver because faster they release, the better it is for the business and hence the teams will chase deadlines; feature set and hence scope would be a constraint because it cannot be reduced further. Cost can be increased while responding to changes as the project is well funded and hence cost is a degree of freedom in this example.
Having looked at project dimensions, let’s now explore their role in managing requirement changes.
The problem of requirement change management
When requirements change, software project managers are stuck in an unanticipated project situation after which the project slips from their grip and takes its own course. In many such cases, it is not that the PMs are unable to respond to the changes with a re-plan, but are unable to carry the customer along, with their requirement change management plan. The customer doesn’t approve the changed plan. A common perception about such situations is that the soft skills of the PM such as assertiveness and persuasiveness can solve the problem by convincing the customer and making him toe the line. While the importance of these soft skills is not denied, a flaw in this expectation is that it is not customer-centric; it doesn’t reflect an understanding of why customers don’t approve the change of plan. One of the reasons why customers don’t agree to change of plan is that they are constrained by what they have committed to their stakeholders. 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 of plan. No amount of soft skills on the PM’s part can get customer’s concurrence if the change of plan implies compromise in areas where the customer is constrained by his stakeholders. This is where project dimension analysis helps the PM to identify the degree of freedom and carry the customer along.
How Project Dimensions can help
When faced with changes, if the PM devises a change plan along the lines of degree of freedom, then there would be a large likelihood that the customer would agree to the changed plan and the project wouldn’t go off track. The project dimensions helps the PM understand where the customer also has elbowroom and is not constrained by his/her stakeholders.
Consider the following situation –
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 agrees that the proposed change is a change in scope but doesn’t agree for a schedule extension. The team is disappointed but because they don’t want to antagonize the customer, they don’t explore further possibilities and try to include the changes into the current deadline because of which the project goes off track. Now, let’s consider the possibility that the team explores further alternatives and instead of schedule extension, they explore if any of the existing features could be cut off so that the team members could be redeployed to work on additional requirement. Or the team proposes to increase the number of resources without extending the schedule; would the customer agree to such a proposal? The chances are pretty good that the customer agrees to at least one of the three plan-change proposals depending on which dimension is a degree of freedom for that customer.
It is very rare that a customer is constrained on all 3 project dimensions namely, scope, cost and time. One of these dimensions ought to be a degree of freedom and it is the onus of the PM to identify the degree of freedom, plan the change strategy on the line of the degree of freedom to maximize the concurrence from the customer. Once this strategic alignment is done, then the soft skills can come in handy to get customer concurrence in the easiest and smoothest possible manner.
Project Dimension analysis needs to be backed up by other PM competencies
While convincing the customer about the change of plan is one big challenge, implementing the plan is the next major challenge. While extending the schedule is an easy way out, adding more resources to implement additional requirements within the same deadline is not so straightforward. Bringing the new resources up to speed is a challenge with this option. In a resource-optimized schedule, moving around resources between tasks without affecting the resource loading is not easy. Same is the case with dropping some features and reallocating resources. A PM should foresee these possibilities and should have a good project schedule that can provide good clarity to enable decision-making. For instance, the project network diagram can be of help here by identifying tasks that have maximum float so that new resources can be allocated to the tasks with maximum float and hence their learning curve can be accommodated. The schedule must be drafted so well that it gives visibility about which resources will be freed up if a certain feature is dropped. This visibility helps the PM to decide which one among the low priority-feature can be dropped and to what tasks the freed up resources can be assigned. It calls for another article to discuss implementation of these strategies in the form of case studies.
To summarize, responding to requirement changes effectively involves 3 main aspects –
- Dimension analysis, identification of customer’s degree of freedom and a plan revision leveraging the degree of freedom.
- Soft skills to obtain customer’s concurrence for the change of plan which is along the lines of degree of freedom.
- Implementation strategy to leverage the degree of freedom so that the team can meet the revised target successfully.