In-Depth

The project office answer

• By Lois Zells
• July 24, 2001

Projects! We cannot live with them; and we cannot live without them.

Yet, there continues to be a persistent demand for software-driven project endeavors. To make matters worse, as the need for projects keeps increasing, the success rate persists in falling. A 1994 survey of 365 small, medium and large companies by The Standish Group International Inc., Dennis, Mass., showed some remarkable results. The Standish CHAOS Report found that:

• Over half of I/S projects cost almost twice the original estimates;
• Almost one-third of I/S projects are never finished;
• Slightly more than 15% of I/S projects are completed on time and within budget; and
• Almost half the I/S executives surveyed think there are more project failures today than five years ago.

Moreover, the costs associated with finding technically proficient resources continue to rise while new skills availability does not keep pace with demand.

Huge sums of money have been spent on methodologies, new technology platforms that promise rapid development, tools, training and so on, in response to these problems. Sadly, few of the cure-alls have lived up to the promise; and many organizations are still no closer to solving project problems than when their quest was started. Accordingly, executives are driven to search harder than ever for ways to achieve a higher return on project investments.

The dedicated team structure The ideal project team structure calls for all members to be 100% dedicated to, and "owned" by, the project. Fig. 1 Source: Lois Zells & Associates Inc.

Project organization is an apt area for management to focus first. Recently, many enlightened groups have come to realize that project success is often significantly related to team structure. Currently, there are three popular approaches to creating teams: it is possible to dedicate staff to a project; team members may be matrixed to the project manager; or the company may create a project office.

Dedicated project teams

The ideal project team structure calls for all members to be 100% dedicated to, and "owned" by, the project. (See Fig. 1.) There is a clear understanding of how each resource fits in the group. The hierarchy is easy to understand. Financial and career destinies are usually controlled by the superior position. Lack of loyalty is rarely a problem. The lines of communication are clearly drawn.

Managing in this team structure is like working in the paradise of project management. Unfortunately, it is not the norm, but one that is typically invoked only on mission-critical projects.

Matrix management

Since there are rarely enough available resources to dedicate to each project, the matrix structure has commonly become the default form of project organization. (See Fig. 2.) Yet, matrix management has also been a major cause of disappointing project results.

Matrix management The matrix structure is commonly the default form of project organization; yet, matrix management has also been a major cause of disappointing project results. Fig.2 Source: Lois Zells & Associates Inc.

In matrix environments, there is an unusually intense competition for the best resources; and, of course, there are rarely enough resources to "go around." As a result, many project teams find themselves having to "make do" with available resources. In other situations, the best resources often find themselves incredibly over-scheduled.

From another perspective, the unfortunate team members are frequently the objects of a tug-of-war for their participation.

As workers, they may get one set of directions from their functional manager. As team members, they hear something entirely different from the project manager. Furthermore, it is not unusual for both sets of requests to be in conflict.

This is the most pernicious aspect of matrix organization. It begs the question of who really owns the resources. The usual answer is the manager who truly controls the salary and career destiny of the worker. Loyalty thus becomes a confusing issue for both workers and managers.

To compound the problems, the poor project managers are often buried so far down the organizational ladder that many team members are actually their peers. What is worse, some of the needed resources may even be higher up in the company than the manager. As a result of both the "dotted line" reporting structure and poor organizational positioning, project managers may have little to no authority over most resources. Yet, they are often held accountable for the success or failure of a project over which they have little control.

On occasion, this structure does work! However, its success is generally due to the negotiating skills, political savvy or manipulative powers of the team leader. Thus, it is not a reliably repeatable process, merely one that banks on individual personalities. In today's competitive business environment, that is just not good enough!

Why the project office?

The entire matrix scenario is exacerbated because it must be repeated for every project that is contending for team members. This is called the multi-project, limited resource (MPLR) environment. In an MPLR setting, few organizations have an accurate understanding of the number of projects underway at any given time, let alone a precise grasp of resource allocation and availability.

Managers in this setting may intuitively recognize the problems; but they find it difficult to identify where the conflicts are occurring. Uncovering the means of resolving the disunities remains an even greater mystery. Hence, many businesses are discovering that a new organizational structure, called the project office, can be a key to solving such issues of this kind.

In a well-implemented project office:

• The selection and approval of projects is driven by business priorities rather than politics or emotions.

• The use of standard, repeatable, reliable project practices allows better communication and more important, better control and predictability of outcomes.
• In-house project management expertise acquired at a high cost to the organization -- and that has heretofore been lost due to promotions -- is better utilized. As a result, productivity is improved.

• The risks of developing in an ever-changing environment are significantly mitigated, sometimes even eliminated.

The creation of a project office has usually been limited to important endeavors such as medium-sized to large, mission-critical projects. In its simplest definition, a project office is a meeting room that is dedicated to a single, specific project. Other times, a separate workplace that is set aside for team members is called a project office. The definition can also describe a single project's management team. The meaning can be extended to include the processes used to manage projects. In another instance, the project office can refer to the people who perform the project management administrative tasks, thereby freeing other members to concentrate on development.

A unique variation on the project office for a large, mission-critical project may be found in the year 2000 environment. In this case, the project office can play an essential role in the management and coordination of many projects -- all the compliance efforts competing for scarce resources.

In the MPLR environment, two other forms of the project office surface: (1) a group of experts in project management that serve as internal consultants to multiple project teams; and (2) a more structured and powerful implementation called the cross-functional project office (XPO).

As consultants, internal project management experts may only support the few mission-critical projects in the company. In this case, there is a minimal requirement for project office personnel. On the other hand, the experts can be chartered as available to all project teams in an organization, thus requiring greater staffing.

The cross-functional project office

Implementing the project office examples described above will certainly bring about some of the desired benefits. But, to gain an even higher return on their project investments, organizations can build a broader franchise -- the XPO. What follows is a consolidated profile of the best XPO practices found in many organizations. Each of these groups asked not to be identified.

The cross-functional project office The cross-functional project office should be positioned at the top of the organization, where it has the positioning and visibility necessary for potency. Fig. 3 Source: Lois Zells & Associates Inc.

Positioned at the top of the organizational structure, the XPO should be unencumbered by rigid territorial boundaries, should have the positioning and visibility necessary for potency, and should have unlimited access to the global business perspective. (See Fig. 3.)

The XPO is staffed with talented members from each functional area that can impact project outcomes. Project Management experts and software development experts must also be part of the XPO. These consulting positions, often accompanied by job grade and salary increases, can frequently represent professional advancements for individuals whose careers may otherwise be blocked.

As internal consultants, the XPO members continue to work as teams. However, the charter is much broader than simple consulting.

Major XPO functions are:

1. providing the decision-making data used for project approvals;
2. monitoring project prioritization;
3. monitoring resource allocation and availability;
4. coordinating and consolidating project planning and tracking efforts;
5. performing project risk assessments;
6. overseeing the development of repeatable project practices; and
7. maintaining the organization's project history file.

When project candidates are identified, the members of the XPO prepare project plans that show high-level estimates of time, cost and resource requirements. Given that the team members have the expertise, this exercise can be completed alone. However, team members frequently seek participation from functional counterparts. The data from these high-level estimates is presented to upper management to help them to make informed decisions about initiating projects and allocating team members.

The functional heads of an organization serve two important purposes in the implementation of an XPO. The roles are: (1) to act as members of the project steering committee; and (2) to act as subcontractors charged with providing project personnel.

The steering committee, which includes the functional managers and the general manager, works with the XPO to select and approve projects for initiation. They also decide whether a project is terminated. An application portfolio management approach is a good way to make these decisions.¹

Application portfolio management gives the right perspective to project prioritization. A major problem in the project management arena is that many workers have more than one top priority project, where the current top can shift like eddies in a stream. Worse, these projects also compete with the real work of keeping a company running. To solve these problems, it is necessary first to prioritize each project in relationship to all other projects and to existing business. Only after this ranking of the projects is completed can intelligent decisions be made about resource allocation.

In addition, the steering committee is responsible for other functions such as:

• the alignment of all project priorities to the corporate strategic direction;¹
• the communication of this alignment to the workers; and
• the resolution of any priority or resource conflicts that cannot be resolved at lower levels.

Most important, functional managers assume the role of subcontractors who provide members for project teams. These managers are the major individuals in their respective business units who can decide on:

1. the time required to satisfy departmental work requirements; and
2. the time that is left over as available for project work.

Thus functional managers should only make commitments when they know that they have enough available internal or contracted personnel to satisfy requests. Subsequently, they are accountable to the general manager and to the XPO for ensuring availability of resources for all the projects to which they commit.

Yet, in the MPLR environment, functional managers may have little knowledge of the precise number of projects underway, either in or outside their direct areas. Even when there is a way to identify and prioritize a complete list of potential projects, it is almost impossible to see exactly where each individual is working, to recognize and resolve resource conflicts, and to determine how much time is available for new assignments.

In an ideal environment, all of the necessary project data and the resource calendars reside in a central repository. Slicing and dicing the data needed for decision-making should be an easy-to-implement exercise. Several project management software tool vendors (such as ABT Corp., New York City, Micro-Frame Technologies Inc., Ontario, Calif., Microsoft Corp., Redmond, Wash., and Primavera Systems, Bala Cynwyd, Pa., offer repository-based products that can address these issues to varying degrees of sophistication. Furthermore, most vendors now realize that this application is a most important key to successful enterprisewide use of their products. So, vendors that do not support repository technologies yet, will -- and soon!

Planning and monitoring projects

Since project teams should not have to "reinvent the wheel" each time a plan is created, repeatable templates should be provided by the XPO. Here, again, a central repository is essential. There are several providers of repository-based project process templates, such as Arthur Andersen, Chicago, LBMS, Houston, and James Martin and Associates, Reston, Va.

Once the team participants are assigned to a project, the XPO helps them develop their respective detailed project plans. The XPO also ensures that all project interdependencies are correctly reflected.

The completed plan details are taken back to the steering committee for approval. Each functional manager is then pledged to delivering a part of the plan. These managers ensure that their personnel commitments are managed and fulfilled and that status is reported to the XPO.

The XPO, in turn, monitors progress and identifies problems. They work with the functional managers to resolve issues. Any difficulties that cannot be resolved are elevated to the steering committee.

It is necessary to have software support that can extract data from individual project plans and store that information in the repository. These products need to consolidate, sort and present decision support data to management. The data will enable executives to make judgments about resource shifting and whether a project should proceed. The extracted data becomes the foundation of the project history file; which is used to improve project processes such as estimating and tracking.

Requirements for success

Regardless of whether an organization implements a project office for a single, large project -- like for the year 2000 efforts -- for providing internal consulting or as an XPO, the requirements for success remain the same.

Executive management must not only "talk to talk;" they must also "walk the walk" by continuously and visibly demonstrating a commitment to the project office. Without such a commitment, the effort will simply degrade into a meaningless exercise, leaving participants frustrated and hopeless. The bottom line is that management commitment must be strong and must be perceived as such by employees.

The positioning of the project office within the corporate organizational structure is the next most significant requirement. The placement of the group sends a clear message about the importance executives place on the project management function. If the project office is buried in the lower echelons of a corporation, the entire group can question the management commitment to getting control of projects.

Also essential to success is adapting the view that the corporation's applications are key assets and will be managed as a portfolio.¹ Project prioritization and resource allocation should be made accordingly.

Next, metrics play a very important role in the process. Critical success factors and their measures should be developed for:

1. judging the successful implementation of the project office:
2. judging general project success; and
3. judging the improvement over time of the project process.

Members of the project office also must work with project teams to develop critical success factors specific to each project.

Additionally, it is essential to recognize that, when push comes to shove, people will do what they are measured against. Consequently, it is important that an organization's performance review system be adapted to reflect realistic expectations for project success. Rather than punish people for not making estimates that were provided too early in the project, it is better to reward them for improving the estimating process.

Finally, there are other requirements for this project management approach, such as the need for adequate funding, enterprisewide project management awareness and participation, administrative support, skills development, marketing and rollout strategies.

Organizations that are looking for the quick fix should not consider this approach. Managers are often surprised at the effort required and they are astonished at its scope. Perseverance, organizational commitment, personal dedication, vision and courage are required as each new challenge arises. Nevertheless, the rewards are great. In today's project-driven business climate, this may be the most important path to project success.

Reference

1. Zells, Lois. "Practical strategic I/S planning," Application Development Trends, April 1996.