“Any goal can be achieved if a strategy is properly executed.” – Nitin Namdeo
Execution excellence as a one-person band is one thing. Execution excellence for a team or group or organization is another level entirely.
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.
On the Microsoft patterns & practices team, 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.
All Up Summary View
Here is an all up summary view:
You Might Also Like
7 Habits of Highly Effective Program Managers
10 Success Patterns for Program Managers
Cuttable Scope
How To Lead High-Performance Teams the Agile Way
Kanban for High-Performance Teams
Lessons Learned in Project Execution
Program Management Books
Your New Technical Skills for High-Performance
What is a Program Manager?
Hey JD – This post is super helpful and I keep coming back to it.
Question:
* Can you explain more about (depicted in the picture) Portfolio Scenario Backlog?
* How would you all use scenarios in this context?
* What are the rituals and frequency where the “programs” (in the picture) get converted to projects?
Very grateful again for everything you write
Thank you! I keep coming back to it, too.
I finally fixed the image (the old one was super blurry).
IN our group at the time, we used scenario loosely.
It was more like Initiative or Epic.
So imagine a list of initiatives or epics that would be the backbone of a program.
We would keep things high level at the portfolio and roadmap level.
Imagine “Rolling Wave Planning” from high level details to lower level as we got closer to implementation.
In our projects, we would unpack the Initiative or Epic into the more atomic user and system stories.
We used programs to make doing projects easier.
So we would do a heavier Vision Scope at the program level.
Then smaller vision scope for each project.
Projects could wildly vary in size from months to years.
The early days were multi year projects.
In later days, we shifted more to month and 3 month projects
And then version more.
So v2 versus a long project.
This is one of those gems that if I didn’t write down it would be hard to recreate it.
It’s ironic how with so much information abundance, we still have a gap in wisdom and knowledge.