Can work planning be delegated down to teams—or even team members? This video addresses the pros and cons of this recent trendy idea, as used in agile/scrum.
- In the manifesto for Agile project management, which is very trendy at the moment, they recommend self-organizing teams. The general approach with Agile is to simplify problems down by making them into small autonomous groups, and to work on small collections of short tasks, so that people can solve their own problems, and you don't need complicated centralized planning. And I partly agree with this. I've been suggesting throughout this course that you can't feed everything into a computer and get the right answer.
The computer will never know everything and the problem just gets too complicated. So I'd rather have a simplified central plan using something like Excel, based on a relatively simple Gantt of Gantts. And then keep most of the planning at project level using Gantt charts. So I do like the idea of keeping things simple and visual. And I also like the motivational idea of letting the teams be empowered to run their own areas. However, I do think you need some centralized planning.
And I think if you leave all of the resource planning to the individual project teams, you'll get some problems for the following four reasons. Number one, you will inevitably have some people who are in several teams, or who joined teams and then leave them again later in the project. It makes it hard for the teams to plan everything. Number two, the teams don't know the overall picture. If their project is part of an overall program and their delivery date affects other projects, then they need to know that.
In fact, their decisions could also affect the resource availability for other projects. For example, I mentioned earlier that you might have a number of projects all wanting to use a laboratory and this could hold up some of the projects if it's not carefully planned between them all. So each self-organizing team will need to talk to all the other teams about that, which is of course possible, but quite messy, and I think instead ideally you'd have a centrally produced Gantt of Gantts for that key resource so that everyone could see the best plan.
Number three is that the teams will optimize for themselves and that doesn't necessarily mean optimizing for the whole program or for the organization. It may be cheaper for them to take a bit longer over a task without realizing that it will hold up another project. Or it may be easier for them to use two people rather than to use one and a half and lend a person part-time to another project. Asking each team to optimize what they're doing is simpler and it requires almost no management time, but it won't necessarily give you the best plan overall.
Number four is that the program manager needs to know what's happening. For example, is one project running slightly late, so it's going to affect the project that will follow? And in order to know this, there has to be a plan which we then know isn't being achieved. If you have pure self-organizing teams, then you probably don't have a plan. They're improvising as they go along. So you won't know there's a problem until nearly at the end when the finishing line is in sight and they can see that they aren't going to reach it.
And by then it's very expensive or impossible to catch back up. So I think you still need a program manager, however you organize the teams in your projects. And what you're really saying with so-called self-organizing teams is that you let them make the small decisions within the framework that you've already decided. If you don't have the framework, either planned top downwards or bottom up, then you have anarchy and you'll never keep your program promises to your stakeholders.
Even with self-organizing teams, you need the program manager to be a sort of all-seeing brain, to allocate the people to the teams to start with, and to decide how long a person is able to stay with that team, and when the team has to deliver the project by. And even if you allow the team to come up with a forecast completion date, then the all-seeing brain has to decide whether that date's going to affect the other projects adversely. To what extent do you think you could divide your program or project down into self-organizing teams? Which decisions do you think you could leave to them? And which ones would still need to be made, or at least monitored by you? And how are you going to draw up and then monitor an overall plan for the program, but still give the teams the feeling that they have ownership and a degree of control over their own areas?
- What is program management?
- Planning from the bottom up vs. top down
- Resource planning
- Managing projects, resources, and time
- Getting the staff you need
- Self-organizing teams