PM Office Productivity – Make or buy?

Make or buy questions are a common thread in any business function that requires an extensive set of support tools to automate time-consuming manual work. This of course includes PM office management of portfolios, programs, and projects. After all, each PM team is only as effective as the collaboration tools they use to get the work done.

What is meant by “make” or “buy”? In fact, “custom” or “off-the-shelf” is a better way to express the question. The real question being, is a custom solution required/better than an off-the-shelf (OTS) solution?

With so many OTS project and portfolio management platforms to choose from, it’s easy for anyone to believe that at least one will meet their particular needs. In truth, it’s very unlikely unless the function is truly non-unique ( e.g. HR) in terms of methods used and work performed, when compared to similar functions in other companies. Project management rarely falls into this category since projects tend to vary significantly in terms of both methods used and the type of projects being undertaken from company to company. As a result, it is almost impossible to find an OTS PM collaboration system that isn’t an poor fit for team productivity.

The unavoidable truth for all those executives looking for a quick fix that can be obtained with a checkbook, is that “make” is very often the only viable option for real productivity improvement. Most OTS solutions are designed to meet the generic needs of any project in any industry. While that enables a greater number of sales, productivity is better served by tools tailored to the specific needs of the organization. When it comes to quality and productivity, OTS is a path to mediocrity.

So what about the make (custom) option? The advantage of course is getting exactly what you want and knowing exactly what you’re getting. The cost may be competitive too, given that most OTS collaboration systems are very expensive to buy and implement (configuration is often as difficult as development from scratch). On the other hand, building your own is more time consuming and it requires expertise more common to an IT organization than a PM office. If you don’t have the expertise in house, the development can be outsourced, but arrangements will need to be made for long term incremental development as your methods change and to provide ongoing support.

Looking at PM office automation from a top down holistic perspective, it’s clear that methodology and management tools must work hand in hand. Methods are the top priority, and must come first, since they define how work is done and therefore have a direct impact on quality and performance. Tools selection is lower in priority since tools simply make doing work easier and less prone to error. It follows then, that tools should be designed/configurable to meet the changing requirements of PMO methods. It also follows that improvements to methods will often necessitate improvements to the tools that support them (hence the need for the long term commitment from custom developers mentioned above).

Looking at automation from the bottom up, it’s evident that simplicity and ease of use are critical to success. Complex environments with multiple application platforms make training, maintenance, the distribution of work, and data integration and reporting more difficult to manage. When users are required to move in and out of different applications to make progress, they become frustrated and less productive, defeating the purpose of automation. In most cases some mix of enterprise and desktop platforms will be needed, but the total solution should be kept as simple and elegant as possible to reduce the potential for failure.

No matter what direction you take, a successful productivity system offers significant cost savings and increases in both speed and competitive advantage, but only when well planned and executed. Additionally, most of the value is realized via incremental improvements over time and not upon delivery of the initial system.

Some things to consider before you begin: Why are you asking the question, make or buy?

• What is the scope of the problem/opportunity being addressed? Do you need a complete system redesign or would some limited or specific improvements achieve most of the gains you’re seeking.
• What constraints (cost, duration, strategic alignment, …) will be applied to any given solution you identify?
• How detailed and specific are existing management methods (steps, forms, templates, reports, …)? As methods evolve, the need for customized tools increases.
• How flexible can you be with respect to existing methods and where?
• Do you have a well formed evolution plan for the organizations that will utilize or be impacted by the solution you implement?
• What ancillary methods/systems will  your solution be required to support and how?
• What off the shelf tools are available in the market?
• What resources and technologies can you draw upon to develop (and maintain) custom solutions?

It will pay huge dividends to begin with a detailed and well vetted list of system requirements. Just like any development project, it’s critical to prioritize each in terms of cost and payback. Use those requirements as input to a high level design that seeks to identify the best approach for realizing the system considering OTS and make options for each component in addition to the system as a whole. However comprehensive the list of requirements, start small – don’t try to boil the ocean. Since most of the real productivity gains will be realized when making post implementation improvements, it makes sense to start with a small first offering.

In summary, while most PM office organizations don’t have the skilled resources needed to develop and maintain a best in class productivity system, a custom (not OTS) solution is the only viable option to long term productivity gain. To effectively drive both quality and productivity the solution must be designed to support the requirements established by PMO methods and change as methods change.

The beliefs expressed above form the basis for PMOSoft’s PMIQ quality and productivity platform. PMIQ is the custom solution that each PMO needs. It provides tools to manage both PM office methods and collaboration and/or productivity tools that support project management in alignment with your own methods.

PMIQ supports ongoing improvements to both methods and tools while PMOSoft provides the long term expertise to help each client PMO improve and maintain their system over time.

Please visit us at http://pmosoft.com to learn more.

A Minimalist’s Approach to Project Metrics

What project metrics do you keep? A simple question, right? Perhaps, but there are so many ways to get wound around the axle in the “age of information” where every question has twenty equally compelling and comprehensive answers.

I personally prefer a minimalist when it comes to metrics management (or anything for that matter, methods, templates, …, anything). The issue for most PM’s (and other managers) when presented with the intellectual overkill found in so many advanced methodologies, models, templates, worksheets, etc.,  is in identifying what to keep and what to toss. Instead, many feel compelled to make use of every process step, template, and metric.

The trouble is, projects come in all shapes and sizes, and the one size fits all standards don’t usually fit all that well. Very few projects will require a lion’s share of the metrics included in any comprehensive off-the-shelf standard/methodology (PMBoK, PRINCE II, …). Couple that with the fact that it would take a small army to collect, evaluate, and react to them all, and it becomes obvious that PM’s in the real world have to prioritize their metrics collection and response efforts.

Getting Started

No one needs metrics – what they need are answers. As a result, it often makes the most sense to begin the process of identifying metrics, by first identifying the questions that will need ready answers as the project moves forward. In most cases, those questions will be answered in status reports using a combination of metrics and summary text, so it follows that metrics exist primarily in support of project status reporting.

As a result, a reverse engineering (RE) approach that works backwards from reporting requirements to metrics requirements is often the best way to go. The RE approach begins with an up-front design of key project status reports (periodic status, milestone, project close, …) that will be used to inform stakeholders and call team members to action. That report design effort will result in the identification of component  metrics required to fill in the blanks.

To produce the best possible report, contents should not be limited based on perceptions regarding the availability of data, but should instead represent the best “imaginable” report given the intended audience. As a PM, a well designed report can also guide daily/weekly tracking and control activities, making those efforts more automatic. Once report design has passed review, the process for data gathering must be developed based on report format, distribution method, and timing.

When establishing the processes to be used in gathering metrics , it’s important to prioritize the list in order of importance, and avoid processing any that aren’t truly needed. No metric should be included, for example, unless the team will actually be able to take the time to react to it. If the team won’t be able to take action in response to an undesirable metric, then it would be a waste of time to gather it.  It’s always possible to increase the number of metrics as the project moves forward, but attempting to take on too much at the beginning can steal time and attention from other critical project activities.

So what basic questions need to be answered? Let’s start by recognizing that everything in management can be cast in terms of short term impact (tactical) and long term impact (strategic). Understanding that most long term metrics are not critical to the execution of the current project, it then makes sense to shift the responsibility for those metrics away from the project team to functional teams like QA, design, or test. Of course, where the long term metrics target improvements in project performance, the project team may be required to maintain ownership.

Some basic project questions:

Project Tactical (short term impact)

• Is the project on-time?
• Is the project on budget?
• Is the project delivering the required high quality?
• What issues/risks threaten scope, schedule, or quality?
• Are project control activities (change, risks, issues, actions, escalations, …) being dealt with in an effective and timely manner?
• Does the project still meet project selection criteria?

PM Office Strategic (long term impact)

• How responsive is the project team (issues, actions, changes, …)?
• How effective is process (intervals & quality)?
• What project lessons have been learned?
• How accurate are requirements, estimates, plans?

Metrics, of course, are dependent upon a competent baseline. Effective projects get one chance at producing a competent plan, and once it’s been approved, it is the baseline. If the plan/baseline must change, then you really have a new project on your hands. Otherwise, there exists no basis for any of the questions above and metrics become fruitless – you can’t usefully measure an object undergoing transformation. The baseline provides the fixed values for time, scope, and costs (resources) from which all project metrics are measured. As a result, plan vs. forecast vs. actual values provide almost everything you need to measure the status surrounding scope, schedule, and cost. The project is on time if planned critical path dates are equal to their forecast dates, on budget if planned costs are equal to forecast costs, etc…  Of course all measurements must be cumulative from the bottom of the WBS to the top to ensure accuracy.

In terms of metrics measuring performance of unplanned work, benchmarks can be used in place of baseline plans. Take action items management as an example. How can you tell that delegated action items are being actively worked and not being starved for attention? The best method involves breaking action management into a series of steps (decomposing it) that can each be benchmarked. New actions, for example, may originate in “Pending” status and require that the PM admin screen the action to ensure it is valid prior to moving it to “Open” status. In this case, it would be easy to establish a reasonable benchmark of 24 hours as a maximum time in “Pending” status. Then all actions could be measured in terms of the benchmark. It’s more difficult to benchmark the length of time an action should remain “Open” status since actions vary in terms of the work to be done. It will make more sense to reference a considered and agreed due date as the baseline for that time-in-status metric.

As stated earlier, the metrics themselves are only part of the story. It’s the expert interpretation of what each measurement means and the explanation of response activities that complete the picture. It’s the formation of the right questions to be asked and answered that set the context. Finally, it’s making the right priority calls surrounding those questions that ensures that you have the information you need to manage effectively and not so much information that it diverts resources from more critical PM tasks.

PMOSoft provides the PM Office information and quality management systems (web applications & procedures) needed to achieve the PMO mandate in as little as 3-4 months. Our PMIQ platform seamlessly maintains more than 100 metrics. Please visit us at http://pmosoft.com to learn more.