The Project Office: When, Why, How

The Project Office: When, Why, How
Written by Gary Gack

The concept of a “Project Office” has been applied successfully in the Construction and Defense industries for many years as a tool to manage risk on major projects. In these days of out-sourcing and business process transformation, the Project Office can help you manage the...

The Project Office:
When, Why, How

By Gary Gack

When the Project Office May Be Used

Scenario 1 - “We must transform our business in order to survive. To survive, we must reduce our cost base by at least $ 1,000,000,000 over the next three years. To achieve this we will reduce our work force by 20%, which will be enabled by integrating and extending our existing information systems infrastructure.”

There are dozens of large companies that fit this description today. Perhaps yours is one of them. In many organizations the ability to implement necessary systems and re-engineer business processes is an important obstacle to success. This is a situation tailor made for use of the Project Office.

Scenario 2 - “Due to the increased competitiveness in our industry, our earnings per share growth has slowed and our stock is now under-valued. To increase shareholder value we must improve our margins, which we plan to do by consolidating our redundant and incompatible divisional information systems into a single common system. This strategy is expected to save at least $ 100,000,000 over five years.”

This is another very common occurrence in today’s environment. Pulling this off probably means selecting an integrated application software package and perhaps engaging a consulting firm. How does a firm that has never undertaken anything even a faction the size of this effort avoid being at the mercy of suppliers that stand to benefit from over-runs and delays? An effective Project Office can provide the expertise and objectivity needed to help the company manage the consultants and package vendors.

Scenario 3 - “In order to reduce unit costs and increase our access to scarce technical resources, we have outsourced our internal IT function to a major systems integrator. The integrator is committed to improve productivity, reduce unit costs and deliver the same volume of software we have developed in prior years.”

We read of deals like this nearly every week. But what is the definition of “the same volume of software” or “productivity”? How will that be measured, and by whom? Clearly both parties may have a vested interest in shaping the answers to their own advantage. A Project Office staffed with measurement expertise can provide a means to assure a fair balance of interests.

Why the Project Office is Used

First and foremost, the exclusive focus of the Project Office is on the Project. The Project Office is not responsible for product to be delivered by the project; rather it is responsible for ensuring that every reasonable step is taken to ensure the success of the Project. This is a crucial distinction. The effective Project Office is structured to insure independence and objectivity. Its principal objectives are, first, to facilitate open, fact-based dialog between customer and developer regarding the processes to be used to maximize chances for success and second, to provide objective and independent assessments of estimates and status.

Developers (bless them!) tend to become very focused on the products (systems) they are developing and quite naturally are less interested in abstractions such as “process” or mundane details such as estimates (trust us, we’ll get it done).

Customers (bless them too!) have a tendency to be focused on the demands of the shareholders and on the deadlines forced on them by competition. They may be equally disinterested in “process” and often feel vulnerable when they must rely on technical staffs whose pronunciations are difficult to understand and more difficult to evaluate. Small wonder they may impose deadlines, attainable or not, since they (and perhaps the developers as well) have no way to know what is realistic (just get it done, whatever it takes).

This gap in perceptions is often fatal, since more than 30% of all large projects fail! Many of these failures may be traced to unrealistic expectations and unrealistic estimates. In my consulting practice I often see project schedules which reflect rates of delivery that are 50% greater than the project team has ever delivered in the past!

Project Office to the rescue! Very senior people whose have in-depth knowledge of the processes required to make large projects succeed staff the effective Project Office. They know how to evaluate the reasonableness of project schedules, and they have expertise in the estimating process itself. They understand project planning (critical path method), definition of deliverables, the role of quality assurance, how (and when) to construct an effective test plan, how to measure and monitor progress and status and how to manage “scope creep”.

The Project Office staff, because their careers are not dependent on those who manage the project, is free to speak up when insiders may not be able to take the political risk. If the project team has not made reasonable allowances for quality assurance effort and related rework the Project Office will attempt to negotiate a workable plan, or, failing to do so will “go public”.

Because Project Office staff is not responsible for business operations, they are free to point out that the customer is imposing unrealistic deadlines or has failed to establish clear and stable requirements. Projects are most likely to succeed when the legitimate interests and needs of both customer and developer are balanced. The Project Office provides a mechanism to facilitate and promote true partnership.

How to Establish the Project Office

Make sure that the Project Office contains the expertise needed to ensure success. At a minimum, the Project Office must include at least one senior individual with large-scale project management experience. The combination of expertise required will depend on the specifics of the project and on the capabilities and experience of the developer and the customer. At a minimum, expertise in estimating, quality assurance processes, project management and facilitation are essential.
Make sure the Project Office is independent and objective. Typically this means that the Project Office will report to a level in the organization that insures free access to key people and the opportunity to escalate critical issues to the highest levels. If either the customer or the developer can silence the voice of the Project Office its effectiveness is compromised. To ensure objectivity one clearly does not place the fox in with the chickens. Beware the contractor who insists on providing the Project Office and resists oversight by outside experts.
Make sure that staff members of the Project Office approach their task with a positive outlook. The Project Office is not an audit function. It is not an enforcement mechanism. The purpose of the Project Office is to bring industry best practices to the fore and to do everything possible to encourage their use. The Project Office has an obligation to speak candidly based on experience, to encourage and persuade, to facilitate and to make visible. In the end, the project team and the customer must decide and act. The Project Office succeeds by forming alliances around the idea of a win - win for all concerned.
Recognize that the Project Office is intended to ensure that the right things are identified and done - by someone qualified to do them. This does not mean that all of the functions mentioned here (and many others not discussed) are actually done by Project Office staff. The Project Office is frequently headed by an independent consultant or by a senior project manager temporarily on loan from the corporate office or from another division. Specific expertise, such as estimating or test process assessment, may be contracted or borrowed from elsewhere in the organization as and when required. The key role is to ensure that the right activities are in the plan, and that they are in fact executed to the agreed standard.

Functions of the Project Office

The functions performed by the Project Office (PO) may vary significantly to suit the specific circumstances and also change as the project moves through its life-cycle phases, which typically include scoping, source selection, detailed planning, monitoring, and wrap-up/post-mortem.

During the scoping phase the PO may be asked to assist the customer in defining the scope and boundaries of the project(s) needed to achieve a particular business objective, such as upgrading a portfolio of information systems to enable staff reductions designed to increase competitiveness in a newly de-regulated industry.

If, for example, an organization needs to reduce headcount by 20% within a three-year period in order to meet cost targets it must rapidly identify all of the systems to be developed and/or modified. Early determination of the boundaries of each project, together with preliminary “should cost” estimates, are essential to recognize the overall resource requirements.

Estimates must not be made pre-maturely - sufficient knowledge of requirements to permit sizing is an essential pre-requisite to any realistic estimate. These high level resource requirements need to be quickly translated into an acquisition strategy - what will be done in-house, what can be purchased, what can be contracted. If the organization needs 12 - 18 months to accomplish this first step (a common time frame), it seems highly unlikely that the three-year target will be met.

A key function of the PO may be to help the client to address this issue, i.e., how to reduce a 12 month scoping effort to perhaps 6 months. The PO may suggest a “massively parallel” approach with several concurrent mini-projects using facilitated rapid requirements techniques within 3 - 6 month “time boxes”. These efforts may be undertaken using in-house resources (if available) or by specialized contractors.

Once adequate scope definition has been accomplished, attention may shift to the source selection phase and definition/execution of an outsourcing process if such a process is not already in place. This will require identification of potential sources, preparation and delivery of background materials for potential contractors, development of a ranking and scoring approach for contractor proposals, and preparation and/or review of contract documents (possibly including incentive and/or penalty provisions). The extent to which the PO participates in these activities depends on in-house capability and experience. Most organizations undertaking exceptionally large efforts do not have all of the necessary capability and capacity in-house.

The PO may be asked to perform independent assessments of supplier organizations (in-house or contractor) to evaluate capability/maturity of development contractor processes and practices. Such assessments may include creation or review of baseline metrics relating to historical rates of delivery, defect rates, etc. These baseline metrics are essential to evaluation of proposed schedules - if the developer has never delivered at the rate proposed, why would we believe that the 60/month proposed for our project is attainable?

During the detailed planning phase the PO may be asked to facilitate the creation of a detailed project plan using the critical path method (essential to success in any large project). This may include training participants in the basics of the CPM approach. Failure of many large projects may be traced to inadequate planning and evaluation of alternatives. The PO acts to restrain the natural tendency to “fire” before “aiming”.

Key functions of the PO in this phase include advocacy and awareness of most common and most serious project risks, acquisition and execution best practices, inclusion of appropriate quantity and type of QA activity, provision for rework and integration of appropriate metrics to aid project monitoring.

The project-monitoring phase may find the PO responsible for maintenance of the CPM network and the preparation of status updates for the customer and/or the provider. The PO may perform or participate in periodic independent assessment of estimates; product quality and detailed plans (such as test plans). Typically such reviews focus more on process issues than on content, which is necessarily the responsibility of the project team.

The most important role of the PO during this phase is to ensure timely and accurate representation of project progress, risks and quality. Best practices in this area include preparation of a “Project Control Panel” to display, succinctly, key indicators of project health.

The PO’s role during the wrap-up or post-mortem phase may include capture and documentation of best practices and lessons learned. Typically this phase will include collection and archiving of project metrics, such as effort months, duration by task, defect rates, product sizing, tools and techniques utilized (with benefit ratings), etc.

In certain cases, such as the roll-out of a common system or other technology infrastructure across divisions, the methodology and experience of the first implementation may be packaged for repetition across sites, hopefully leading to lower risk and shorter cycle times for subsequent waves of implementation.

Key competencies of the PO include:

Experience in large-scale project management - the PO must have the “gray hair” gained from a range of comparable efforts.
Metrics fluency - the successful PO will understand the state of the art in project metrics and will be experienced in the application of metrics to project management issues.
Industry best practice awareness - the successful PO knows what works (and what doesn’t). Specific expertise in key process areas (such as requirements definition, systems design, inspections, testing, etc.) will be needed, but may not be full time within the team - these resources may be contracted or temporarily drawn from existing resources.
Communications skills and diplomacy - the effective PO can facilitate real communication under potentially hostile circumstances.

Structure of the Project Office

Scenario 1: A multi-divisional organization decides to consolidate diverse systems into a common integrated package. Concurrently, a process re-engineering project is initiated to establish common business practices. Two contractors are hired - one to support the re-engineering effort, one to implement the common package. Both contractors will incorporate divisional personnel in their respective project teams. A line executive manages the process redesign and the CIO leads the IT portion.

As might be expected, there are many opportunities for conflict and confusion. When the conflicts among these various interest groups begin (about an hour after the project starts) the executive sponsor of these initiatives must find a way to sort out the conflicting claims and clarify boundaries.

In this instance the Project Office should be established as a staff function reporting to the executive sponsor of the overall effort and providing support and advice to both the CIO and to the executive responsible for the re-engineering effort. The Project Office acts to ensure adequate planning, with particular emphasis on clarifying inter-dependencies among the teams. The Project Office attempts to function as an “honest broker” that will diligently search for common ground among the various interest groups whenever possible.

In a situation such as this, the contractors may attempt to kill one another off in order to secure all of the business. The CIO and the re-engineering executive may disagree over strategy. The divisional personnel may secretly (or even openly) prefer that the entire initiative fail. The sponsoring executive typically lacks both the specific expertise and the time to examine all of the many conflicts on their merits - frequently resulting in “political” decisions and a death spiral of distrust.

The Project Office acts as an advisor on industry best practices and provides objective, independent, data based perspectives on the issues as they arise. In addition, the experienced Project Officer anticipates issues before they arise and provides counsel on preventive measures. In this scenario the crucial element is planning.

Scenario 2: As a consequence of de-regulation, a large organization is faced with the need to reduce costs by 20% in order to be competitive. A re-engineering contractor is hired to identify opportunity areas. The resulting plans call for substantial head count reductions to be enabled by major enhancements to the IT infrastructure. Aggressive cost targets and dates are established, top-down, which imply massive IT changes within a three-year period.

Total size of the IT effort is not known, but certain assumptions (guesses, really) are made which suggest a need to increase IT staff by 50% over the first 18 months of the initiative. Grave doubts exist as to the feasibility of such a large increase. Pressure builds to out-source parts of the IT work.

A contractor is hired to perform a capability assessment of some of the initial projects. Estimates and schedules are independently reviewed. These assessments indicate project schedules have been unreasonably compressed and are unlikely to be met. It is also determined that more than half of the proposed initiatives have not defined requirements sufficiently to permit sizing, and hence effort and schedule estimates are vague. A Project Office is recommended.

In this instance the Project Office should report to the executive responsible for the overall transition effort. The Project Officer will establish advisory relationships with both business and IT executives and will put together a team of IT, business and outside experts to assess and support key process areas. The most urgent task will be to determine the true scope of the requirements to enable preparation of a sourcing strategy. Clearly this initiative cannot succeed unless resource needs are fully known soon enough so those resources may be secured in time to accomplish the necessary work within the three-year time frame.

Under this scenario the critical roles for the Project Office include scoping and status monitoring.

Scenario 3: An organization decides to out-source the entire IT function. A systems integrator commits to a fixed price contract that guarantees a certain level of “work” over the duration of the contract. Productivity improvements are built into the contract with associated penalty provisions if they are not met.

In this case the customer is represented by a small group directed by a seasoned IT executive with responsibility to manage the out-source contractor. Responsibilities include measurement of contractor performance relative to contract commitments.

In this instance the monitoring group does not include specific expertise in measurement. It quickly becomes clear that measurement issues are complex and carry the potential for serious conflict between the customer and the contractor. The monitoring group and the contractor agree to hire an independent metrics expert to define the required measures and provide on-going advice on their interpretation and application. The metrics contractor becomes a sort of “mini - Project Office” reporting jointly to the customer and the contractor.

Literally hundreds of scenarios exist which could effectively employ the Project Office concept to increase chances for success in major initiatives. The common factor in all of them is a rapid move to a “new level” for both the customer and the IT organization - “going where we’ve never gone before”. A small group of high-powered helpers who have been there before can save lots of grief!