Peak Portfolio

Why PMOs Fail

Allen Eskelin — Tue, 25 Oct 2011 02:14:12 +0000

There is a way of doing things and a way of getting things done and they’re not always the same. Most organizations of size have a Project Management Office (PMO) charged with defining processes and best practices (the way of doing things). These organizations typically sell the processes to a CIO to get executive-level support and then use that support as their stick to make sure the processes are followed. These people are often referred to as the PMO Cops by project managers.

So what’s wrong with this picture? The problem is that PMO’s are often staffed with process types who don’t have significant experience delivering projects. If they did, they wouldn’t be in a PMO role. Organizations can’t afford to have their best project managers doing process work. They need them delivering results to the business. Since the PMO team often lacks experience, they don’t receive the respect of the experienced project managers. This causes the experienced project managers to resent the PMO (“who are they to tell me how to manage a project”). This arrangement is common and is doomed to fail from the outset.

Some PMO’s try to overcome their lack of experience by hiring consultants to provide expertise and industry best practices. The problem with this approach is that every organization has a different culture and political climate. Consultants will not have the experience delivering projects within the organization so the industry best practice may not be the best practice for the organization. Once again, the experienced project managers will recognize this and resent the PMO for having a consultant “tell them how to manage a project”.

Other PMO’s try to pull their experienced project managers into an advisory committee to review the PMO-generated processes and provide feedback. This often fails because the experienced project managers get frustrated having to keep explaining things over and over to the process types. They don’t typically have time to waste on this. So they start skipping the meetings. The other challenge is that what works for one project manager may not work for another project manager. Project managers have different styles and typically find a way to become successful with their own unique approach(es). What’s the solution? My recommendation is to refocus the PMO’s role on the following:

Target Inexperienced Project Managers: Provide processes, coaching, and mentoring services to the inexperienced project managers. They’re the ones who need help. Experienced project managers don’t need a prescribed process. Leave them alone and let them do what they do best. They know from experience what needs to be done and to what extent (the way of getting things done). They also know where they can cut corners. This can only be determined based on experience. So for an inexperience project manager, it’s a good idea to have them go through the whole process without cutting corners. Over time, they will develop a sense of what’s critical and what’s overkill for a given project.
Apprenticeships: Place inexperienced project managers in a Project Office under an experienced project manager. Let them do the busy work for the experience project manager (example: manage the project schedule, change management process, etc…). This will be a win-win for both project managers. The experienced project manager will free up time to focus on high-value activities. The inexperience project manager will learn by watching the experienced project manager in action.
Project Audits: Setup a peer review process whereby the experienced project managers conduct project audits on the inexperienced project managers. Most experienced project managers would be happy to mentor the rookies. This will work even better if developing other project managers is part of the senior project manager’s annual review. Developing people is a requirement for moving up the leadership ladder and this can be a great way for a project manager to demonstrate that skill set.
Training: Bring project management experts in-house to provide training to the project managers. Or, encourage the experienced project managers to conduct the training programs.
PMIS: Implement Project Management Information Systems (PMIS). The key here is to get the experienced project managers involved in selecting the systems. Also, focus on tools that will help project managers become more efficient and not ones that will make their jobs more difficult. The premium is often placed on controls by management. Controls slow a project down so it’s important to prioritize the key metrics and milestones that need to be tracked and reported on.

Focusing your PMO on these five activities will provide value where it is needed most: developing the inexperienced project managers. Additionally, it will leverage the experienced project manager’s experience instead of trying to change the way they manage projects.

Bottom line: focus the PMO on developing the inexperienced project managers and let the experienced project managers continue to do what they do best: deliver results to the business.

by Allen Eskelin, CEO of Peak Portfolio, consultant, author, and Ironman.

Peak Report Email Newsletter

Minimal Path Project Management

Allen Eskelin — Fri, 16 Sep 2011 21:07:28 +0000

In today’s tough economic climate, businesses are forced to run with a lean staff. Executives are looking for ways to enable their project managers to manage more projects simultaneously. How can they accomplish this without burning out their staff? First lets look at a common approach and then I’ll recommend a new approach.

Critical Path

If you’re in the project management profession, you’ve most likely heard the term “critical path”. In project management, a critical path is the sequence of project tasks which add up to the longest overall duration, which helps to determine the shortest time possible to complete the project. Managing the critical path is a valuable tool for project managers to ensure they deliver a project on time. In the following diagram, the shaded boxes represent the tasks on the critical path:

By focusing on reducing the duration of tasks on the critical path, a project manager can shorten a project and therefore manage more projects in a year. While this helps, it doesn’t enable project managers to manage more project simultaneously because all project tasks must still be completed.

Minimal Path

So how can project manager continue to be successful while managing a greater number of projects? My answer is to reduce the number of activities required to complete a project. This means for each individual project, the project team identifies only the tasks required to complete the project successfully and does nothing more than that. I call this Minimal Path project management. Using our previous example, the shaded boxes below might represent the minimum number of tasks required for the project to be successful:

This is different because most organizations force their project managers to start with an approved project methodology and adapting it to the project objectives. These methodologies are filled with every possible task that will ensure quality on every type of project. With Minimal Path project management, there is no methodology. The project team starts with a blank sheet of paper and defines only what is needed to meet the project objective.

The Resistance

PMOs will typically resist Minimal Path project management as they are tasked with providing project methodologies, measuring compliance, and rolling project statuses up into program and portfolio reports. The only way these teams can provide accurate reporting is to ensure that all projects have a consistent group of tasks and milestones across all projects so progress can be measured consistently. The problem with this is that all of these tasks are a project tax for the sake of reporting and have little to no contribution to the success of the project.

Executives may also resist this approach if it means their portfolio reports will be less consistent and more difficult to prepare for their PMO.

Overcoming the Resistance

The only way to sell this approach is to focus on the benefit of completing more projects with less project managers and project resources. While executives may not have even considered this a few years ago, you can bet they’ll listen now if it means accomplishing more with less.

If you can’t sell the idea of Minimal Path project management to your leadership and/or your PMO, see if you can try the approach on a few projects that aren’t critical. Better yet, manage two similar projects using Minimal Path for one and the standard methodology for the other and see if there is a significant difference.

Pros/Cons with Minimal Path

Pros

Reduce resources needed to complete a project
Increase the number of projects a PM can manage
In some cases reduce the duration of a project

Cons

More difficult to track and measure projects consistently
Perception of lower quality of project management due to less project activity

Conclusion

Businesses looking to complete more projects with less resources should carefully consider whether a methodology should be enforced on all projects. Minimal Path project management will accomplish the same project objectives with the least amount of work.

by Allen Eskelin, CEO of Peak Portfolio, consultant, author, and Ironman.

Peak Report Email Newsletter

Vendor Research: 12 Methods for Researching Vendors

Allen Eskelin — Sat, 20 Nov 2010 11:07:01 +0000

Visible content.

Identifying and Contacting Vendors

Allen Eskelin — Sun, 16 May 2010 09:05:13 +0000

Identifying and Contacting Vendors, Inform IT, June 2001

Why Should You Visit the Site of a Prospective Vendor

Allen Eskelin — Sun, 16 May 2010 09:03:47 +0000

Why Should You Visit the Site of a Prospective Vendor, Inform IT, June 2001

The Role of Leverage in a Technology Acquisition

Allen Eskelin — Sun, 16 May 2010 09:02:04 +0000

The Role of Leverage in a Technology Acquisition, Inform IT, June 2001

Buy vs. Build

Allen Eskelin — Sun, 16 May 2010 09:00:29 +0000

Buy vs. Build, Inform IT, June 2001

10 Keys to Successful Technology Acquisition

Allen Eskelin — Sun, 16 May 2010 08:57:56 +0000

10 Keys to Successful Technology Acquisition, Inform IT, June 2001

Technology Acquisition by Allen Eskelin

Allen Eskelin — Tue, 11 May 2010 22:44:36 +0000

Ask yourself the following questions about your organization:

Are you partnering with the best vendors for your situation?
Are you negotiating the best deal possible?
How do you manage a technology acquisition?

With proven, step-by-step solutions, this unique and practical book shows information technology (IT) project managers how to acquire the right technology from the right vendor at the right price for their business.

There are numerous project management books on how to build technology, but the increase in project failure, limited resources, and accelerated change in systems and platforms has forced IT managers to move from building to buying technology, thereby shifting substantial risks to third parties. Allen Eskelin, drawing on his own experience managing acquisition projects, thoroughly explains each task required to buy technology successfully from outside vendors.

“We all know this, but not this well… Everyone knows how to acquire technology. We buy new cars, computers, and lawnmowers. But Technology Acquisition offers much more than I had anticipated—an interesting, practical roadmap and compass.” —Robert C. Larrabee, www.computer.org

Technology Acquisition covers all facets of technology acquisition management, including the “people dynamics” that can make or break a project. The book offers useful templates, example documents, checklists, and schedules that guide you through the entire procedure, as well as case studies to illustrate the processes described.

Author Allen Eskelin is the founder and CEO of Peak Portfolio. Allen has 20 years of technology management experience at Microsoft, Starbucks, and Gateway.

Managing Technology Acquisition Project Life Cycles

Allen Eskelin — Fri, 23 Apr 2010 09:38:56 +0000

Managing Technology Acquisition Project Life Cycles, PM Network Magazine, March, 2002