The goal of the project manager is to complete the project on time, on budget and deliver to the scope. In order to accomplish this, the project manager creates a detailed schedule for each person on the project. In a matrix organization, the people are, however, answerable to the resource manager.

The goal of the resource manager is to ensure the maximum utilization of the people who report to him/her. The resource manager constantly has to juggle to ensure people are available for projects vs to ensure the people are kept busy (higher utilization).

Project managers are in a constant tug-of-war amongst themselves and the resource managers for people.

It certainly is a dilemma that project managers and resource manager face. A lot of time and effort is expended in trying to reach a consensus. It does not have to be this way. Let’s see if we can use the Theory of Constraints (ToC) thinking process to identify the root cause of the project manager and resource manager dilemma. Let’s also explore how we might end this dilemma.

The Theory of Constraints thinking process deals with cause & effect. For every action there is a cause and if we do not like the actions, all we need to do is to identify the cause and fix it. The trick is in going deeper to the core of the problem. Let’s flip it around and assume that the estimation process is the root cause of the issue. Let’s see where that assumption takes us.

Here is how the project manager determines the schedule:

1. Projects tasks are listed with dependencies and estimated. Estimate contains safety buffers. Basic human behaviour.
2. Buffers within each task extend the duration of tasks and in turn the entire project
3. If project duration is too long, senior management reduces the duration. Moreover, since customers cannot wait, multiple projects are started and are in progress simultaneously
4. Multitasking, variation in estimates and task dependencies, together with Parkinson’s Law and Student Syndrome, wreak havoc with task deadlines. Milestones may consistently be missed. If every milestone is hit consistently, it is logical to conclude that tasks have significant safety built into them.
5. Missed milestones cause angry customers. Number of missed milestones will ensure customers complain to senior management
6. “The squeakiest wheel gets the grease”. Customer who complain the loudest get the people to complete the job.
7. Expediting certain projects means other projects now get into trouble. The resource manager, of course, allocates people to address the “squeakiest wheel”. As the squeaks subside people are allocated to address other “squeakiest wheels”.
8. Project managers on delayed projects are now unhappy. They are measured on how good they are meeting scope on schedule and on budget. Now their project is going to be off schedule. S/he and respective customers try to squeak the loudest
9. Go to step 4
10. Somewhere along the way, someone realizes that there needs to be improvement. Additional controls and checks and balances are introduced in the name of improvement. This adds further delay to project schedules. The common refrain becomes, “We need to plan better.” However, fire-fighting never seems to end and there does not appear to be a way out.

This causes a lot of conflict and it is unnecessary. I read this somewhere, “If, despite best efforts there is no improvement, then we need to change the management system.” This is one of the hardest thing to change – convincing the senior management that there just might be another way out of the chaos.

Assuming, there is a senior management will to change, we are now placed with a quandary:

1. What to change
2. Change to what
3. How to effect that change

What to change

Let’s reiterate the problem:

The goal of the resource manager is to ensure the maximum utilization of each and every person reporting to him/her. The goal of the project manager is to ensure his/her project is completed on schedule, on budget and on scope.

The conflict arises due to the differences in the goals of the project and resource managers. If we eliminate the conflicting goals then the two roles can live in harmony. So let’s go about eliminating this conflicting goal.

Project managers use time to schedule tasks. This time is now communicated to the resource manager, who in-turn uses this time to allocate people. Both the project manager and the resource manager ignore the variation. Even if they account for variation, sometimes it is just way off the mark. So the question arises, what if we can change our projects from being “time based” to “work based”? Instead of focusing on time and saying, “you have 20 hours this week to work on project A”, we say “we have to complete these tasks in the listed order” as fast as we can.

A paradigm shift? Certainly. But just think – what if? Let’s take that train of thought further to see where it might lead us.

Change to what

We know the team needs to complete the work in some estimated time. We also know there is variation in that time. So instead of making people accountable for their estimates, why not make them accountable to work instead?

What if we introduce a policy like, “Do not start a new task unless an existing task is finished. Address bottlenecks as they arise to ensure speedy task completion.” What might the implications of such a policy be?

1. Focus now becomes how fast the task can be completed from “I have 10 days to complete the task”
2. Task are now small enough to reduce variability. It is common knowledge that longer the tasks, the more the uncertainty and hence more variation. Keeping tasks small enough will ensure less task variability and in turn ensure speedy completion.
3. Individuals are empowered to “stop the line” when bottlenecks are encountered
4. Work in progress is limited. Tasks complete faster due to improved focus.
5. Work is now scheduled based on flow rate
6. A pull system is now created
7. Team members have a sense of accomplishment as they check off completed tasks
8. Resource manager is going to happy since his team is now fully utilized
9. A culture of trust and customer focus will evolve

What are some of the challenges?

1. The project manager no longer can decide when tasks can start and end based on the Gantt. Paradigm shift.
2. The resource manager can no longer allocate people to projects since the people “pull” from a queue. Paradigm shift.
3. Senior management will now have to limit work in progress projects. BIG paradigm shift.
4. Slaughtering of a number of other local project management sacred cows. (Maybe time for a feast?)

So will this policy solve the resource and project manager’s dilemma? It could. By focusing on tasks the resource manager is now happy that the people in his/her team is now being utilized where it matters. By limiting work-in-progress projects, the project manager is now happy that people will focus on his project tasks to ensure speedy completion. Ah, a Win-Win situation!

How to effect the change

If we are committed to the policy change, how do we go about bringing about this change? Most people I meet say that they are visual people. A picture is worth a thousand words. What if we could:

1. See which stage all tasks are at all times?
2. See who is working on what tasks at any given point in time?
3. Predict how long it takes for a team to complete tasks?
4. See bottlenecks as they happen – and not after the fact?
5. Determine the flow rate of work through each team?

A visual board where project tasks/deliverables can be track would be great. What will make it awesome is if the visual board could tell me in what stage work is at all time. So a visual board is my first requirement.

The second requirement is that I should be able to calculate the flow rate of tasks completed by each team. This will require some work. Meet with your team and analyse how to categorize your work types – do not go overboard with the number of work types. I recommend “Just do its” and “Planned work”.

Now you can determine the flow rate of each work type for each team (work center) in your organization. (For a more detailed explanation about work centers, read Making Kanban work in matrix organizations.)

Flow rate or Cycle Time is calculated using Little’s Law. It is basically, the division of number of work-in-progress tasks (numerator) by the rate of completed work (denominator) within a certain time period.

Cycle Time = number of work-in-progress tasks/rate of completed work

The goal is to reduce the Cycle Time value. In order to do that, the numerator should be small while the denominator should be large. This means that in order to turn around work faster we need to limit work-in-progress.

Ah – a task work-in-progress limit. This is the third requirement. How do we communicate that? Of course use the visual board. So our visual board now tells us:

1. Where all work is and what stage each work is in
2. The limit of work-in-progress at each stage. (Instead of stages you could also look at introducing work in progress limits by team)

Guess what – this is now a Kanban used for software engineering.

So implementing a Kanban can help resolve one of the most thorniest issues between the resource manager and a project manager and create a harmonious win-win situation. In order to change behaviour you need to change policies. The question is, are you willing to modify your policies which act as a constraint to your processes and say, “Do not start new work until you complete existing work”?