I have the fortunate opportunity to manage the Enterprise Platform portfolio for Microsoft IT and thought that I’d share some tidbits how I do it.

In Microsoft IT, the Enterprise Platform Portfolio (EPP) is only one program portfolio peer to other program portfolios like our Line-of-Business (LoB) specific portfolios such as Sales, Marketing, Services, HR, Legal, IT (yes, even IT is a LoB to us), etc. The EPP is a portfolio designed to manage our platform systems and encourage them to deliver more value to the company.

I’ve distilled the EPP’s Charter (aka Team Model, Process Model and Delivery Approach) into the following points to help articulate how I manage the EPP:

1. Fund Platforms only. It seems simple enough, but defining what is a Platform and what isn’t like Application, Vendor Products, Processes, Capabilities, Locations, etc can be a bit tricky. We pulled our definitions from our Enterprise Information Model and elaborated on them to help communicate what qualifies for funding from the EPP and what doesn’t. We use a couple of views, one that is more loose and one more explicit to help communicate to different audiences. Here are a couple of diagrams that we use:

   Architecturally-pure Platform Diagram	Exec-ready Platform Diagram

   • An Enterprise Platform is a set of Components where one or more of those Components are used by more than one Application. More than one Line of Business uses these Applications.

   • An Enterprise Platform may master a Data Facet.

2. Fund non-discretionary costs first, then allocate the remaining budget based on criteria intentionally used for the Platform to deliver business value. Here is our prioritization criteria as a reference:

   Business Alignment
   	Relation to Goal Prioritization	Does the Platform relate to highest priority Business Goals?
   	Capability Assessment	Does the Platform relate to priority Business Capabilities Assessment (Value, Performance and Maturity)
   	Business on-boarding Commitment	Can the Platform demonstrate commitment from multiple businesses?
   Portfolio Simplification
   	# of Redundant Apps and Plats	• Will the Platform reduce redundant Applications/Platforms? • Will the Platform retire similar functioning Applications/Platforms slated for retirement?
   	Retirement of Unsupported Vendor Products	Will the Platform retire the use of unsupported vendor products?
   Platform Excellence
   	Information Quality	Will the Platform improve information quality; make information more accurate and available?
   	Regulatory Compliance	Will the Platform help Microsoft comply with Regulatory Compliance?
   	Security and Privacy Policy Alignment	Does the Platform comply with Security and Privacy Policies?
   	Agility	Flexibility, Maintainability • Flexibility to support many Business Processes • Self-service

3. Solicit senior Architects to form a role-based Team Model. I’ve created a Team Model with 5 voting members filled by Microsoft IT’s most senior Architects. Each advocate 5 different perspectives of our Platforms investments; Business Advocate, Enterprise Architecture Advocate, Technology Use and Incubation Advocate, Platform Software Quality Advocate, Operations Advocate. It’s important not to make this team model reflective of the organizational team model but rather a set of perspectives of a platform. This avoids the situation of having organizational-bias in the voting and commentary of Programs in the Portfolio.
4. Platform Roadmaps. We use Platform Roadmaps to document what the Platform will do. The entities on a Platform Roadmap mirror the information in our Prioritization Criteria. That is, a Platform Roadmap includes all associated Business Goals related to the Program affecting the Platform, Business Capabilities and Process Flows improved, Applications and Platforms that will be retired as a result of the Platform, supporting Vendor Products, etc. We equate Platform Roadmaps to a sort of contract or agreement that the Program must adhere to. During the Program’s delivery, we run current Program information and compare it to the Roadmap to determine we the Program is on-plan or not. From the EPP’s perspective, the Platform Roadmap is the scope of the Program.
5. Enterprise Architecture to manage the EPP. Managing the EPP is the responsibility of our Enterprise Architecture team. This is important because the Platforms are an enterprise concern and require skills plus organization position to perform the necessary analysis to optimize our platform portfolio. For example, we perform analysis to form our Platform Strategy that includes cross-LoB needs analysis, associations to our enterprise data facets, application and platform consolidation methods, vendor products analysis to optimize our licensing and support contracts. Also, being positioned outside of the typical IT value chain (LoB-facing resources, engineering/development, and support) allows us to easily traverse the organization and remove organizational bias.
6. Data-driven funding allocation process flow to balance the portfolio. I’ve put together a relatively simple funding allocation process flow which allocates funding to Programs via decision points. For example, if a Program is in-flight, we allocate funds to ensure its original scope is delivered. If a Program requires funding to become compliant, we allocate compliance funds. One thing that we do to help spread the funds so that we don’t find ourselves shoveling all our available funds into one or two programs is utilize the concept of ‘seed’ funding. Seed funding is a limited amount of funds to allow a team to prove themselves per our Prioritization Criteria listed above. In our situation, we have some platforms that veer off-plan, therefore, score low on our Prioritization Criteria. In these situations, we limit funding to simply allocating non-discretionary funding and then seed fund them to get them back on track. This allows us to spread the funds further and fund new Programs and course-correct existing Platforms. Our customers perceive this as IT being more agile to changing business needs. For our funding allocation process flow to work, we must make the decisions data-driven to remove opinion and bias as much as possible. This is where my senior architects come into play. That is, they vote Y/N on each Prioritization Criteria for each Program. Those that rank higher are pushed through the funding allocation process first. We iterate through the funding allocation process flow until all available budget is allocated. Then draw the line leaving us with a list of which Programs are funded, what scope is being funded.
7. Continuously invest in Portfolio Management maturity. There are always improvements to ensure the platform portfolio is managed to deliver the most business value possible. The more mature the portfolio management, the more business value realized. Capabilities such as:
   • Portfolio Optimization in terms of
     • Program Dependency Analysis to understand when Programs can be hydrated to optimize resource allocation.
     • Program Overlaps and suggestions for what should happen to them.
     • Platform Strategy to understand where we want Platforms to go directionally and how to get there via promotion of Applications, retirement of Applications and Platforms, etc
     • Program Gaps to be filled as a results of analysis of Business Strategy
   • Strengthening the Portfolio Management Team to sit on funded Program Teams to guide and ensure delivery to stated Platform Roadmaps
   • General continuous improvement

I’m curious to learn what others do to manage platforms. Please share your thoughts if you have a moment.