Doing a substantial amount of program management as part of the Visual Studio ALM Rangers “virtual” team ecosystem, which we outlined in Visual Studio ALM Rangers – Reflections on Virtual Teams, I decided to attend a”Program Management” course. It was probably the best decision and investment in time I have made for a long time, because I believe that I have a better grasp of the “PM” world, lots of new questions and ideas for the future.
What is evident is that PM != PM!
Do you not love the world of acronyms? If you are puzzled, the let me elaborate: PM = Program Management and PM = Project Manager, which implies that a MSFT Program Manager != Project Manager! Not again … MSFT = Microsoft.
The one day course was mind numbing, because at the end I had so many threads running amok trying to find answers to many questions and ideas. So much so, that I revised my commitments and have decided to start a discussion thread on my blog.
If you are considering a MSFT Program Manager role, you must read Zen of PM, you must attend the Program Management course as early as possible (not 2.5 years later like I) and you must find a mentor who can guide you through the seemingly complex, often challenging, definitely crucial and challenging world of a PM.,
7 Models of a PM
I identified seven models or core responsibilities of a Program Manager within the Rangers ecosystem, shown as seven balls being juggled by the robotic PM below”, listed in “my” perceived order of importance:
The Program Manager:
- … is a bridge between the customers/community/partners and the product group. On the one hand a PM is in touch with the users and comfortable with the in-the-field realities, while on the other hand a PM is technically competent and knowledgeable of the technology designs.
- … leads and is not a manager, chief, captain, boss or dictator. I would compare a program manager with an artist or an architect, that leads, motivate and energizes teams of people to create a work of art.
- … is responsible for and is passionate about “shipping” solutions, that result in happy users.
- … orchestrates teams, bringing a variety of skills, personalities and (hidden) agendas under one “team” roof, and leading by adding value.
- … leverages, not manages, resources, balancing ambition, creativity and realism, and most importantly takes care of any impediments that may impact the team. Similarities with a Scrum and Ruck master started bubbling up … but I need to give this thread more thought before making further comments 🙂
- … enables the B-X-T perspective, which confused me for a long time in the course … until yet another TLA (three lettered acronym was explained). BY enabling the B-X-T perspectives, the program manager ensure that there is Business Value, Good EXperience and that the solution is Technically OK.
- … enables Integrated Solutions … which could very well be number one on this list, as this is one of the core reasons this role evolved at Microsoft. With the Rangers we often focused on specialised solutions, but with the latest “Gig” (Understanding our Visual Studio 11 Readiness conspiracy) we are not only working on integrated readiness, but working with integrated solutions spanning Team Foundation Server , Visual Studio and other technologies. As the bridge, the advocate and the voice of reason, the program manager is the perfect champion to orchestrate, leverage and enable teams working on solutions that integrate with other solutions.
What should be evident by now is that Program Management has very little in common with the Project Manager, so it is true that PM != PM. There is a small part of project management that a program manager is responsible for, but it is typically a very small (minute) role.
There will be more posts on this topic, but I would appreciate YOUR thoughts and feedback!