The Business Driven PMO

A quick trip to Wikipedia yields the following definition for resource leveling: ‘a project management technique used to examine unbalance use of resources (usually people or equipment) over time, and for resolving over-allocations or conflicts.’ In other words, through resource leveling we can ensure that the project schedule is reasonable and realistic from a resource perspective – that the people or equipment needed to execute the work will be available when and where they are needed.

Sounds simple? The reality is that resource leveling needs to take multiple factors into account and can be anything but simple. And, like anything else that’s really complicated, most of us are looking for better tools to help us accomplish the task. That’s when the question about automatic resource leveling comes up.

While some project scheduling tools provide a process to see if resources are overloaded, others also provide a function that will recalculate the schedule to eliminate any overloads. As exciting as it may sound, in practice, it’s common to see that managers either never use it or even if they do, they don’t use the resulting schedule without making a lot of other adjustments. Why? Because even though automatic resource leveling can quickly ‘resolve’ overloads, it typically does it by delaying tasks until the resource is available. What it cannot do is account for human or project variables; all it does is throw some simple numbers. The solution uses elementary level math to solve a calculus-worthy problem.

While some project managers often take advantage of the speed of automatic leveling they really don’t trust the inferences drawn from the calculation to make their final decisions. They recognize that a resource leveled schedule requires a deeper understanding of the project work and the resource requirement to perform that particular task. It also requires a deeper analysis of more subtle options, tradeoffs, or variables to yield the optimal schedule.

In order to level resources in an efficient, meaningful way, a manager must keep in mind the following:

1. Resource leveling is not just a math problem. A project manager must consider more than the singular question of effort required over the duration of a task. Instead, one must also think about what makes sense for the type of work being performed. Some tasks can be completed in less time by adding more people but sometimes splitting up the work canactually increase the time required to complete it, since multiple efforts need to be coordinated and integrated- which makes it even more time consuming. If you have a team member that needs to attend a three-day class, adding another person will not reduce the time for the class to one and one-half days.
2. Keep an open mind. There are many different alternatives to consider when resource leveling. Sometimes it makes sense to work on multiple tasks concurrently while for other kinds of work dedicatedeffort is more practical. For example, having a team come together (either physically or virtually) to work through a plan or work through the details of a project deliverable may take less time than going through multiple cycles of email. Conversely, if we expect to have a document out for review, it is entirely reasonable to schedule the same resources that created that document to work on another task. You may also want to consider alternative ways of accomplishing the work – such as rearranging the order of tasks or using technological advances to reduce the time required for a given task. You also need to consider general workload –even though your estimates may indicate that someone can work on 20 tasks simultaneously, you may be building in inefficiency by asking people to juggle too many things at once. Ever tried reading a book in an airport and realize that you’ve just read the same paragraph three times (or more)? The fact is that each time you’re interrupted by a flight announcement, you probably don’t pick up at the exact spot you left off – you end up re-reading from a logical spot. The same happens when we try to rapidly switch between multiple tasks – the very act of switching makes us less
   efficient.
3. Don’t try to be too precise – Remember that everything in the schedule that you’re trying to level is based on estimates – timelines may change along the course of the project. Good resource leveling requires that you keep your eye on the big picture rather than micromanaging or focusing on granularities. Also, keep in mind that the further into the future you go, the less sure you will become of everything. Give up on the notion of leveling to the hour six months into the future – resource leveling is about making a reasonable schedule, not a precise schedule. The more granular you are, the more you will need to adjust when things change.

Resource leveling is an important part of the project management process, but it can’t be done automatically. While an automatic tool may be handy, it is not a substitute for good old-fashioned common sense from a real-live human being. A software package cannot appreciate the need for variation in an individual contributor’s day, nor does it understand, as a good manager would that sometimes tasks must be performed concurrently, and they are other times when it they cannot be. The bottom-line is that an automatic tool can begin the resource leveling process, but it cannot finish it without human help.

On a closing note, if you haven’t read Fredrick Brooks’ book, The Mythical Man-Month: Essays on Software Engineering, now would be a good time.

Although the Clinger-Cohen act was passed in 1996 that mandated a capital planning and investment control process, PPM as it’s found in the private sector is only just making its way to the federal government. As a recent memorandum from the Executive Office of the President notes, ‘the stove-piped and complex nature of the Federal enterprise has led over the years to a proliferation of duplicative and low priority investments in information technology (IT).’

The Federal Government is now focusing on maximizing the return on American taxpayers’ investment in government IT by instituting a new IT portfolio management process. Their goal is to root out waste across the Federal IT portfolio and avoid investment in low priority and duplicative ITinvestments.

As the Federal Chief Information Officer mentions in a blog post, over the next year agencies are required to lead agency-wide IT portfolio reviews within their respective organizations. This will lead totargets for IT spending reductions, illustrate how investments within the ITportfolio align with the agency’s mission and business functions, establishcriteria for identifying wasteful, “low-value,” or duplicative investments and improve governance and program management.

As election seasonstarts, it will be interesting to see how the different candidates discuss costreduction for the federal government. For our part, Daptiv recently partnered up with Winvale to help the government agencies with thiseffort. We hope over the next few years we can share some of our experience tohelp the US government’s IT portfolio reduce costs and improve business
outcomes.

What’s in a name? As far as PMOs are concerned, it matters quite a bit. Standard parlance maintains that PMO stands for Project Management Office. Back in the days when the PMO literally ran a single project or program, the name was fine. But over time the PMO has evolved. Its scope of work has increased manifolds- first, it performs its core responsibility- to run all projects, next it sets up a methodology, and finally serves as a center for strategic portfolio planning. The charter of the PMO has now evolved to a point where the acronym bears little relevance to its traditional meaning.

To begin with, there is this notion that the new strategic PMO can be run by a good project or program manager. Indeed, most PMO Directors that I’ve met come from the project management ranks. While many perform admirably, their first inclination is to enforce methodology discipline – the death knell of many a PMO. Without a solid business background PMs are often ill prepared to handle the strategic trade-offs of the portfolio selection and planning process. Portfolio management is in essence a business process requiring strategy and operations expertise. In fact, analyzing competing business priorities does not require PM skills at all. It requires keen facilitation skills to handle the contentious debates that crop up between VPs arguing for their pet projects. Furthermore, a solid understanding of what makes a company tick while holding business stakeholders accountable for business cases.

Consequently, this leads to another area where PMO struggle and that is Benefits Realization. If we’re going to posit a business case during portfolio planning, shouldn’t we harvest the results as feedback? Shouldn’t we hold the business sponsors accountable for the benefits they claimed would be returned? Yet this is, again, a business function that occurs post project, and is often not dealt with by the “Project Management Office”. Project Managers like to “close” projects and assume they’re done once they hit “go-live”. But, benefits take months and even years to be realized and gathered and so fall outside this traditional project management thinking.

Finally, even if a solid PMO Director is in place, the “project” moniker still invokes too narrow a scope in the minds of business stakeholders. Without their full buy-in to the strategic nature of the PMO charter it is very hard to succeed.

So, the question here is – how to fix this problem? Is it really just about changing the name? Well, in my opinion that’s a start but what would really help is a change the way organizations perceive the charter of the PMO and its implementation process. The evolved PMO is really a strategic planning function focused on implementing change (the project management part) in the organization. It should facilitate portfolio planning, monitoring, and results to ensure strategic alignment and analyzing benefits returned for th investment. Project Management, Resource Management and the like are tools in service of the broader business goals. Several new acronyms have been proposed, including Portfolio Management Office (keeping the PMO moniker), sPMO (Strategic PMO), Project and Portfolio Management Office (PPMO) and the more light-hearted 3PO (Project, Program, and Portfolio Office).

The PMO has already grown well past the Project Management Office charter – isn’t it about time the name did as well?

Gartner recently released the 2012 Gartner PPM Magic Quadrant for Cloud-Based Project and Portfolio Management Services. This magic quadrant is focused on the needs of PPM leaders to improve speed, accuracy and agility, while managing risks and costs. It profiles vendors that are providing disruptive technologies — cloud and software as a service (SaaS) — to support these needs.

In addition to the vendor analysis, Gartner identified four key trends they are seeing in the PPM marketplace:

1.    PPM Sweet Spot

Gartner has observed a growing trend of organizations focusing on enhancing the collaboration,communication and reporting that targets the information flow between the project manager (the one responsible for managing and monitoring the work) and the project sponsor (the one asking for the work). Sweet spot communication and reporting require a “just enough” approach to the level of detail required to fit the audience. For instance, key tasks or milestones or phases might be tracked, but the sweet spot does not venture any deeper into more detailed PPM activities.

 2.    PPM and Agile Development Support

With the rise of agile development, PPM applications are supporting some of the communication, collaboration and reporting nuances associated with agile development methods, such as Scrum. A typical project portfolio includes different project types based on a wide range of methodologies, including waterfall, hybrid agile/iterative and more sophisticated agile variants for new product development. PPM solutions are now supporting more integrations to providers such as Atlassian and its issue and bug tracking Jira product, as well as Rally and its products that support agile development.

3.    PPM, Social Networking and Collaboration

Gartner notes that social networking and collaboration in the PPM context seem more like fads that could fade away someday, rather than become a legitimate mainstay PPM capability. Enterprise collaboration and communication tools, including issue tracking, threaded discussions, synchronization, integration to and from email systems and applications, and other mechanisms that have been staples of PPM software products for years. With the rise of Salesforce.com’s Chatter, Jive and Yammer that could change if something more meaningful and useful evolves from this introduction of social networking and collaboration in PPM software.

4.    PPM and Mobile Device Support

Finally, PPM providers are using HTML5 to connect a PPM system to a number of mobile devices, including tablets and smartphones. PPM providers are focused on delivering three main mobile capabilities to their customers early: (1) Time reporting, allowing end users to report their time from mobile devices into the PPM system, (2) The ability to approve items within a process flow of a PPM system, and (3) Executive reporting to mobile devices, so end users (for example, business managers or project managers) can access and view reports and dashboards from their tablets or smartphones.

You can view a full copy of the 2012 Gartner PPM Magic Quadrant for Cloud-Based Project and Portfolio Management Services at http://www.daptiv.com/gartner-ppm-magic-quadrant.htm

Organize to fit the work. 

This seems like a simple concept, but whether you’re setting up a new PMO, or expanding/re-organizing an existing PMO, getting the right organization can be daunting. Not only do you need to define the right roles, you also need to think about getting the right people with the best knowledge, skills and abilities to fill those roles.  Here are some thoughts about how you can go about building an optimal PMO organization. 

While there seems to be general agreement that a PMO provides a focal point for projects and project-related processes, practices and tools, there is no cookie-cutter definition of what is PMO is, what it does or who is needed to run it.  PMOs are by nature highly situational; they reflect the unique needs and challenges of their client or parent organization. Needless to say understanding and articulating your PMO’s value proposition and business objects are the critical starting point.  A critical point to remember is that when you start the discussion about organizing, you really need to focus on what you do.

What your PMO does, or needs to do, to meet its objectives and provide value is the key step in translating those too often broad, lofty strategic statements into the tactical, assignable activities that real people need to execute.  It’s very similar to the way we define projects - we start with strategies and business objectives and we end up with defined deliverables, tasks and assignments.

So assuming that you’ve been diligent about defining what you do, here are some thoughts about who you might need to do it.  

PMO Administrators:  Most PMOs are heavily tasked with collecting data, distributing information and coordinating review and governance activities. In a perfect world all of these things would be auto-magical but in the real world someone needs to make them happen.  From sending ‘gentle reminders’ to managers that their reports are due to coordinating calendars and distributing meeting materials, the PMO administrator plays a key role in making sure that the internal processes run smoothly.  The best administrators also play a role in creating and communicating those internal processes across the PMO stakeholder community.  Superior organizational skills, patience, persistence and good people skills are all a must!

PMO Analysts:    There are potentially several different analytical positions and job titles appropriate to a PMO; process analyst, information analyst, tools analyst, business analyst, etc..  So what does an analyst do?  In the PMO context, the analysts are the people who dive into the details:

• A process analyst defines the individual elements that make a process – what needs to be done and how – and helps in communicating that across the organization.  The process analyst is the person who works with subject matter experts to work through the details of how a process will work, create the process documentation, educate process users and stakeholders about using the processes, and continually improve, update and enhance the process as your organization matures. 
• Information or reporting analysts determine what kind of data is needed to support decision-making, set up the mechanisms for collecting that data and critically examine the data, turning it into meaningful information can be used by decision makers.  If you ask a really good information analyst a general question about how a particular category of project is performing, you will never get a response of ‘fine’ – you’re more likely to get a dashboard report showing consolidated information on key indicators for that project type. 
• Tool analysts are the people in your organization who know more than anyone else about the capabilities of the tools you use to manage projects and portfolios.  They can tell you what your tools can and can’t do but they can also get creative and help you use your toolset to craft solutions to your business problems. 
• Business analysts liaise with your organizational stakeholder community to understand their needs and requirements and help translate these into systems, processes and tools that will meet those needs.  Business analysts work with the stakeholder community continuously to ensure that what is delivered meets the needs and requirements; as such, they play a huge role in ensuring stakeholder satisfaction.

Great  analysts – of any kind – are excellent at open listening and are exceptional  critical-thinkers.  They use details, but they don’t get bogged down in them and can explain their methods and thinking to others.

Project Managers:  The great debate is not about what project managers do, but whether they should be centralized in the PMO.  One side argues that because the PMO is responsible for the practice of project management, all project managers should report and/or be accountable to the PMO.  The decentralization side argues that project managers should have a strong working knowledge of the business or technical aspects of projects and should thus report into the functional area executing or sponsoring the project.  PMO’s are concerned about adherence to project management standards, and mitigate risk by having deploying professional project managers.  Functional areas are concerned with the quality of the project deliverables and the need to understand the project’s business and technical issues.

The answer is that both sides are right and wrong.  In practice, most successful organizations are those that recognize the need for a mixed model.  Large, complex, cross-functional Programs and Projects require a dedicated manager who can effectively oversee the project across the enterprise.  As a ‘center of practice’ the PMO is the appropriate ‘home’ for these project (or program) managers.  Conversely, a smaller, intra-functional project may not require the same level of project management rigor and could be effectively managed by a functional resource – a ‘project leader’ as opposed to a ‘project manager’.  Using a mixed approach is not without its challenges, but there are also some compensating benefits. 

 A key challenge is determining the criteria for which projects require ‘project managers’ vs. ‘project leaders’ , which then need to be applied to during the project intake process.  Those criteria should be focused on risk mitigation, not availability of qualified project managers. Assigning a project leader to a mission-critical project because all the PMO’s project managers are busy invites disaster.  There must also be clear expectations and accountability for things like status reporting – as information generated by project leader is needed by the PMO to provide enterprise-level visibility into projects and portfolios. 

Key benefits of centralized project managers include ensuring an adequate level of management for large complex projects, and providing the enterprise as a whole with subject matter experts in project management. These expert PMs can assist in establishing project management processes, educating or assisting others in their use, and increasing the overall project management maturity of the organization.

The PMO Manager/Leader:  Last, but not least, we come to the head of the PMO.  In his 1990 Harvard Business Review article, ‘What Leaders Really Do,’ John Kotter asserts that management is fundamentally different from leadership.  According to Kotter good managers deal with complexity by planning and budgeting, organizing and staffing, and controlling and problem solving.  By contrast, leaders cope with change; setting direction, aligning people to that direction, and motivating and inspiring people to keep in the right direction.   

The effective PMO manager is both manager and leader. This individual establishes the plan for what the PMO will do, manages the work and the staff and ensures tactical objectives are met.  At the same time the head of the PMO fills the pivotal leadership role for the PMO team and for the practice of project and portfolio management across the organization. While the PMO manager spearheads efforts for creating and maintaining processes to ensure consistent predictable project performance, the PMO leader is continually working across the enterprise to encourage the adoption of those processes and the use of the information they provide.  The effective PMO leader is continuously adapting themselves and the PMO to support the needs of the organization. 

In conclusion, setting up and organizing a PMO requires forethought and preparation.  Some things to keep in mind:

• Understand what your PMO does (and what it doesn’t do)
• The optimal PMO organization is situational to its environment; no two will be the same.
• Get the right kind of people to do the right work in support of the PMO mission.
• Always remember your roles as manager and leader

And, of course, organize to fit the work.