How many software development groups have a separate Project Management Office (PMO)? What are the pros and cons? March 2012

(1)

How many software development groups have a separate Project

Management Office (PMO)? What are the pros and cons?

March 2012

Scope of this Report

For this month’s report, we are assuming that the question refers to just two models for the management of software development projects:



The “Line Management” (LM) model;



The “Project Management Office” (PMO) model.

We also assume that we must consider if, and how, these two models might be used differently in the face of different Software Development Life Cycle (SDLC) models. For simplicity, we assume only that two SDLC’s will adequately cover the range of all SDLCs for the purpose of this report: Waterfall and agile. We suggest that other SDLCs such as iterative (or spiral) can be considered as fitting on a spectrum between waterfall and agile for the purposes of this report. For similar reasons of simplicity, we are assuming that the agile SDLC in use is SCRUM. We assume that readers of this report are broadly familiar with these SDLCs so It is outside of the scope of this report to describe these them beyond those characteristics which are relevant to the question at hand.

We assume that for “small” software development groups or organizations, the use of a PMO is not an option. However, this does beg the question of how we can define “small” in this context and so we have included a section on this topic.

Typical Characteristics of the Line Management (LM) Model

 The project team consists of individuals who are members of functional groups whose line managers are responsible and accountable for the delivery of and reporting on their respective functions within the project.

 The line managers all ultimately report to one manager who has overall responsibility and accountable for the success of the project.

 Depending on the size and mixture of the project team, the “ultimately responsible and accountable” manager can be quite high up the management tree.

(2)

Typical Characteristics of the Project Management Office (PMO) Model

 The Project Manager (PM) of software development projects is an individual who is a member of a separate PMO group.

 The PM does not have line management responsibilities for the members of the project team.

 The PM is accountable for the delivery of and reporting on the project as a whole.

 The PMI PMBOK® Guide has a detailed definition for the PMO but the following are key points which typically differentiate the PMO model from the line management model. Note that functions and responsibilities which would be typical for line management are described in the PMBOK® Guide as being somewhat exceptional or at one extreme of a spectrum:

o “The PMO can operate on a continuum, from providing project management support functions in the form of training, software, standardized policies, and procedures, to actual direct management and responsibility for achieving the projects objective.” o “A specific PMO can receive delegated authority to act as an integral stakeholder abd a

key decision maker during the initiation stage of each project, can have the authority to make recommendations, o can terminate projects to keep the business objectives consistent.

o “In addition the PMO can be involved in the selection, management , and redeployment, if necessary, of shared project personnel …”

When is a software development group too “small” for a PMO?

In most cases, the following characteristics of the software development group would make it “too small” to derive value from a PMO:

 When the concurrent projects being developed are too few and/or too small to justify the effort of less than two FTE project managers.

 “Too few” and/or “too small” in this context probably means that less than about the total number of FTEs on software development teams is less than about 30-35 (In agile SDLC terms, this represents about four teams of 7-9 people).

 Another definition that we have seen at one of our clients is a separation between “projects” that require the participation of the PMO and “tasks” that do not. A task is defined as being less than 100 hours of effort. Of course, significant gaming occurs at the boundary but the impact is generally not too negative ( our client thinks of the avoidance of PMO involvement as an incentive to small development teams to complete smaller tasks within the 100 hour gate).

A “Survey”

Good data on the first part of this month’s question – the number of software development groups using a PMO - is scarce. Fortunately, we were able to take advantage of a team of DCG consultants attending the SEI’s SEPG 2012 Conference in Albuquerque, NM, USA – an annual convention for CMMI experts and novices. The DCG consultants used this timely opportunity to perform a highly unscientific and statistically unjustifiable survey of attendees who either marked a notice on the conference notice board or responded to a simple question during conversations about other things. With this survey sample set of process-oriented people from, presumably, process-oriented, larger software

development companies, we expected our informal survey results would show a natural bias towards more use of the PMO model than would exist in a random survey sample.

(3)

The results of our informal survey showed that roughly the same number or slightly more software development groups use the LM model as use the PMO model. Given our hypothesis of a natural bias, our projection from the informal survey was that, generally, slightly more software development groups use the LM model than use the PMO model.

Another insight that might be drawn from our informal survey is that there is no evidence that highly process-oriented individuals/organizations believe that one model of the other is necessary for mature software development.

A report from PM Solutions of Glen Mills, PA, “The State of the PMO 2012,” gives somewhat

contradictory information stating that, “Most companies have a PMO (87%). Of the few that don’t, 40% are looking to implement one within a year. Biggest growth by far is in small firms — 73% now have PMOs compared to 48% in 2010.“ However, this data includes all types of PMOs: Business, IT and software development. The report suggests but does not specify that much of its data is more related to business PMOs. Even within the report there are contradictory indicators. For example, “In looking at changes in the PMO landscape since the 2010 survey, we see evidence of PMO leaders’ response to prolonged economic stagnation. Across the board, PMOs have scaled back on their functions, except in those areas that will allow them to measure and demonstrate business value.”

In a paper entitled, “To PMO or not to PMO, that is the question!” presented at a PMI conference on 2009, Seweryn Spalek admits that a great number of project management offices (PMOs) fail and that executives have long debated the value of investing in PMOs. However, the paper describes how

organizations can effectively launch and efficiently operate a PMO. In doing so, it overviews a case study showing how one organization established and operated its PMO, noting the key advantages the

company realized via its PMO.

One final data point: According to an article on social media and job titles in the March 10, 2012 edition of The Economist, the popularity of the job title, “Project Manager” as a term of self-description on LinkedIn fell by about 5% between 2007 and 2011

(4)

Pros and Cons of PMO (versus LM) for “large enough” software

development operations

Pros Cons

Waterfall  Having a single PM focused on project success facilitates

communication between (sometimes competing) functional teams

 To some extent, the waterfall model works through clear task separation which tends to disassociate the functional teams from the overall success of the project. A PM can help with this.

 For complex projects, the planning and estimating of the whole project requires specialist skills which a PM is more likely to have than a developer.

 In the LM model, line managers are often promoted to positions of accountability because of their functional or people skills not

necessarily their project management skills

 The PM needs to be strong enough to win battles for resources amongst functional heads especially if their bonuses depend on different criteria

 There may be a tendency for weak PMs to conceal bad news about project status if they feel it reflects badly on them and they can “fix it soon.” The tensions between functional teams may tend to drive bad news to the surface quicker if they are dependent of deliverables from elsewhere in the team.

 Line managers may have individual motivation tools such as annual reviews, salary increases, bonuses, training etc. that are not available to PMs.

Agile  The skills of a PM are invaluable in managing multiple SCRUM teams (“scrum of scrums”) or mixed scrum and waterfall teams in parallel

 Where agile teams have

dependencies on other project teams (agile or waterfall) for deliverables, the PM can be very beneficial in planning these deliverables and re-planning them when things change.

 The PM can provide a status reporting framework that meets corporate information requirements without compromising the agile principles of the project teams (too much).

 There is an overlap between the role of scrummaster and the role of a PM in a typical waterfall project. If this tension is not resolved early, it can have a negative impact on the project teams.

 Where agile teams consider themselves to be managed” rather than “self-organized,” PM’s may face considerable resistance and cannot succeed without strong line management support.

(5)

Conclusions

Generally, slightly more software development groups use the LM model than use the PMO model. Highly process-oriented individuals/organizations believe that one model of the other is necessary for mature software development.

The skills and objectivity of PMOs are valuable where projects are complex involving more than simple dependencies between team deliverables. PMOs provide objectivity on projects at the expense of some overhead and the loss of the motivational link between project team member and line manager.

Successful implementation of PMOs requires strong support for PMs from line managers.

Sources:

1.

“The State of the PMO 2012,” A PM SOLUTIONS RESEARCH REPORT, www.pmsolutions.com

2. “A guide to the Project Management Body of Knowledge” (PMBOK® Guide) – 3rd Edition, PMI 2004.

3. “To PMO or not to PMO? That is the question!” by Seweryn J. Spalek, PMI Global Congress 2009 – EMEA Proceedings, GBS03.PDF