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.

Sharing the Stage to Win in Project Management

What kind of manager are you, theory X (TX) or Y (TY)? As we all learn at some point in our education, TX generally assumes that employees are shiftless and lazy, and will only work if they’re forced to do so. TY on the other hand assumes that all employees want to do a good job, and if given the responsibility, authority, and tools to get the job done, they will devote themselves to the best outcome they can generate.

In reality, of course, things are never this binary. Any group will have some people that generally fit the TX profile and others who better align to TY.  It’s the job of each manager to extract the maximum value from the teams they manage, and within the framework of project management, that requires more than their obedient follow through on assigned tasks (i.e. TX). It requires each team member’s best research, critical thinking, and independent action towards the best possible project outcomes. In short, they have to own the problem right along with the PM. It is the PM’s job to make sure they’ve identified resources that can and will do just that.

Getting the best work from a team necessarily means placing trust in each team member. PM’s with a proclivity to “play the hero”, will often claim that project responsibility falls squarely on the their shoulders alone, but such statements smack of a TX mentality. The PM hero will often shoot from the hip, make decisions in a vacuum, and under utilize team members by limiting them to assigned tasks and not utilizing them as subject matter experts in planning and decision making efforts. While it’s true that the PM is ultimately accountable for project outcomes, those with highly developed management skills will involve their team members in identifying what needs to be done and providing expertise in decision making, as well as actually doing all the work. This level of engagement is important since projects, in addition to meeting business requirements, also have a significant impact on team building, professional development,  and employee on the job training for employees and partners.

So what does it mean to “share the stage”?  It means, making important delegations that challenge team members, helping them to exceed those challenges, and then giving them the credit when they do. This behavior builds leadership skills for tomorrow and motivates employees to do their best work for the PM. It motivates them to work with the PM again whenever the chance arises. Employee satisfaction improves when team members are given the chance to have an impact and are recognized for good work. Gallup (the poll production company) made the connection years ago that customer satisfaction follows in a direct correlation to employee satisfaction, so there is a direct impact on customer loyalty. OK, all good stuff, so what’s in it for the PM.

Well here’s the odd part – the part that doesn’t really seem logical. The good  guys really do win in the end. Although it’s hard for some the get their heads around (you know them), when someone takes on a management role, it becomes less about them and what they do personally, and more about what they are able to accomplish through others. While the PM was busy delegating all the interesting work to team members, selflessly helping them win the glory, and openly praising their efforts, all eyes above were fixed on the PM. Why? Their team was well motivated, engaged, and productive. They obviously selected the best and used them wisely because project outcomes were very good and  this was highlighted when the PM personally took steps to praise the great work done by key team members in project reports. In general, this PM seems to be creating win-win scenarios in every direction.

I heard it best stated in an old AMEX advertisement where the young restaurant owner says, “My father told me, you can do anything you want to do – you just can’t do it alone.” Absolutely right – you need the team. PM’s who don’t realize that, won’t get the best their team has to offer, and all project related outcomes will suffer.

PMOSoft provides the PM Office information and quality management systems (web applications & procedures) and consulting expertise needed to achieve the PMO mandate in as little as 3-4 months.  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.