| PM Network | May 1997 | page 33 |
PM Network May 1997 page 33
by Richard E. Murphy
EARLY PROJECT SCHEDULING and resource leveling software was the province of "specialists"; thats why the first Project Support Office (PSO) operations appeared with the advent of computerized project scheduling techniques in the early 1960s. The projects of that time were large and complex ones. mainly in the engineering/construction and aerospace fields. A Project Office staffed by those knowledgeable in CPM techniques and the use of computer software was essential to assist the project manager in planning and monitoring his or her project.
Beginning in the mid-1970s the PSO concept began to be questioned as more "user-oriented/controlled" project management software became available. Some organizations eliminated the PSO function as individual project managers and team members became comfortable with operating the new software, which gave them complete flexibility in terms of reporting formats and update cycles. In particular, the introduction of graphical reporting techniques during the '70s gave functional department-located project team members the "impact" hype of com- munications mechanism that was greatly appreciated by upper management. The flexibility and ease of use of the new software expanded the base of potential users and minimized the need for the specialists who previously staffed the PSO. In actuality a new breed of specialist was created during this period, with a new or- ganizational alignment: the functional group performing project work.
This trend greatly accelerated in the 1980s with the introduction of PC-based project management software. Suddenly everyone was empowered to do the things previously in the specialists domain. It was easy to create and monitor project schedules-perhaps too easy! Some users, however, lacking a fundamental under- standing of project management principles, created and monitored schedules that resulted in "pretty pictures everywhere," but not necessarily better project management.
As we entered the 1990s, corporate management recognized the need for better project management expertise at all staff levels, and many organizations began to resurrect the Project Support Office concept, but with several key differences The first incarnation of the Project Support Office dealt almost exclusively with single, large, complex projects. The new PSO is more likely to be a multiproject or program-oriented function. The projects of today are in most cases smaller than those of 20 and 30 years ago and they are much more manageable and controllable, given accurate and timely data. The PSO operation has therefore become a more valuable resource. Additionally the scope of services offered by todays PSO has expanded significantly beyond operation of scheduling software This has occurred because organizations today have recognized "managing by projects" as a core technique for efficient operation.
Many view their project management operation as an enterprisewide strategic in- formation system, much as they do accounting and human resources.
Why Have a PSO?
The PSO concept has some significant advantages compared to the alternative approach of controlling projects by relying on the traditional functional department/division approach.
The pure functional approach has inherent disadvantages. Functional boun- daries impede cross-functional business change. Specialist skills are usually locked in specific functional groups. Support systems tend to be department centered, rather than process centered. There is unclear ownership and accountability of project goals. Performance measures are usually static and historical, rather than forward-looking.
The PSO approach offers certain advantages: an organizational structure aligned with cross-functional change; a global view of resources; skills focused on strategic goals; clear ownership and accountability of project responsibilities; and performance measurements that are dynamic, predictive and forward-looking.
Exhibits I and 2 illustrate the traditional structure and one type of PSO-based structure.
While it is certainly true that a functional approach can be successfully implemented in some situations, there are certain cases in which a PSO operation should be considered very seriously. Some examples are an organizations first implementation of project management methodology; a very large, complex, resource-limited single project; a large multiproject environment; or a managing-by-projects implementation. For IT projects implementation specifically a situation where the IT organization has been viewed as unresponsive, could be another candidate for this type of organization
A New Approach: Managing by ProjectsIn the past few years business process reengineering has spawned a concept of managing by projects. An inherent outcome of BPR is that organizations begin to view all changes to their business processes as "project oriented." Organizations committed to the managing-by-projects philosophy categorize all activity as "projects" in either "change" or "operational" categories. As illustrated in Exhibit 3, the concept of managing by projects affects all aspects of a business, beginning with the development of corporate strategy and continuing through the strategic and op- erational planning cycles.
While most staff understand the meaning of project when applied to traditional operational project planning and execution, projects that change the way an organization functions are perhaps more critical and require significantly more planning, monitoring and auditing because they are concerned with fundamental changes to the business processes of an organization. The potential impact of such projects is usually more widespread than most operational projects. Thus, the need for accurate and timely feedback, and especially com- munication of project goals, status and accomplishments. becomes extremely important. These functions cannot and should not be left to the line functions concerned with daily operations; they are clearly the realm of the vital staff function known as the Project Support Office, with the charter and skills to carry out these responsibilities.
Very often, those committed to the managing-by-projects concept also introduce the notion of "program" management, distinguished from "project" management. By definition, a program is a collection of related projects that address specific corporate strategic business objectives. Program management is that set of management activities and processes that facilitate the prioritization balancing, conversion, and integration of new strategic initiatives within the context of the current organization and planned time and cost constraints, thereby minimizing risk and maximizing benefit to the organization
Introduction of the "program" management approach almost mandates the establishment of a PSO organization for even the most experienced "project" management organization. Let us look at some of the principal responsibilities of a Project/Program Support Office, which can include one or more of the following: project initiation and planning; capturing and analyzing historical data; risk assessment; maintaining and enhancing corporate project management techniques; supporting users of project management systems; project manage- ment training (both fundamentals and software); quality assurance.
Two of these areas deserve special note. With the availability of easy-to-use project management software, it is recommended that the PSO not be charged with the actual operation of the software, but rather with the support of the users. The best technique for ensuring accurate project status data is to place the software tools in the hands of those performing the work. The PSO can be charged with providing training in the use of the tools and can function as an internal hotline for users. A natural outgrowth of following this recommendation is that PSO personnel should be involved in the project management software selection process if possible.
The role of the PSO in risk assessment also deserves emphasis. Managing risk is a primary determinant in project success. As part of the project status cycle, the PSO should identify, categorize and analyze potential risks. They should assist other project staff in developing alternatives and use their analysis to establish contingency. As part of their post-project audit function, the PSO should factor risk potential/actuality into future project planning activities.
The principal charter of the PSO is to "help manage the future, not just recalculate the past." Meaningful change doesn't come from high-tech hardware and software, but rather from people who are committed to and capable of performing new roles in a new business environment. The Project Support Office is a valuable aid to attaining this goal.
Key Project Phases and the PSOProjects/programs can be broken down into four fundamental phases: identification, definition, execution, audit. Inherent in all of the PSO functions identified in Exhibit 4 is communication. It is the single most important overall function that the PSO can perform in its supporting role. When establishing a PSO that will be involved in "change" projects/programs, it is vital to understand the dynamics of such projects/programs and the do mends they place on a support function. In such environments, the PSO must:
Of these criteria, the one most likely to cause failure of a Project Support Office implementation is the inability of the PSO to cross organizational boundaries. For organizations attempting their first implementation of project management techniques, this hurdle is perhaps the hardest to handle. In a pure functional organization the line managers perform the dual functions of line management and project management. When switching to a PSO-style organization it is natural for the functional line managers to feel that some portion of their responsibility is being removed. The executive responsible for setting up the project support organization must be aware of this and plan accordingly. For this reason, consideration should also be given to recruiting from the line management ranks for the PSO manager position. Regardless of the types of projects for which a PSO is being created, the profound organizational change effects should be considered, and it is suggested that the PSO team start with a pilot project implementation. As in any organizational restructuring, some staff will accept it with enthusiasm and some will reject it out of hand.
This brings us to the relationship between specific project and functional reporting structures and the responsibilities of the PSO. It is my contention that the primary overall goal of a PSO is management visibility and control. The PSO doesn t make the mid-course corrections to a project plan. Executive or project management does, based on the data, analysis and support of the PSO. As noted above, one of the principal functions of the PSO is risk assessment and management.
Successful implementation of a Project Support Office depends more on initial staffing than on any other factor. Because of the organizational change aspect of the function, it is recommended that the senior PSO manager be chosen from the existing line, rather than staff ranks. By following the pilot project implementation approach. it is possible to staff a PSO with as few as three or four personnel, including the senior manager and at least two members with significant project manage- ment software operations experience.
Beware of the tendency to rely on project management software vendors for training in this area: most vendors only train in the operation of their particular system, not in fundamental project management concepts. If the organization doesn't possess personnel with the necessary project management and project management software experience, this is one area where outside recruitment should be considered.
Another critical success factor is PSO team knowledge of the current business processes of the organization. Since we are dealing with fundamental change to the way of doing business, the team must have actual experience with the existing mode of operation. Without this experience, the team may find itself constantly on the defensive, attempting to justify change to an audience with significantly more 'real world" experience.
A final qualification for PSO team membership is an ability to lead without pressuring. The key is for all team staff to realize that they perform a very vital support role, contributing to overall project success. ~
Richard E Murphy, a 20-year veteran of project management,
joined Artemis Management Systems in 1990
and was responsible for the development of the Artemis
Views product line. Currently, he is charged with establishing
and maintaining partnerships with major
project management industry players.