PM Post: Managing the present and the future
[Part 3 in a series on Multi-Project Management and Organizational Effectiveness. If you want to start with Part 1, you can find it at Organizations are multi-project systems.]
Once an organization understands the constraints associated with it’s ability to deliver projects, whether for customer-driven deliverables or for internal process improvements, it has the basis to not only avoid overloading its current capacity and capability, but also to smoothly growing the capability to take on more work in the future, whether next month, later this week, or next year.
Next month - “How much should we take on?”
Gating project launches. At the border of portfolio management and project management lies pipeline management. Nothing will bog down a project delivery system faster than the premature push of projects into a system that can’t really handle them.
Once the portfolio management or sales acceptance process determines the relative ordering of projects, the process for synchronizing project launches to constraint capacity is a simple matter of staggering them at the point of use of the constraint. Once it is known when the constraint can take on a new project, it’s a simple matter of placing it there in the calendar, perhaps with a bit of buffer to avoid cross project impacts at the constraint, and examining the resulting schedule to determine where it’s appropriate to start the upstream activities.
If project launches are staggered in this manner, then the constraining resource will not be overloaded. And if the constraining resource is not overloaded, then the other non-constraining resources will also, by definition, not be overloaded, thereby reducing pressures to multi-task and simplifying the question of priorities when the occasional need to choose which task to work comes up.
Today - “What should I be working on?”
Clarity of priority at the task level. If projects are not overloading the system, the question of which task to work is simplified by the mere reduction of active tasks in play. In-boxes are less loaded. However, due to the vagaries of project plans, and of variation in task performance, occasionally it might occur that a resource faces the need to choose one task to pick up and finish before addressing another one that is waiting. There are several options to providing such guidance.
Assuming that the individual projects are being actively managed via Critical Path or Critical Chain processes, one consideration is whether any of the waiting tasks are on the critical path or critical chain of the project in question. If so, that task would most likely be the appropriate first choice over a competing “non-critical” task.
If there is a choice of two or more “critical” tasks from different projects, the relative health of the projects in question can be easily assessed based on working one, then the other, and vice versa. The scenario that leaves the best combination of the resulting health of the projects’ promises in best condition (or maximizes the benefits associated with both projects) would be preferred. In an environment based on Critical Chain Scheduling and Buffer Management, project buffers provide not only the ability of projects to absorb such decisions, but also make the assessment process straightforward. Critical Path-based projects, usually relying on smaller, if any, schedule reserves, might have to add some additional recovery activities. (Note that this constraint-based approach to multi-project management comes from the same source as Critical Chain Scheduling and Buffer Management; the Theory of Constraints, and the two processes work together by design.)
If all queued tasks are “non-critical,” it’s less of an issue, and while usually a first-come-first-served process will suffice, a consideration of the general health of the project promise, or in the case of a Critical Chain project, buffer consumption, could also provide useful guidance.
Next year - “How much can we work on?”
Current and strategic constraints. In the previous section, the stabilization of the system around the organization’s current constraint was described. That current constraint is the result of past actions and staffing levels; it may not be an ideal leverage point for maximum strategic benefit. Once the system is stable, the organization can manage itself proactively by designing a more appropriate system based on what one might call a “strategic constraint.”
An appropriate constraining resource would be one that is commonly and heavily used across a range of anticipated projects, but is also hard to augment. If it’s easy to get more of it by acquiring more people or improving processes, then it’s probably worth doing so to easily grow organizational capacity, assuming the protective capacity around it is also easily grown. If hard to augment, it becomes a matter of offloading and/or improving processes to grow capacity. A constraint that is hard to get more of while commonly and heavily required is a natural candidate for a long-term constraint against which to manage the organization.
Additionally, such hard-to-grow resources are often critical to the organization’s competitiveness. For example, a system architect who know the ins and outs of the firm’s software products is far harder to replace, and is inherently more important to its capacity than some “plain vanilla” developer skill that can be augmented with contractors. If there is some other, easily elevated constraint in place, it behooves the organization to develop plans to grow it’s capacity along with any others who might be limiting what can be gotten through the expert. Understanding this relationship also highlights and justifies the need to grow that expert skill as well, perhaps through shared work or by determining what it is in the work usually performed by the expert that really needs the expertise.
An interesting offshoot of effective constraint management is that if one considers a limiting factor — a constraint — to be a weakness, then the system’s strength — the resource and skill that defines its core competency — should probably be that weakness. After all, you don’t want any other aspect of the organizational system to limit the ability to maximize the benefit of that strength. Developing such a strategy for growth that either grows resources around an appropriate constraint while increasing its capabilities, or provides a clear path to grow the necessary capacities to move the constraint to somewhere more appropriate provides a smooth transition from one level of performance to the next.
[Continue at Part 4 - It’s what you finish; not how much you start.]
