Dealing with Classic Project Management Constraints When in Crisis

May 14, 2010 – 2:35 pm by Howard Moorin

One of the first tasks a company completes when it decides to implement new software is to determine the “Project Management triangle” constraints: scope, costs and schedule. While subsequent efforts should be focused on delivering a project within these constraints, there must also be flexibility to manage the underlying constraints in the event of unforeseen circumstances. In some cases, however, one or more of these constraints are not at all flexible. This paper looks at a hypothetical case where the scheduled deployment date and project scope cannot be altered, and where increasing expenditures cannot, by itself, solve the problem.

Envision a project that consists of developing and deploying a proprietary application to be used by both internal corporate personnel as well as a network of outside sales representatives. These outside representatives (as well as the internal users) are expecting the application to provide the functionality specified in the scope statement. The need to meet this expectation severely limits your ability to change the scope. At the same time, for a number of technical, legal and financial reporting reasons, the application must go into production at the beginning of the fiscal year.

Following these constraints, you develop your schedule. Because some extra time is available, and thanks to some foresight by the project manager, some ‘slack’ was incorporated into the schedule to allow for some of the unexpected delays that often accompany complex deployments.

Imagine that development of your application proceeds smoothly through the early stages of your project and a relatively robust system is ready for testing as planned. At this point, though, the first troubles appear: developers failed to deliver some of the planned functionality and during the QA process testers discover twice as many defects as you expected them to find. To make matters worse, many of the defect fixes either fail to resolve the problems or lead to new defects. Soon, you realize that you have already eaten into most of your ‘slack’, and your deployment is still behind the planned schedule.

You next increase expenditures and bring in more technical resources. While this is helpful, it is not enough as these resources only have certain technical skills and the project can only accommodate a certain number of ‘cooks in the kitchen’ before it leads to declining marginal returns. At this point, you have no flexibility to change the deployment date, reduce scope, or increase expenditures. So, what do you do?

Making Changes Inside of Your Constraints

While your constraints limit your overall ability to deliver your project, there are some options available that allow you to work inside of your constraints in order to meet the overall project parameters. These options include:

Prioritizing Your Work Efforts

Imagine for a moment that there are two cars in a garage, neither of which works. You can either devote an equal amount of time and effort to each car until they both work, or you can devote more time to one car until it works before turning your attention to the other car. This is analogous to approaching scope constraints – you can choose to focus on scope areas that are important to your external sales partners to ensure their comfort with the application before working on areas that affect only internal users. You are still working to have all required functionality operating by the deadline, but your top priority is to be sure your external partners are not disappointed.

Overlapping Development and Testing

Ideally, you would have completed your development before testing starts. This allows you to focus your technical resources on addressing defects, improving system stability or enhancing functionality. However, when you are operating behind schedule, there are alternatives to consider. One possibility is to deliver specific functionality to your test team. While that functionality is being tested, your development team can be working to deliver the next functional component. This concurrent process can help a project return to its schedule.

Focusing Your Resources

In most workplaces, people face a large number of distractions. Even workers who diligently focus on getting work done are likely to spend significant time helping coworkers, participating in work area discussions and undertaking other tasks that, while they may be helpful to the company, are distractions from the key goal of getting the project back on schedule. One effective tactic to address this problem is to establish a ‘war room’ where those tasked with fixing defects or developing functionality are able to work without outside distractions – even work-related distractions. Optimally, the war room will have a moderator who can make sure there are no interruptions and who can help workers focus on the task at hand rather than distracting each other.

Conclusion

There are always project constraints. However, not all constraints are created equal. While project managers always hope they are lucky enough to have projects that allow constraints to be adjusted as the project unfolds, the reality is often the opposite. However, with creative thinking and resource agility, there are steps that project managers can take to complete their work within their original constraints. It isn’t always easy, but it is easier to attempt such adjustments than it is to concede failure.

Posted in Service Business Management | Permalink |