The mythical project office--practical ideas to help IT project offices succeed

James M. Peters, SoftwareMatters.com, Inc.

William J. Honeyman, Computer Associates,

Myth—“A person or thing having only an imaginary or unverifiable existence.”

Mythical—“Having qualities suitable to myth.”

Several years ago I was implementing a software tool within a project office organization. The nature of the tool required a thorough understanding of their organizational structure and the project reporting requirements. As I delved into the structure of the organization it became obvious the project office managed and directed the project managers. The project managers belonged to the project office. The business units sought the best managers for their projects. The project office assigned the project managers based on the needs of the projects and the availability of the project managers. The organization had mixed the best aspects of a consulting model with the need to maintain the organizational expertise that the internal project managers offered. And it all seemed to work. Often, ways of organizing business such as the project office achieve a certain mythical nature, they are discussed as if they are real but are imaginary. And to actually verify their existence is beyond the ability of the practitioner. Seeing a successful “all purpose” project office organization turned ideas that had been mythical into tangible realities. Knowing it had been done successfully gave me an assurance that it could be repeated by mere mortals.

Our intent is not to provide the ultimate Project Office structure for Information Technology (IT) organizations nor is it to expound on the virtues of any given organization. Our focus is to define the context of IT project offices, identify areas that are critical to the success of Project Offices and present techniques that have worked in the real world to help organizations develop and implement quality IT solutions.

Underlying any discussion of project offices are the forces that drive the need and the structure of project work within an organization. Answering the following questions will help put that work in context.

1. What is the nature of Information Technology work?

2. What is the organizational context of project offices?

3. What are the mission and objectives of the project office and how do these affect the structure of the project office?

The purpose of project offices range from organizing project work to correlating IT work to business needs to scheduling resources to tracking costs to finding silver bullets. Fulfilling the variety of purposes for Project Offices has resulted in a wide variety of organizational structures. Frequently the names are the same for organizations whose missions are radically different and just as frequently different names are given to organizations with very similar missions. To ease communication the variety of Project Office structures will be reduced to four fairly arbitrary types.

The Method

The current paper is based on the ideas gleaned from the experience of the authors in working on project teams, managing projects and development groups, implementing project management and control tools, and watching organizations. The credential the authors have that is fairly unique is that we have both participated in the implementation of enterprise project management and control software in numerous organizations. A great benefit of adding a tool to someone’s tool chest is that you get to see the other tools they are using for the job. These organizations either had well established project offices or were actively developing some form of project office. Many of the good ideas we might lay claim to are actually theirs.

An exhaustive literature search was not performed but numerous reference materials were utilized in the validation of concepts and in transforming some of the best practices referenced into useable tools. Since the focus of the paper was on practical ideas for IT project offices, much of the material either did not apply directly to IT or applies but is still more theoretical than practical. But there are some great project office insights and practical ideas found in books such as “The Project Office” by Thomas Block and J. Davidson Frame or “Project Portfolio Management” edited by Lowell Dye and James Pennypacker.

Gathering ideas from practitioners in working project offices was done with a series of interviews. A questionnaire was developed to facilitate the interview process (see Exhibit 1). The intent of the questionnaire was to elicit the stories behind the project offices and the techniques and ideas that worked for others. Much of the initial response to the interview questions has been incorporated into this paper but the number of interviews completed at the time of this writing is not sufficient to make any interesting claims of common practices shared by all successful project offices.

Exhibit 1. Project Office Interview Questions

Project Office Interview Questions

The integration of personal or organizational experience and knowledge, the experience and tools provided by practitioners and educators in numerous publications, and the focused interaction with other professionals on what has worked for them provides has provided a workable framework for our research. It is also the first strategy that we recommend for the development or improvement of project offices.

The Nature of Information Technology Work

Understanding the requirements for and the products of an IT project office requires an understanding of the typical work that is done within information technology organizations. Consider the following scenarios:

Joe’s connection to the network does not work …

The HR system will not handle the compensation package required by a new law …

The MRP system is inefficient and costs too much to maintain …

Canadian postal codes are not printing correctly from the sales contact system …

The network is outdated and needs to be replaced …

The fixes made to the general ledger system have failed for the fourth time …

The voice and video traffic is making a departmental server crawl …

Acquisition of new business unit requires systems integration …

Vendor no longer supports mainframe utilities in use …

A new product is being rolled out requiring a support help desk …

This is the world of IT. The resolution to these scenarios could be development of systems, replacement of hardware, updates to software, procurement of software or hardware, development of better methods, etc. The resulting work includes both major projects and minor projects, urgent needs and future needs, some supporting strategic goals and some supporting tactical objectives. Some of the work is directly related to the products of the organization and some is several steps removed. The role of the project office with respect to this work will vary with the mission of the specific project office.

Identifying or defining the relationship of the project office to the IT work is essential. A simple technique to begin defining this relationship is mapping the work of IT to the functions of the project office. For example, in the scenario, “The fixes made to the General Ledger system have failed for the fourth time …” a quick list can be created of possible project office functions related to the solution of this issue. Rephrasing the scenario as a question and answering it could result in the following list.

What is the project office role with respect to the issue “The fixes made to the General Ledger system have failed for the fourth time …”?

1. The project office may define the standard for release of changes to systems.

2. The project office may define the process by which work is initiated.

3. The project office may manage the project manager.

4. The project office may identify resources with the skills to perform tasks on the project plan.

5. The project office may define the quality measures that caused the issue to be classified as a problem.

A common understanding of the IT work and the possible project office roles can help to clarify the mission and the project office and eventually help determine the services and products that need to be offered by the project office.

Exhibit 2. Hypothetical Organization Chart

Hypothetical Organization Chart

The Organizational Context

In addition to the need to understand the work, it is necessary to understand the organizational structure within which the project office operates. A hypothetical information technology focused organization chart is shown in Exhibit 2.

The arrows on in the exhibit point to some of the locations within the organization that an IT project office might be positioned in the reporting structure. All five of the locations specified within the organization could be reasonable for a project office related to manufacturing systems. A project office whose mission is to coordinate the implementation of a new MRP system could reasonably placed in positions 1, 4, or 5. The project office tasked with leading the organization in becoming a level 4 in their software process maturity might be placed in positions 2, 3 or even 1.

Often the position of the project office within an organization is set before the mission of the project office is determined. An Information Systems Quality Assurance group that is designated as the project office for all information systems is likely to be in position 2 of our hypothetical organization chart, reporting to the CIO. The ideal world may dictate that position 1, reporting to the CEO, would be better due to the coordination necessary of all IT work for all divisions in the company.

Combining the nature of the IT work and the organizational context provides a view of the enterprise that is useful in developing the products and services of the project office. Before these products and services can be defined the mission or purpose of the project office must be understood.

The Mission of the IT Project Office

The mission of the Solutions Center at Eli Lilly is “to produce quality systems with low defects in short periods of time to support the business.” The mission of many year 2000 project offices was to prevent interruption or losses to the business due to the issues related to the year 2000. The mission of project offices dedicated to the implementation of a major financial or ERP system is the successful implementation of the financial or ERP system. The mission of many project support offices is to provide the key decision makers with accurate, consistent data on the planning, scheduling, and tracking of all IT projects.

Though the mission of each of these project offices is different, the techniques used in accomplishing the goals may have a significant amount of overlap. All of the project office types could use the weekly collection of effort, cost, and status data as a technique to help in achieving the goals. Conversely, there are many techniques or tools that are appropriate for a project office whose mission is quality improvement that does not apply to the temporary project office (e.g., the ERP implementation project office). Coordination and delivery of project management training is usually controlled by an organization that is not focused solely on one product.

The activities supporting the implementation of a new financial system may involve the management of all projects related to the financial system, the reporting to key stakeholders on the status of the project. Accomplishing this may require training, administrative support, reporting systems, etc. But everything is focused on the one objective, implementing the system.

What becomes apparent is that there are different types of project offices and every one has its unique aspects. Combining the mission with the nature of the IT work for the organization and the organizational context provides a basis for determining the activities of the project office. The combination of these aspects also provides us with the ability to classify the general types of project office types.

IT Project Office Types

It is difficult to get a handle on the common themes behind project offices given the variety of reasons project offices are created and the contexts within which they exist. Since the work of the project office is directly related the mission and context behind the project office it is helpful to identify the types of project offices. For simplicity sake we have defined four types of project offices for the purposes of this paper.

1. Project Support Office (PSO)—Provide administrative support for project selection, tracking and reporting. Examples include a Quality Assurance group that is given ownership of the project control tool and the change control process but has little involvement with the project work being monitored. The PSO role is primarily external to the project work of the IT organization.

2. Project Management Office (PMO)—Provide project support office functions and provides staff in key roles in the management of projects. An example would be the professional services organization for a consulting firm where the project management office supplies the project manager for all projects. The role is primarily internal as it relates to any given project.

3. Program Office—Provide initiative or program coordination or ownership. Examples include Y2K project office or the program office for a major system implementation such as SAP. Often, very large system development projects have a program office that controls all aspects of the project. The program office can also be viewed as a super project. The program office follows the project lifecycle and will come to an end once the purpose is fulfilled and the work transferred back to the other groups within the organization.

4. Project Office—Provide project support office functions plus methods development, and project audit, resource allocation, and project consulting roles. The project office may also manage the project managers similar to the PMO. The differentiating aspect is that the project office is more consulting or mentoring oriented. The role of the Project Office in projects is a combination of both the external roles typified by the PSO and the internal roles typified by the PMO. Of all of the types the Project Office is the most likely to include “portfolio management” as one of its key roles.

References to the project office in lower case will be general and not specific to one of the types introduced above. Differing views on the subject may place the Project Office under the Program Office where the Program Office would have reporting to it several Project Offices. Even the acronym used, PMO, is used in other places for either the Project or the Program Management Office. The classifications listed here been made for the purpose of simplifying the discussion of the activities carried out by the project office.

The Work of the Project Office

Understanding the types of project offices and the nature of the IT world may help in the development of the project office project charter. It does not provide you with the foundation of what to do and when to do it. Successful implementation of project offices requires an understanding of the work that is done and the deliverables that are produced.

Much of the work of the project office is cyclic. There are two primary cycles that the project office lives by; first the time cycle, and second the project cycle. Activities that relate to the time cycle are the processing of timesheets or the generation of monthly reports. Activities relating to the project cycle are coordination of project selection process, or mentoring project managers in use of a scheduling tool. Many activities do not fit as neatly into a cycle. These include activities such as administering a project management and control software tool, implementing a measurement program or creating a systems development method.

While there are numerous tasks performed by any project office listing a few of these will help put the work in context. The following are those that are frequently identified with more extensive project offices.

Timesheet generation

Timesheet processing

Project Management/Control Tool Administration

Project Management/Control Tool Selection

Develop standards and procedures

Audit Projects

Coordinate change control board

Design/Develop management reports

Coordinate project meetings

Allocate resources to projects

Forecasting for the IT organization

Generate weekly management reports

Generate monthly management reports

Review project documentation

Project quality assurance

Generate project status reports

Develop methods

Coordinate steering committee

Monitor PM certification

Deliver PM tool training

Budget preparation

Procure PM Training

Procure PM Tool Training

Deliver training

Schedule Projects

Generate project exception reports

Maintain project reporting code tables

It is useful to view this work is in the weekly cycle within which many of the tasks are completed. Typical weekly cycle oriented activities are shown in Exhibit 3. Some of the key project manager or project team member activities are shown in bold. This view is useful to help everyone involved to understand of what must be done by whom for a simple weekly project time accounting process to be successful. Placing names or roles on the activities in a chart like this ensures that the roles are clear.

Another view of the work is the deliverables that must be produced. The following is a list of sample deliverables that are produced by the project office.

Organization Specific Project Management Methods

Organization Specific Software Management Methods

Time Accounting Standards

Project Approval Process Standard

Exhibit 3. Project Office Cycles

Project Office Cycles

Earned Value Reports

Training Program Design / Implementation Plan

Management Reports for all Projects

Design / Implement Metrics Program

Internal PM Certification Process

Risk Assessment Procedures

PM Tool Selection Study

Quality Assurance Guidelines

Project Exception Reports

Resource Utilization Reports

One of the important things to note is that much of the work of the project office has been expressed in terms of standards, methods, and reports with a few studies in the mix. Much of the day to day work that makes this possible is done in detailed data collection, coordinating the cross functional teams in methods development, preparing for and coordinating the steering committee process that selects and prioritizes projects. Add to this mix the objective of many project offices to act as project consultants and mentors to raise the general level of project management capability within the organization. The mix of all of these aspects of the project office often results in a set of requirements for the project office that is beyond the scope originally anticipated. Fortunately, we are all project managers and dealing with scope problems is just one of the things we do.

Project Office Organization

The possible work the project office may be involved with is very broad. One organization interviewed organized the work into three groups; the project management and control tool group, the methodology group, and the Training group. Using that as a model for our sample we have filled in some of the activities for which each group is responsible. The sample organizational framework using this approach follows.

Project Office Group

1. PM Tool Group

a. Project Initiation / Workflow Control

b. Tool Support

c. Reporting

d. Tool Training / Mentoring

2. Methodology Group

a. Writing Standards and Procedures

b. Developing Systems Development Methodologies

c. Developing templates for standard methods

3. Training Group

a. Project Management Training / Mentoring

b. Methodology / System Development training

c. Project Management Certification monitoring

The methods group is focused on standards and the conceptual side of how work should be approached. The Training group is focused on the training of project management and the methodologies developed or adopted by the organization. The tool group is focused on the software used to support the PM methods adopted by the organization. An extension of this outline would be to insert the work activities and the deliverables listed in the prior section in the appropriate position in the outline.

Project Offices Key Practices

The final three questions of our initial questionnaire attempted to capture best practices of the project offices that were the focus of the interviews.

What are the top five things the project office does to support organizational (or enterprise) objectives?

What are the top five techniques or tools used by the project office to further the objectives of the project office?

What are the successes or failures of the project office that may help others to succeed?

The research of the authors was not intended to produce a definitive list of best practices for the project office but instead to begin building a set of practices for use in the project office tool kit. Some of the answers to the questions are listed below.

Selected Best Practices

a. IT workflow coordination and control. The project office should own the process by which work is identified, defined and prioritized. It should also administer the logging and tracking process.

b. Develop Project Management standards by which everyone works. Developing a common internal language and a common approach to project management eliminates many of the communication issues. Standards should be developed for the Project Initiation process and other key processes.

c. Enterprisewide project management and control software tool.

d. Capture actuals (hours and status) data for all project and non-project work.

e. Develop project management standards and procedures by which everyone works. Some standards that should be considered are:

1. Project selection/prioritization process

2. Project coding standard

3. Project management process guidelines

4. Development methodologies

5. Time / Status reporting standard

6. Performance measurement related standards and guidelines

f. Utilize a common set of tools peripheral to project management tools that facilitate common reporting, the sharing of project information, project discussions. Use the Internet or intranet for communication.

g. Reports, reports, reports … the kinds of reports the project office should provide or make available include:

1. Project status

2. Project forecast

3. Project backlog

4. Project audit

5. Resource utilization

6. Resource forecast

7. Executive summary

8. Key indicator reports

All of the above report types assume that all project cost, effort, and status data is available in a consolidated format such as a database. The medium for delivering these reports may not be a traditional report but instead a view in a decision support tool or a web page in the project office web site.

h. Have good application development tools and testing tools. The project office is often in a key role to facilitate the selection process due to its frequent role in working with multiple development groups within the IT organization. The methodologies and standards are often closely tied to the development environment.

i. Develop internal project management best practices. The collection of best practices used within the enterprise can provide project managers with new tools to use and the project office with insights into the skills of the project managers. Two references containing samples of software development related best practices are available. Steve McConnell’s, “Rapid Development,” has numerous best practices for software development in general but many of these are applicable to the activities of the project office. “The Program Manager’s Guide to Software Acquisition Best Practices” lists numerous best practices with their appropriate use and value. Internal best practices have the advantage of having the people that utilize or develop the practice available to train or mentor others in the use of the practice.

The interesting aspect of responses to these questions was that there was little mention of mentoring and coaching and project management training in the best practices. This was certainly a key portion of the work done by the project offices responding to the questions but the best practices given focused primarily on either the measurement activities of the project office or the establishment of an environment where project management could be successful. Expected responses like “establish a great training program” or “establish an internal consulting group” did not get mentioned. The activities that facilitate communication of project data to management and to project managers were the areas where significant project office effort has been placed.

Conclusion

The implementation of a project office is a project just like any other. And just like any other project the chance of success is greatly increased by having experienced or seen the end result, the project office, in production. The glimpse we have provided of the context within which project offices exist and the glimpses into practices that others have used successfully is a way of saying that there are IT project offices that are real, not mythical, and there are many practitioners whose knowledge can be invaluable. Sample implementation plans, standards and procedures, or report samples are typically too sensitive for most organizations to share with outsiders but many are willing to share their knowledge and experience. Capturing their knowledge using a formal method such as a formal interview process may help to reduce the risks to your project office.

References

Adams, John R., & Cable, Dwayne. (1982). Organizing for project management. Upper Darby, PA: Project Management Institute.

Adams, John R., & Campbell, Bryan W. (1982). Roles and responsibilities of the project manager. Upper Darby, PA: Project Management Institute.

Block, Thomas R., & Frame, J. Davidson. (1998). The project office. Menlo Park, CA: Crisp Publications.

PMI Standards Committee. (1996). A guide to the project management body of knowledge. Upper Darby, PA: Project Management Institute.

Dye, Lowell, & Pennypacker, James, (eds.). Project portfolio management. West Chester, PA: Center for Business Practices, A division of PM Solutions, Inc.

McConnell, Steve. (1996). Rapid development. Redmond, WA: Microsoft Press.

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 or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA

Advertisement

Advertisement

Related Content

  • PM Network

    Empathic Problem-Solvers registered user content locked

    By Mustafa, Abid As the digital revolution continues to sweep through organizations, there is a real danger that enterprise project management offices (EPMOs) will be left behind. EPMOs traditionally have excelled…

  • PM Network

    The 24/7 PMO registered user content locked

    By Vukosav, Denis The project manager in the United States welcomes the team to an important meeting. For him, it’s early morning. But it’s midday for the team members in Ireland, late afternoon for those in India…

  • PM Network

    Premium on Digital registered user content locked

    By Fister Gale, Sarah Like any organization in a legacy industry, insurance companies have to meet digital disruption head-on to stay competitive. For Triglav Group, that means balancing growth and change amid industry…

  • Project Management Journal

    Project Management Practices in Private Organizations member content locked

    By Tereso, Anabela | Ribeiro, Pedro | Fernandes, Gabriela | Loureiro, Isabel | Ferreira, Mafalda This article aims to make a contribution to theory, as well as to practice, by identifying which project management practices are used by most private organizations in general and by sector of…

  • PM Network

    Change Agent in Plain Sight registered user content locked

    By Mustafa, Abid Digital transformation fatigue is setting in. After years of backing tech overhaul initiatives that fail to realize some or all promised benefits, some organizations are losing their appetite for…

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.