In the dawn days of project management software, there was no such thing as “Desktop” systems. Indeed, there was no such thing as a desktop. The use of early project management systems were done entirely in mainframe or very centralized environments and by personnel who were very specialized as well. Given the extreme cost of setting up such systems, it was only on the very largest of projects or most complicated of project environments where they were found.
Consequently, the most common, almost universally accepted organization for the use of these systems was the ‘Project Office’. In this office, one would find a small cadre of skilled schedulers estimators and project-related experts who acted as a broker of information. They were identified on many organigrams as outside the normal hierarchy of business through a dashed line connecting somewhere high up the corporate ladder; a sort of ‘black box’ from which important information flowed.
The perspective of management is that this office were the eyes and ears of management, reporting on the status of the project. From the field, these people were known as the schedule ‘reporters’, reporting on the efforts of the people actually doing the work.
The truth was usually neither of these. The project team usually walked a fine line, delivering the results of their analysis in the formats that would most benefit the project to the people who most needed the information. They were often the only people who had perspective on the project as they were the only people who, from week to week would “walk the project”, taking notes on the progress of each piece of work. They were able take advantage of that perspective by specializing in the analysis of the project, looking day-by-day at project schedules, alternative strategies and the pace of work. The first software systems that these offices used were large, unwieldy and user-hostile. It took imagination and no small amount of effort to produce the results required out of them.
The analysis that the Project Office delivered was important but underlying it all was something that was at least as important and not immediately obvious until the nature of computing changed.
The advent of desktop computing brought with it almost immediately desktop project management software. The software category was ideally suited for the latest in computing and the notion of more friendly and more flexible software for scheduling was quickly adopted by both experienced and novice project managers.
In the early heady days of PCs no one thought anything of the distribution of project scheduling work. The notion of the project office seemed passé. After all, the software no longer required a dedicated skilled operator. Some new desktop planning systems could be used within minutes and mastered within hours and produce reports that looked every bit as good and as professional as the old system. It is more the exception than the rule now to find a project office. Mega projects still have them, older organizations who have had project management as part of their culture for many years still do as well; consulting engineering firms for example. Yet the need for such systems is no longer as obvious.
Users have flocked to desktop systems in droves but along the way they’ve lost out on something that was part of the underpinning of the Project Office, part of its fabric. It’s true that the product of the Project Office was schedule reports but it’s equally true that to do so required the Office had to create project management practices and procedures, standards, naming conventions and more. Desktop systems have successfully replaced the user functionality with systems that are faster, require less hardware and are so user friendly that they no longer require skilled operators but what has been lost along the way are the benefits of the effort put into organizational practices and procedures for the management of that data.
These practices and procedures included things like naming conventions. For example, in such an office it would be unthinkable to have different project files using the same code for different resources. There would be a consistent and identifiable time for project status updates in order to be able to compare different aspects of the active projects against each other. Reports would be standardized in order to enable the grouping of multiple project files together. Even if such reports weren’t standardized, the people who created them for one project would be immediately available to create them for others. Common codes such as Work Breakdown Structures might be shared among all project files in order to make them comparable later.
The absence of the Project Office has now become more and more apparent as the pendulum swings back somewhat in organizations that are now attempting to coordinate their project management efforts to produce enterprise-wide analysis and reports on projects anticipated or in progress. Enterprise Project Management Systems are lovely marketing terms but without the structural underpinning, they are simply a lot of features with the potential for delivering organizational project management.
Is it time for the Project Office to make a comeback? I think so. It would not, however, be the Project Office of old. With the advance of project management systems today, there’s not much profit in re-centralizing the user functionality. What is sorely missed however in almost any organization which is trying to implement a cross-department or organization-wide project control environment are the standards that must exist for such a system to work.
A new breed of Project Office may be the only way to ensure enterprise-wide project management. The mission of such an office would be to establish standards for all users. The new Project Office would be the publisher of naming conventions, of common coding structures, of report formats, of common calendars and shared resource files, of data standards that will make merging data later even possible. Their task is not made particularly easier by easier-to-use software. With individual users able to operate independently, it becomes more difficult to impose these kind of standards.
The new Project Office is also an ideal place to centralize project management expertise and to establish whatever project management training might be required for the organization. As a source of training and useful data, standards can be ‘snuck in’, offered as a path of least resistance (my favourite concept in implementing project management across the enterprise). The Project Office loses its “Big Brother” stigma and becomes a sort of super help desk, delivering as part of its own fabric the practices and procedures that make enterprise project management possible.
– – –
