11Horn Paper

7/31/2019 11Horn Paper

1/19

1

Evolut ion of

Port folio Management

in

CTS Clusters

Brian Horn

07/ 08/ 11

Version 3.5


2/19

2

1 Introduction ................................................................................................................. 32 CTS Business ............................................................................................................... 33 Case for Portfolio Management ................................................................................... 44 Evolution of Portfolio Management in CTS................................................................ 54.1 Establish ................................................................................................................... 54.1.1 Capture Project Labor .......................................................................................... 64.1.2 PMBOK ................................................................................................................ 64.1.3 PMBOK Lite ........................................................................................................ 74.2 Scale ......................................................................................................................... 84.2.1 Out ........................................................................................................................ 84.2.2 Up ......................................................................................................................... 94.2.3 Cross ................................................................................................................... 105 Areas for Improvement .............................................................................................. 105.1 Benefits Assessment .............................................................................................. 105.2 Cross Region and Sub-cluster Coordination selection, resourcing ..................... 105.3 Schedule Optimization ........................................................................................... 105.4 Enterprise Tools ..................................................................................................... 105.5 Project Management Rigor .................................................................................... 11Appendix A CSS Mission, Goals, and Strategies ........................................................ 12Appendix B Project Charter - PMBOK ....................................................................... 13Appendix C Project Charter PMBOK Lite ............................................................... 14Appendix D Project Charter Scale to other DS Sub-clusters .................................... 15Appendix E Sharepoint Site ........................................................................................ 16Appendix F Report by Subgroup ............................................................................. 17Appendix G Report Senior Management .................................................................. 18Appendix H Report cross region, cross cluster ......................................................... 19


3/19

3

1 IntroductionThis paper chronicles the evolution of portfolio management in a business group that

is primarily operations focused. Being operations focused tends to delegate projects toextracurricular type activities, often with little management. With a relatively smallpercentage of total group labor allocated for projects, it is imperative projects be selectedand managed optimally. The intent of the paper is to show how to establish and scaleproject management techniques in operations centric groups.

This paper will cover the following:

CTS Business Case for Portfolio Management Evolution of Portfolio Management in CTS Areas for Improvement

2 CTS BusinessGenerating around $60 B in annual revenue, Microsoft is one of the largest

corporations in the world. Microsoft is divided into several major Business Units (BUs).Numerous organizations like IT, HR, Finance, Microsoft Consulting Service (MCS), andCustomer Support Services (CSS) provide services to the BUs and their customers. .

Rigorous project management is utilized by the BUs. Gradually, formal projectmanagement methodologies are being adopted by other organizations based on theirunique needs. For example, MCS has created Project Management Offices (PMOs) foreach of its regions to push out common project management methodologies to theirorganization. CSS created a PMO in January 2005 to manage projects that impact of allproduct support, like support globalization and operations standardization. SeeAppendix A for more detail on CSS mission, goals, and strategies.

CSS is divided into two major units; Consumer Support and Commercial TechnicalSupport (CTS). CTS has over 3000 employees that provide enterprise level support.CTS is organized into clusters; Windows, Exchange, Dynamics, Office, and DeveloperSupport (DS). DS works with developers to create and deploy advanced applicationsusing Visual Studio languages, Internet Information Server (IIS), Internet Explorer (IE),and SQL Server database. As a developer oriented group, DS is in a unique position toidentify and work on projects.

DS SQL Server Database is a sub-cluster in DS. Around 10% of the CTS workforceis in this sub-cluster. Below is a diagram that depicts the workflow (operations) for DS

SQL Server Database. On a typical day, over a 100 new cases are created and routed to aFrontline (FL) Support Engineer (SE). Using processes specific to FL, around 70% ofthe cases are resolved in a timely manner, requiring no further escalation. The remaining30%, around 40 cases, require Escalation Services (ES) to either assist or own the case.ES is a more experienced group within DS SQL Server Database sub-cluster that worksdirectly with BUs on difficult issues. ES typically assists on 20 cases and owns another20 escalated cases a day. Out of the 20 cases escalated, 15% of them, around 3 cases,need BU Developer input through a formal Request for Comment (RFC).Approximately 1 RFC a day is promoted to a Request for Hotfix (RFH) resulting in a fixto address a product defect.


4/19

4

The daily routine of an engineer is to interact with customers (cases), FL, BUDevelopers, and other product support groups. An ES engineer typically works on 8-10cases at a time, spending an average of 6 hours on each case. ES cases last days, weeks,or sometimes even months. While working cases, ES engineers often identifydeficiencies in one of the following:

Content for customers to resolve their own issues Training material Supportability features in the product Product bugs

Supportability features are the biggest area for project work. As part of their job, ESengineers are expected to identify ways to improve troubleshooting. Many projectsinvolve developing utilities/tools to aid in the diagnosis and resolution of issues. Projectsalso include formal feedback to the BU on supportability enhancements for futureproduct versions.

3 Case for Portfolio ManagementIn the CSS mission, goals, and strategies in Appendix A, strategy 7 states leverage

expertise by innovating driving continuous improvement. In a group whoseprimary focus is operations, this is a difficult balancing act. It brings into question thedifferences between operations and projects. Operations are repeatable work thatproduces similar results. Operations are the core functions of a cluster. For DS SQLServer Database sub-cluster, operations are customer direct case work. In the past, caseswere created to do non- customer direct work. It was felt that this work was similar tocustomer direct work (cases) and could be managed the same way.


5/19

5

People tend to view projects from either a tactical or strategic point of view.

Tactically it is a temporary set of activities with a defined start and end, creating a uniqueoutput. It has scope, time, and cost objectives. From a strategic view, a project is oftendescribed abstractly like a vehicle for change, manifestation of strategy, or creation ofbusiness value. Because of this difference in view, success of a project is often describeddifferently. From a tactical view, success is achieved when the output (work) of theproject is complete while meeting the objectives of scope, time, and cost. From astrategic view, the expected outcome is considered achieved when the project

deliverables are adopted by the organization and ongoing business value is realized. InDS SQL Server Database sub-cluster, once it was realized that both views where inregards to a project, people were able to separate projects from operations in a moreconsistent manner.

After people in DS SQL Server Database sub-cluster recognized that projects weredifferent from ongoing operations, many still felt like there was not enough project workto warrant managing projects differently than operations. In order to build a case to adoptportfolio management processes, it was necessary to show how much project work wascurrently being done. To obtain this data, rudimentary project labor tracking was put inplace. Once in place, it was straight forward to show, see below, that project work

represents around 5% of all labor in the sub-cluster.

For DS SQL Server Database sub-cluster, 5% of labor represents around $1.5 Mannually. When expanded to include all of CTS, the cost approaches $15 M annually.Even in a company the size of Microsoft, millions of unmanaged costs raises concerns.

4 Evolution of Portfolio Management in CTSIn order to solidify portfolio management processes in CTS required establishing

proven methods in DS SQL Server Database sub-cluster and then scaling to other regionsand CTS clusters.

4.1 EstablishIn DS SQL Server Database sub-cluster, portfolio management processes were

rolled out in the following phases:


6/19

6

Capture project labor prove the need Implement PMBOK processes learn by doing Implement limited PMBOK processes adapt

4.1.1 Capture Project LaborPreparing for the start of fiscal year 2006, DSD ES engineers started recording

project labor. An existing labor recording tool, Hercules, was used. Engineers werealready using Hercules to capture labor outside of case work, thus little change for them.

Hercules had 4 main categories of labor:

Out of Office (OOF) vacation, sick, leave Training attended, developed, delivered Operational administrative (meetings, email), staff functions Product supportability, Beta

Hercules categories and subcategories were activity based. In order to associatethe activities with specific projects, the engineers were requested to use a special tag() in the comment of their labor log. The tag contained the project name. Theproject name entered by the engineer was a text field. To communicate the approved

projects and their tags, labor reporting instructions we documented on a wiki site.Training was rolled out to the teams.

In order to produce project labor reporting, access to the labor reporting backenddata was required. Custom queries were written to parse the description fields in thelabor entries. Because there was no validation of project account names used at the timeof entry, the backend reporting included a way to associate errant names with the properprojects.

This method of labor recording was far from ideal. It did allow the reporting ofprojects separately from operations, case work. Also, it used a method of labor

recording that was already familiar to the engineers.

4.1.2 PMBOKPreparing for the start of fiscal year 2007, formal portfolio management processes

were put in place. This coincided with me finishing a masters program in projectmanagement at the University of Texas at Dallas (UTD) and passing the PMI PMPexamination. During this phase, there was a heavy emphasis on PMBOK processes.Appendix B shows the Project Charter and instructions expected to be used whensubmitting a project proposal. The Project Charter is indicative of the overzealous useof PMBOK processes.

Fiscal Year 2007, turned out to be a learning year that position DS SQL ServerDatabase sub-cluster well for a more pragmatic implementation the following year. Oneof the surviving concepts was that of roles, see below.


7/19

7

I took on the role of Project Coordinator (PC), which I still do today. I workclosely with the members of the Project Advisory Committee (PAC). Each project has a

Project Lead (PL) responsible for the work of the project and a Project Supervisor (PS),typically the PLs direct report manager, who is responsible for scope, time, and costobjectives.

Note that the PAC does not judge the merits of the project, rather decides on thenormal working hours to invest on the project. It was clear from engineer feedback thatthey wanted the freedom to work on any project, even if it required working on themduring their off hours. Funded hours are those approved for normal working hours. APS can schedule someone away from operational work to consume funded hours in orderto hit a deadline. PLs are expected to submit all project work. If a project is unfunded,its status is still tracked, but not the off hours spent on them.

4.1.3 PMBOK LitePreparing for the start of fiscal year 2008, PMBOK heavy processes were lightened

up resulting in many processes that are still in use today. The project charter was furthersteam lined, see Appendix C.

The feedback from the previous phase was clear, project processes were toocomplicated. A simpler project submittal workflow was created, see below.


8/19

8

The workflow involves 3 roles Project Lead (PL), Project Coordinator (PC), andProject Advisory Committee (PAC). The PAC meetings are broken up into 2 halves.The first half focuses on approving new submittals and the 2nd half reviewing in-progressprojects.

4.2 ScaleOnce portfolio management processes were established in DSD ES, the processes

were scaled in phases as follows:

Out to other sub-clusters in DS Up to senior management in DS Cross to other geographic regions and other CTS clusters

4.2.1 OutPreparing for the start of fiscal year 2009, what began in the DS SQL Server

Database sub-cluster was scaled out to the other sub-clusters in the DS cluster. Thisrequired some compromise resulting in a new Project Charter, see Appendix D. A newSharepoint site was created, see Appendix E. A major change was incorporatingmultiple PACs, a different PAC for each sub-cluster. This allows decisions aboutprojects to stay close to those that understand the specific technologies.

In early 2009, a new case tracking tool was introduced. It is a CSS developedtool. This provides the flexibility to conveniently add new functionality. A request wasmade to the development team to include project labor logging. This feature was added


9/19

9

later in the year. The new feature allows associating a unique identifier, Work Item,with a project. To log labor for a project, the engineer simply enters the Work Itemnumber, date, and a brief description of the work done. Once the PAC approves theproject for funding, the PC creates a new Work Item through case tracking tool anddocuments it to the Project Charter, referred to as Funding ID.

Another significant change when scaling out to other DS sub-clusters was thestandardizing on project categories, see below. Projects are categorized by the PL whensubmitting the project. The following are the high level categories:

Content Supportability Market Share Enablement

Each sub-cluster is given a budget for the year for each category of projects.Backend reporting was updated to show how a sub-cluster is tracking against eachcategory of projects.

Also added was the association of projects with a Project Group. Typically, afterreviewing the Project Charter, the PC associates the project with a specific Project Group.Backend reporting was expanded to include a Project Group view. This allows forfocusing on a narrow group of projects. Project Groups are typically another level ofbelow sub-clusters that are specific to each sub-cluster. See Appendix F for an exampleof a Project Group report.

4.2.2 UpWithin months of all sub-clusters in DS using the same portfolio management

processes, DS senior management started including project spend reports in their SeniorManagement Scorecard reports, see Appendix G. The report includes the top spendproject in each sub-cluster grouped by project category. The report also includesexpected impact, but this is an area that needs improvement and is discussed further inthe next section.


10/19

10

4.2.3 CrossStarting in late fiscal 2010, other DS geographical regions and other CTS clusters

were added. To accommodate this change, a Region field was added to the ProjectCharter and reporting. To accommodate other clusters, more PAC menu options wereadded, see Appendix H how reporting was modified.

Once scaling out to other DS sub-clusters was completed, scaling out to other CTSclusters was easy from a tools standpoint. With DS cluster as a reference point, other

clusters quickly adopted the proven processes, labor reporting, and reporting.

5 Areas for ImprovementConsidering that many in CTS use to think they didnt work on projects, great strides

have been made in portfolio management over the last 5 years. But, there is still more tobe done. As we begin the new fiscal year, the following areas have been identified forimprovement:

Benefits assessment Cross region and sub-cluster coordination Schedule optimization Enterprise tools Project management rigor

5.1 Benefits AssessmentSeveral attempts have been made to quantify expected benefits from doing a

project. The first attempt resulted in a Priority based on 9 factors, each rated from 0 to 5.Second attempt resulted in an Impact score from 1 to 5 based on the same 9 factors fromthe first attempt. The preferred way to quantify expected benefits is a financial ROI.With labor reporting in place, the denominator of the ROI calculation is straight forward

to determine. But, the numerator, return, is still elusive.

5.2 Cross Region and Sub-cluster Coordination selection, resourcingThe PACs have done a reasonable job of selecting and resourcing projects from

their respective region and sub-clusters. But, with each region and cluster actingindependently, there continues to be redundancies and inefficiencies. Resourcing aproject cross region and sub-clusters is very attractive, but will require a level ofcoordination that is not yet feasible.

5.3

Schedule Optimization

Many times projects are accepted on their own merit without much regard toschedule impact on operations and other projects. There is work to be done in the area ofcross project schedule optimization.

5.4 Enterprise ToolsIn 2008, Project Server 2007 was looked at as a single tool for portfolio

management, see below. It was decided it would likely require too much training for an


11/19

11

operations group that spends relatively little labor doing project work. Also, there wereconcerns about the tool shaping our processes, limiting our flexibility to tailor processesto our specific needs. Reporting was a concern as well. We decided to use Sharepointand Excel. As CTS becomes increasingly sophisticated in managing projects, thisdecision will need to be revisited.

5.5 Project Management RigorAs more complex projects are undertaken, the need for more rigorous project

management processes is needed. If it is decided to move to Enterprise Project Server,then it will make sense to have an end to end solution from project selection tomanagement of individual projects.


12/19

12

Appendix A CSS Mission, Goals, and Strategies


13/19

13

Appendix B Project Charter - PMBOK


14/19

14

Appendix C Project Charter PMBOK Lite


15/19

15

Appendix D Project Charter Scale to other DS Sub-clusters


16/19

16

Appendix E Sharepoint Site


17/19

17

Appendix F Report by Subgroup


18/19

18

Appendix G Report Senior Management


19/19

19

Appendix H Report cross region, cross cluster

11Horn Paper

Documents

Transcript of 11Horn Paper