This video looks at the key issues, including multiple stakeholders, projects which are partly in your portfolio and partly in someone else’s, deriving a programme work breakdown structure, cost quality and time, and saying no to an impossible mix of all of them. It also covers constant change and charging for changes, and getting everything in writing.
- In many ways, program management is almost the same as project management, only bigger. But, I think there are five areas where they actually are significantly different. So let's have a look at those. First, is the fact that programs often go on for years. They sometimes don't even have a finish date, whereas projects always do. To use a real example that I've been involved in, making the large British city of Bristol more environmentally friendly is never going to end.
There will always be new things coming along to make Bristol even better. Each new thing is a project with a start and a finish, but the overall program might not have an end. Next, is the problem of multiple stakeholders. In the case of programs, the stakeholders are bigger, and there's a lot more at stake, and whereas a project manager can call a kickoff meeting and sit back and say, "I'm not starting "until you can all agree about what it is you want." The program manager has a constant problem of shifting priorities as new projects get added and new stakeholders get involved.
And, the program manager has to be much more active in steering the program through the minefield of unhappy stakeholders. Not just potentially unhappy but inevitably unhappy. You'll never please all the people all the time. This annoying political dimension is much more important in program management than it is in project management. Linked to this is the fact that the inevitable juggling of cost, quality, and time at the start is bad enough within a project, but in a program you're juggling the cost of all the projects, and the timing of all the projects.
And also, the cost of one against the quality of another, or the quality of one against the time of another. We can get the building modified and ready for production quicker if we saved money on the marketing campaign for the new product. Or, if we want the new building to be really good, then the IT upgrade will have to wait until later in the year. You can imagine how tricky that can get. Third is the fact that edges of a program can be more difficult to define than the edges of a project.
I'll explain what I mean. At the start of a project, the first thing you do is decide what's in scope, and what's out of scope, and those lines stay drawn. If they want to include something extra, then you can demand extra time and extra money for it. But in a program, there might be projects that are in your program, but also in someone else's. That new bridge is in your traffic management program, but it might also be in the technical infastructure program and also in the environmental improvement program.
You're not just borrowing people for your project, but you're borrowing whole project managers and whole projects for your program. Fourth, is that the complexity of managing programs is a whole league more difficult. You can try and keep it simple by dividing them down into projects and parceling out each one of those to someone good. But as we've seen, some of the projects depend on others, sometimes just one or two tasks deep down within one project depend on some of the tasks in another project and even more horribly, the resources are usually massively connected.
The cube of resources, projects, and time is very tricky to manage. If you need some extra people for a project, you can get them from somewhere, usually another project, but if you need extra people for a program, then, where will they come from? And if you buy them in, then the money required is going to be much larger, probably too large to the point where it's impossible to get. Resource planning is much more of an issue for programs than it is for projects.
Finally, there's the documentation of changes during the program, which is important during projects but is even more important during programs. As things change within your program, perhaps new projects are added to it, or requirements within its projects change, there will be effects on the various other projects within it. Their costs, their timings, and their quality, can all change and every time, this needs to be agreed and documented, so that everyone knows where we are, and so that nobody can say to their program manager, "You failed to deliver what you promised.
"That part of the program was late, "or was over budget, or wasn't as good as I expected." So, we've got open endedness, multiple stakeholders, unclear edges, complexity of planning, and documentation of changes. All of these are kind of issues for project managers, but for the program manager, they're infinitely more important and more difficult. But don't worry, this course is here to help you, and also, it's worth it.
If you're a program manager, you can really make a difference to a lot of people's lives and you'll never be bored. Do you think this is the case for the programs you're involved in? Would you agree that all of these are important and difficult issues? We'll be coming back to all of them during this course and I'll be showing you techniques that will help you to navigate through this difficult minefield.
- 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