PM Post: Organizational effectiveness is resource effectiveness
[Part 2 of a series in Multi-Project Management and Organizational Effectiveness. If you haven’t already read Part Organizations are multi-project systems.]
The old saw defining efficiency largely as doing things right and effectiveness as doing the right things definitely applies to multi-project systems. How individual tasks are defined and delivered are key to the efficient completion of individual projects. And choosing the “right projects” from the portfolio of possibilities is clearly related to the contribution of the efforts to the organization’s success. While these single-project and portfolio management concerns are beyond the scope of this chapter, strategies for managing the interaction of various active projects as they vie for the attention of the limited resources are not.
Understanding the importance of getting the right things done at the task level, and behaving accordingly are significant contributors to efficiency as well and are the basis for multi-project resource (organizational) effectiveness. Unfortunately, too many organizations overlook this and instead emphasize control of costs to the detriment of what they are trying to accomplish.
Maximizing throughput or controlling costs? In the previous section, the dichotomy of managing today’s deliveries as well as setting up for the future was discussed. Another pair of necessities for organizational effectiveness is found in the need to maximize throughput of the system and, at the same time, control costs. Many managers look upon these as conflicting requirements, as pressures to keep expenses down have the potential to threaten the ability to deliver more completed projects quickly and with quality.
This sense of conflict comes from confusing organizational effectiveness with efficiency, and even worse, with resource utilization. Assuring that everyone is fully utilized all the time may seem like a reasonable strategy for getting the most out of the individual resources, and, by extrapolation, out of the organization. On the surface, this feels like it makes sense. However, if a system wants to maximize its throughput, keeping resources fully loaded across the board actually hamper that objective for several reasons.
The first reason to avoid striving for full resource utilization is that if everyone is fully loaded, there is no slack to deal with the inevitable run-ins with Murphy’s Law. Given the uncertain nature of projects as unique endeavors, any negative deviation from planned expectations will require capacity to recover. If that protective capacity is not available, problems in a project will result in either cascading problems that will threaten the promises of other projects, or burnout of resources, or both. In either case, future throughput is threatened.
Similarly, without protective capacity set aside, there is no ability to capitalize on new opportunities that arise. Potential throughput is lost.
Multi-tasking multiplies time to complete projects.
In environments where full utilization of peoples’ time is valued, there will usually be time-sheets to fill out, or measurement and reward systems — formal or informal — that drive people to keep busy. In addition, in such a situation, projects are usually launched with an eye to making sure that no one is starved for work. As a result, there are usually plenty of choices of things for everyone to work on. With many active projects expecting progress, there is pressure to work on several at one time, splitting one’s time and attention across them. Unless an effective multi-project management system provides clear priorities for resource attention, people will strive to make the “measurement” look good by keeping busy and keeping several balls in the air. This is multi-tasking — working on several significant pieces of work simultaneously, switching between them before any one is completed and before it’s output is handed off to the next task in the project.
What happens in this situation is that, as a result of trying to make sure that everyone is always fully utilized (a seemingly efficient means of controlling costs), the time it takes to convert a task input into an output that is usable by the next task is expanded by the time it sits while another project gets the attention. In addition, the context switching cost — the time involved in the question, “Where was I?” when returning to a set-aside task — adds to the actual work time, adding further inefficiencies to the project. Throughput associated with these projects is lost as their completions are delayed beyond when they could have been achieved.
Resource efficiency is not necessarily organizational effectiveness. By striving to be “efficient” through high local resource utilization — by striving for cost control through avoiding “wasted” idle resources throughout the organization — the real objective is sub-optimized. Throughput of completed projects and their benefit — paid invoices, improved processes, or new products that will ring new cash registers — associated with those completions is threatened, lost, or delayed.
Constraint-Savvy Multi-Project and Resource Management
In order for a multi-project system to operate effectively for an organization, it needs to assure that the project pipeline isn’t overloaded. Also, when there are decisions to be made between project tasks vying for the attention of a resource, it needs to provide a clear priority that is aligned with maximizing the benefit from the total collection of projects so that the resource in question will pick up and work the “right” task without multi-tasking. The first of these requirements is directly related to understanding and managing the organization through its constraints.
Constraint = Capacity = Throughput. Unless artificially forced otherwise, or unless mismanaged to the point of non-recognition by overload, systems put together for a purpose typically have one or at most very few constraints limiting their ability to deliver that purpose. Like the clichéd “weak link of a chain,” a potential bottleneck resource can usually be identified as a limiting factor associated with project throughput.
The capacity of the system is the capacity of this constraining bottleneck. It doesn’t pay to try to push more projects into launch mode than this constraint can handle. They’ll only back up waiting for it to attend to them and they’ll distract and unnecessarily overload all the resources working upstream of the constraint. Rather than trying to tightly balance the load on all resources (and killing throughput in the process), a rational approach to managing such a system is to identify (or design in) a clearly understood constraint and manage that one piece of the system very closely.
Protective Capacity
The current constraining resource in a multi-project system could be located anywhere. By definition, other resources are non-constraints and have more capacity than would be technically needed to support the possible throughput of the system. But to start cutting and slashing this extra capacity indiscriminately would be a mistake. At some point, that would merely shift the constraint from where it is to another, potentially unpredictable part of the system at the same or lower level of capacity, or worse, set up a situation with hard-to-manage interactive constraints.
Instead, the means of managing the constraint for growth of throughput starts with stabilizing the system so that the extra capacity upstream of the constraint assures that the constraint is not starved for work. The only resource that should be kept near high utilization (note “near high” is not “at full”) is the constraint, since the output of the system is tied directly to its output. Project launches that are synchronized with the ability of the constraint to deal with them will, if sufficient protective capacity is available up stream, flow smoothly to the closely managed possible bottleneck. Similarly, once through the identified constraint, no downstream resource should be so tight that it delays the conversion of constraint output to a complete accrual of project benefit. Again that implies a necessary level of protective capacity downstream as well.
Once stabilized and ridden of the effects of overload and multi-tasking, the true capacity of the system and of its components is far more easily identified. At this point, the organization can take rational steps to grow its capacity and capabilities by systematic constraint management.
Implications for project portfolio management. Once the constraint of the system is understood, it will have implications beyond just project delivery performance. It will also provide useful input to the project portfolio process. If the organization is limited to taking on projects at the rate that they can pass through the bottleneck, then those projects that have a higher relative benefit value per time required of the bottleneck will be more valuable to the organization than those that require more bottleneck time, all else being equal.
One project may seem to have small face value, but if barely involving the constraint, it will be able to deliver that value while barely displacing some other project and its benefit. It’s almost a “free” project, taking advantage of the slack in the non-constraint resources. On the other hand, if a project that looks very valuable when complete, but requires so much constraint time that many other projects are denied or delayed, it becomes a serious strategic decision to move forward with it. If, by the nature of a bottleneck or constraint, taking on one project forces us to forego or delay another, then this metric of benefit per constraint usage becomes an important factor in the decision to launch.
[Continue to Part 3 - Managing the present and the future.]
