Project Management Institute

Positioning the project office

what's your opinion?


by Paul C. Dinsmore, PMP, Contributing Editor

PROJECT OFFICES HAVE CROPPED UP in organizations in recent years because of the snowballing number of projects companies have to incubate and nurture in order to survive and prosper. But what are project offices good for anyway? And how should they be positioned? And what ultimately determines where they reside in organizations?

Structure and support are needed to make sure enough on-target projects are produced to sustain and stimulate the business. If you sit at an organization's strategic level, you may need to champion a corporate program office to guarantee consistent project management methodology and practice for multiple projects across the enterprise. If you are in the mainstream of an IT area, however, you may require a project office to provide specific standards, methodology, training, and support to information technology projects. The same departmental focus applies to engineering and new product development. An even narrower focus is the “project office within a project” for special situations like mega-projects or other very unique undertakings.

Why Bother?

Two conditions are required before it makes sense to design and implement a project office: one is external to the organization and the other is internal. The first is market pressure—the crunch to get more products and services out faster, to shorten the product development cycle. This pressure from the outside spawns discomfort within the organization and moves people to search for improved methods.

The second condition is the internal repercussion caused by that market pressure, which manifests itself as dissatisfaction with the processes being used. Since the pressure from the market calls for a major boost in an organization's project output, both hands-on professionals and managers begin to question the procedures in place. That questioning sets off a search for a better way for meeting the market demands, which in turn often results in implementing a project office to act as a stimulus and guardian for modern project practices.


Paul C. Dinsmore ( is a PMP and PMI Fellow. He is the author of seven books, including the AMA Handbook of Project Management [Amacom, NY, 1998] and Winning in Business With Enterprise Project Management [Amacom, NY, 1998]. He is president of Dinsmore Associates, affiliated with Management Consultants International Group, based in Rio de Janeiro, Brazil. Direct comments on this column to

How to Design and Implement a Project Office

Based on my research and on assignments in organizations, I observe that no two companies seem to go about implementing project offices the same way. This makes sense, I suppose, since companies are at least partially different in culture, product strategies, locations and managerial styles. So the design of project offices must take into account the peculiarities of organizations. In other words, project offices have to be customized to be effective.

In my April 2000 column, I summarized the project office design variables that influence the design of a project office. The variables are organized as a checklist of questions, covering context, organization and people, support functions, and project execution. The queries raised in the checklist are great both in number and in variety, leading to different responses and thus suggesting differing configurations for project offices. The possibilities cover everything from centralized enterprise project management involving a powerful corporate project office to departmental approaches to basic support functions for isolated projects.

Coming up with a great technical design for a project office, however, isn't enough to make it happen. Although technical design might outline the “right” solution, in the real world it takes much more to turn design into reality. And that additional element involves human behavior.

Power and Opinions: Spare Me the Facts

So how should these organizational decisions for placing project offices be made? Based on technical design (the facts) or on opinions?

Managerial decisions are generally opinion-based as opposed to fact-founded. Facts and technical findings are manipulated until they justify the opinions of the decisionmakers who have preconceived notions based on prior knowledge and experience. Peter Drucker documented this initially-shocking-but-obvious reality decades ago.

The power relationships of those opinion-makers also shape the positioning decision. Winners and losers appear when newly configured project offices are placed in organizations. This spurs behavioral responses—both before and after the project office is entrenched. The opinions of the organization's power brokers are a part of all organizational shuffles, and the move to implement a project office is no exception.

Market pressure and internal discomfort of company professionals and managers with the status quo are prerequisites for new project office initiatives.

Does this mean that technical issues and fact-finding should be written off in the decision-making process? Should decisions be made straightaway after a few rounds of managerial jousting? Obviously not. Fact-finding spotlights new information, and allows decision-makers to refine opinions. It also obliges them to justify opinions when in apparent misalignment with the facts.

An Example: New Product Development and Project Management

Let's take the case of a major corporation that has a need to launch new products speedily, and also faces project management challenges in the areas of engineering, information technology, and operations. Here are two approaches for dealing with the challenge.

All Out Thrust for New Product Development. Under this assumption, new product development is the overall goal—time to market is king! Whatever needs to be done to meet that goal is done—all stops out, full speed ahead! Great emphasis is placed on identifying new opportunities, competitive analysis, technological development, and refining the process to design, construct, test, and implement the new product.

Project management in this setting is a tool aimed at helping achieve the goal of shortening time to market and meeting the market's demand for new releases. Planning, scheduling, and control tools are used to organize and monitor the activities needed to develop new products.

Enterprise Project Management Approach. In this view, the goal is to optimize the therefore they must all be optimized. This includes the following project groups:

Strategic. These projects include cultural change, implementation of strategic projects like total quality, new strategic directions, and new managerial philosophies such as matrix management or participative management.

Operational. This group includes major upgrades in equipment and systems, office relocations, and maintenance projects.

Capital Improvement. New factories, infrastructure, and other projects involving substantial capital expenditure are included in this category.

Marketing and Product Development. Here the assumption is that new product development is a part of an overall enterprise effort aimed at managing all types of projects effectively. A standard methodology or project management process is the basis for managing the projects. For marketing and product development, that standard methodology is adapted to NPD projects.

NPD Project Office Vs. Corporate Project Office

What's the best way to organize the project office for the situation presented: All out thrust for new product development or the enterprise project management approach?

Under the enterprise project management tack, a corporate-level project office is called for to manage the procedures and practices for projects throughout the organization. Assuming, however, the option is to place specific emphasis on new product development over and above other types of projects, then a specific NPD project office is the solution.

Note that most new product development activities are likewise project management activities. The following tasks, for instance, clearly belong in either category:

Gaining buy-in for the process

Dealing with changing requirements

Prioritization of projects and of activities

Structuring a product development organization

Managing contractors and third parties

Cross-functional cooperation

High-level visibility for key phases

Team building for developing new products

Training and development of competency

Metrics for comparing progress and results

Specific management tools for new product development

Resource allocation

Dealing with cultural issues.

So there's logic to either approach to dealing with the new product development challenge. A strong case can be made for either technical recommendation: the holistic enterprise view or the clearly targeted NPD approach.

MARKET PRESSURE AND internal discomfort of company professionals and managers with the status quo are prerequisites for new project office initiatives. Having a feasible technical solution based on a thorough analysis of the relevant variables is also a precondition. What makes sense and what will ultimately work?

A feasible solution supported by the opinions of the decision-makers and the power structure of the company is what will work. For instance, a new product development program strongly supported by upper management is better for the company than a lukewarm, poorly supported enterprise management approach. On the other hand, an enterprisewide project approach with strong management buy-in provides support across the organization and ultimately improves the bottom line as a result of multiple projects being brought in on time, within budget, and in accordance with the client's needs and the company's strategies. Strategic positioning of project offices strongly affects a company's performance. Perhaps more important than the decision itself is top management's steadfast support of the chosen option. ■

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

August 2000 PM Network



Related Content