The Business Driven PMO

Early this week we announced the launch of our upcoming PMO Success Webinars for 2012, aimed at offering real-world guidance on how to build and run a successful Project Management Office.  This free educational series will provide insights and perspectives from PMO Directors and Consultants at organizations running successful PMOs as well as Daptiv’s professional services team.

According to research performed by industry analysts such as Project Management Institute (PMI), the Gartner Group, and Forrester Research, 25% of all PMOs closed within one year and 50% closed within two years. Clearly, PMOs face significant challenges within their organizations. On the other hand, the need to successfully complete projects has never been greater.  Most companies recognize that projects are a major vehicle by which companies grow, improve and meet their business objectives.  The need to plan, monitor, and execute projects has never been greater. Companies decide to setup PMOs to do just that but they often fail to get the desired results from them.  Daptiv’s PMO Success Webinar Series will shed light on how companies can prevent the fall of PMOs and instead turn them into a strategic asset.

We kick off our first webinar titled, “Are You Ready for a PMO” on Tuesday, September 25. It will focus on how organizations can assess the need for a PMO and how they should go about setting one up. Come join the discussion with 250 industry professionals who have already signed up for the series. Panelists will include Mark Perry of BOT International and Dave Blumhorst of Daptiv Solutions, LLC.

To find out about more the Daptiv PMO Success Webinar Success Series, click here.

Lean.org characterizes Lean as:

“Eliminating waste along entire value streams, instead of at isolated points, creates processes that need less human effort, less space, less capital, and less time to make products and services at far less costs and with much fewer defects, compared with traditional business systems. Companies are able to respond to changing customer desires with high variety, high quality, low cost, and with very fast throughput times. Also, information management becomes much simpler and more accurate.”

Lean.org defines Lean as:

“To accomplish this, lean thinking changes the focus of management from optimizing separate technologies, assets, and vertical departments to optimizing the flowof products and services through entire value streams that flow horizontally across technologies, assets, and departments to customers.”

Building a Lean and effective IT governance should not be transformational but transitional.  It is a major shift for an organization whose only governance is the command and control of the organizational chart.  Simply implementing a PPM tool is not the answer. In the book “The Information Paradox”, by John Thorp  Copyright 2003, McGraw / Hill, states that there are three necessary conditions for an effective governance:

• Activist Accountability
• Relevant Measurement
• Proactive Management

Well technology can’t deliver these three conditions, they’re organizational. However a PPM can contribute to sustaining the knowledge, specifically with Relevant Measures.  It can be the single source-of-truth. Implemented correctly the PPM system IS the repository of the decisions the organization has made in the past.  This means that any governance placed in IT investments must also have the same scrutiny place on the ‘relevant measures.’  Relevant Measures must evolve with the rhythm of business.

As I said earlier, a governance needs to be transitional, it is a continuous improvement process and needs to be implemented at the rate the organization can absorb the change.  Activist Accountability!  Commitment needs to up and down the organization with strong leadership.

To start with the governance needs stewardship. This classically comes from the PMO, but as it has been will documented this isn’t the process/methodology police.  The PMO needs to be open and clearly communicate the “vision of the end” at the beginning.  A lean effective governance is more than how you run a project or any investment for that matter. That’s why it is important to recognize that governance is a combination of two major processes; the first being the project life cycle; the second is the portfolio process.  Your transitional strategy needs to take both of these into mind. And these processes should be instantiated in the PPM tool. Another key to governance is the roles in the governance and the exchange of information and dialog between them.  Oh and this is NOT an organization chart! But is a make-up represented cross-functionally. The roles are:

• PMO – Is the steward of the governance.  The make of this is more that just project managers.  It needs vision and leadership capable of being the “trusted advisors” for the complete governance. The PMO is the champion for change. Not only does the PMO
  require the PMs but needs the vision and the moxie to champion the “roadmap” for the governance’s evolution.
• Decision Board – Represents the needs and priorities of the governance.  It’s made of the business leaders accountable for the introduction of change from the investments in the portfolio. The Decision Board is accountable for the decisions of the portfolio make-up and the Relevant Measures.
• Steering Committee – Represents the needs of the project, program or investment.  This is different from the decision board its scope IS narrow, but necessary.  I’m not going to elaborate on the Steering Committee; its role is well documented in project methodologies like the Project Management Institute’s Project Manager Book of Knowledge (PMBOK).
• Project Manager or Program Manager or Initiative Manager or Investment Manager – They all fulfill the same role – Investment Steward, one of the most important roles in the governance.  The investment steward is accountabledelivering on investment outcomes.  Againthis is a well-documented role.
• Project Members – Yes they are considered as part of the governance and are sometimes left out. Their role in the governance is to deliver capability as prescribed by the investment steward and communicate progress on that delivery.

Those are the primary roles, however in more mature organizations there exists two more roles, they are:

• Portfolio Manager- In highly evolved governances the Portfolio Manager is accountable for the performance targets or outcomes of the portfolio. The Portfolio Manager is part of the decision board and advises the decision board on investment scenarios and portfolio adjustments.
• The Architecture Review Board – In conjunction with the Steering Committee this board is counseled for any impact to the enterprise architecture. Now wait, this not the standards police! The architecture board is made up of enterprise architects and is accountable to ensure that an investment does compromise the direction of the enterprise architecture.  Enterprise Architecture is a topic in of by itself and there is much written but in no means is the scope of the blog post.

This post is about Building and Maintaining a Lean and Effective IT Governance Board, I’ve touched on mostly the building part, but maintaining?  I’m not going to fool you that is the hard part. But the key to remember, this is a continuous improvement process.  People are likely to move on, especially in the leadership, that’s why keeping the governance going is not one person responsibility.  How does that saying go…? “It takes a village…” and change is good!

By keeping up with the rhythm of the business you are always ensure the portfolio is working on the Right things, the Right way, things are getting done, and the governance is realization the full benefit and potential.

People and organizations all over the world continue to embrace and adopt “Lean Management Principles” in their work. What started with Edward Deming in the 1950s and later found its way into the Toyota Production System has now made inroads into software development. You will notice that IT organizations and software development teams often talk about “Lean” software development or “Kanban” as it pertains to how they work. It is therefore essential that today’s Project Management Office (PMO) understand this old new way of project execution in order to stay relevant in today’s business climate.

Before we go any further, let us first understand what Lean is all about and whether PMOs should embrace this concept as well. Lean in a nutshell, is a set of tools that help in the identification and elimination of waste. As waste is eliminated, quality improves, consequently, reducing time and cost of production. While elimination of waste can seem to be a simple subject, it is often easier said than done. Organizations often have a difficulty classifying a process or activity as waste and often tend to be conservative when identifying/defining waste. Toyota defines Lean as the reduction of three types of waste:

1. Non-value-adding work
2. Overburden
3. Inconsistency/Unevenness as it pertains to flow of work

Lean aims to make the work simple enough to understand, execute and manage, and I believe that all PMOs should strive for this. Let us now get down to brass stacks and examine how a PMO could strive to be Lean. Here are some steps a PMO could take:

1. Prioritize projects based on business value. A project is a vehicle for change in an organization, which means that the business does not like the current state it is in and constantly evolves to move to a new state. Be willing to question the assumptions that drive any decision to change and make sure that the scope of the project is in line with the desired
   change/objective. This will help PMOs avoid/eliminate non-value-adding work.
2. Keep the internal PMO processes simple to start with and make changes as you mature. This will help the Project Managers and the PMO director to focus on delivering business outcomes rather than following mundane procedures.
3. Level out the workload among the Project Managers so that they can provide each project the required attention. Take the help of automation tools such as Project Portfolio Management software to help with collaboration, resource management, project prioritization, and reporting.
4. Use a “pull” system as your project intake process. In such a system, the sponsor of the project would place an initial project request. This request in-turn would trigger a project prioritization request, which in turn triggers subsequent
   requests (such as resource request). This will encourage a “just-in-time” process and will discourage a “just-in-case” process (common in a “push” system) wherein resources are often under-utilized.

To conclude, as projects and project executions take on a lean posture, it is imperative that PMOs do so as well. With this blog I have just scratched the surface of the lean PMO concept. Stay tuned for more! In the meantime, I welcome your comments and feedback.

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.