So now you have gone through the process of defining your business domain, the key drivers of your business, a list of viable ideas that line up with your strategy, selected and prioritized a bunch of them and wrote a business case for one major idea detailing why it would be beneficial to implement it. Now what?
The next step would be to create the program charter. I say program charter rather than project charter for a reason. Program charter should be your default choice rather than a project charter. A project focuses on delivering a specific product. A program is focused on delivering a capability and associated benefits. In most cases, if not in all, delivering a capability usually involves several interconnected projects hence the need for a program. Let me give you an example.
Let’s say that your organization has grown over the last few years and along with it your information technology infrastructure. You have now gotten to the point where you really need to consider a comprehensive disaster recovery capability. Your day to day business is heavily reliant on the IT department and if any major issue occurs in that area that interrupts your business activities, it could cost the organization significantly. So everyone has agreed that having a comprehensive disaster recovery capability is an extremely good idea. The business case has been written and the benefits and payoffs have been analyzed and documented. So what’s the issue? Why not go ahead and just create that disaster recovery capability?
The problem is that treating the creation of a disaster recovery capability as if it were one item is like trying to eat an elephant in one bite. It is too big and complex a capability to deliver in one go. Better to break it down into small chunks. The smaller chunks will be easier to manage. You will have different teams working on them therefore spreading your resources more evenly and also be able to accommodate regular non-project operational work. You may be able to hire outside consultants and vendors who are specialized in each chunk. For instance vendors who specialized in network uptime may not have the same expertise as application capacity planning experts for one of your major applications. There are also supporting services that are not entirely IT but are interlinked with them. So for example some processing capability which is normally performed by the IT system may have to be moved to manual processing during a disaster. For that capability you will need to provide training on switching staff to manual processing.
There are other considerations as well. A disaster recovery capability might mean having to build an external location physically away from the main office but which mirrors the systems in the main office. In the case of say, a major fire at head office, the satellite office can be started up and used to continue business activity. That means a project is required to build and equip an external office. This would require different types of human resources and activities not just IT.
So you can see that a capability for something like disaster recovery can spawn many projects all of them interconnected and all leading towards one main capability. One of the program manager’s duties would be to ensure that all the deliverables of the projects are integrated correctly and transitioned to operations properly. So while each project will focus on an individual deliverable for that project, each one of those projects provides a piece of the bigger program deliverable which is the required overall capability.
Program management is very effective in this area. Program management is about delivering capabilities, benefits and managing inter-project risks and constraints. The integration of the projects to enable the capability and the benefits associated with it is the key deliverable of the program.
So in a nutshell, after a business case for an idea is completed and approved, the next step is to think whether it should be delivered through a program or a project. By default you should think of a program because it is always easier and more efficient to break down a large problem into smaller chunks. However if the idea is small and the deliverable is an obvious product or service, then a project will do and there would be no need and little gained from over complicating things.
Hope you found this useful.