Portfolios, Programs, and Projects
Note: This article is updated at Portfolios, Programs, and Projects.
Execution excellence as a one-man band is one thing. Execution excellence for a team or group is another.
One of the best ways to improve execution excellence for a team or group is to map out the portfolio, programs, and projects.
Having clarity on the portfolio, programs, and projects is a starting point for mastering execution.
In patterns & practices, what we did is create a visual roadmap to share the big ticket items. This helped set expectations with stakeholders in terms of what would ship when. It also helped build awareness for our internal teams to improve coordination and alignment.
The Portfolio
We managed our portfolio in a very simple way. We simply kept a backlog of projects and initiatives grouped by themes and programs. At this level, we would do two key things:
- Prioritize the projects against demand and commitments. This would inform our roadmap.
- Estimate the size of the project with T-Shirt sizing and do ballpark estimates of people, time, and budget.
In general, we could manage budgets and resources at the program level, as program level investments. This helped simplify planning.
The Programs
We used programs as organizing themes to group related projects, streamline planning, and simplify communication. For example, in patterns & practices, we organized our projects into the following programs:
- Client – We used this program to organize and plan our rich desktop and Web application projects.
- Engineering Practices – We used this program to organize and plan any security, performance, team development, and application architecture projects.
- Enterprise Library– We used this program to organize and plan our full Enterprise Library releases, as well as any sustained engineering, and any “Application Blocks.”
- Mobile – We used this program to organize our projects related to mobile phone scenarios.
- Web Services – We used this program to organize and plan any of our SOA and Web Services projects.
By having a backlog of programs and projects, we could establish our “cut line.” The “cut line” was the line where we’d need more resources and budget in order to execute. This made it easier to both share what we were working on, as well as push back on demands that exceeded our capacity. It also facilitated discussions with stakeholders in terms of priorities. The impact of prioritizing one project over another made it very easy to see the impact in terms of the Roadmap or what would be pushed below the cut line.
At the program level, we could use high-level user stories and scenarios to get a sense of the size and scope of key projects. We kept the scenarios high-level so that it was easy to tell the story and paint a quick picture of why the particular project, program, or initiative was important, in a way that stakeholders could relate to.
The Projects
At the project level, we got way more specific. At the project level, we had to get clarity on the demand and the scope. To do so, we would map out the user stories. The user stories were collected and prioritized with customers and stakeholders. The user stories were important because they created a very specific way to scope the project. They also helped see what skills and experience were crucial to project success. They also created a way to cut scope at a more atomic level. They also created a way to flow incremental value throughout the project life cycle.
As you can imagine, when you have clarity on your portfolio, both in terms of a backlog of programs and projects, as well as expressed as roadmap, and you have clarity on your programs in terms of big bucket investments and themes of work, and you have clarity on your projects, in terms of priorities as well as the actual user demand and how the projects relate to one another, you are moving up the stack in terms of execution excellence, organizational maturity, and most of all, simplicity.