Teamocracy and project management: a conundrum
a case for the project office
Harvey A. Levine
A software package does not a project manager make; a call for expertise-based project leadership
The state of computer-based project management implementation in today's downsized and decentralized organizations is an enigma. Two basic models for computer-based project management are emerging in today's businesses. There is the desktop model. This features one or more copies of a project management software package, possibly tied together across a network. Each user is independent and is expected to be self-sufficient in use of the software and process. There is also the enterprise model. Here, we can expect to find a server-based system, optimized to facilitate data flow, communication, and possibly cross-application, cross-platform connectivity. Each user is a contributor to a system that is most often placed under the control of the Information Systems (IS) function.
Quite frankly, if implemented as described above, both of these models are way off the mark.
In the case of the desktop model, we see major omissions. Where is the leadership? Where is the development of standards? Where do we go for expertise in project management, and in the use of the project management software?
Project-Manager-by-Default. Where do we get off expecting that all engineers, or programmers, or marketing specialists will possess skills in project management, or in operating a project management software program? Would we likewise put accounting software on each employee's desk, ask them to perform the accounting for their area, and then eliminate the corporate accounting function? We don't ask engineers to do marketing. We don't ask programmers to pour cement. Why do we ask them to fill a role for which they are not trained (and which probably isn't in their job description)? This is truly absurd. And it will produce regrettable consequences.
IS = PM. Not! It's even worse for the enterprise model. Who came up with the idea of putting IS in control of the corporate project management system? Of course IS has an important role to play in this function. But not as the owner I have participated in numerous meetings where IS was leading the specification of a new enterprise project management software system. Rarely did their high-priority items ever address the important needs for project managers. In this enterprise model, we see all of the same omissions as in the desktop model. But instead of a lack of leadership, we see the leadership role in the wrong place.
What is missing is the project office Due to a combination of corporate downsizing, movement from hierarchical structures to “teams,” and the flattening of organizations, it is becoming increasingly difficult to justify the function of the project office. Yet, the role of the project office to successful project management is more important than ever. Back in the days of mega-projects and mega-computers, the project management function was clearly situated in the organization. The project office assured the availability of project managers and project control specialists, as well as standards and practices. Project management was implemented according to a plan and this implementation was monitored, measured and supported by qualified experts. The shift to managing multiple, smaller projects, using microcomputers, has in no way eliminated or reduced the need for this function or expertise.
The Teamocracy: Set Up to Fail? My professional colleague and perennial PMI supporter, David Cleland, has authored an important text, Strategic Management of Teams (1996, John Wiley & Sons). While reading it recently, I recognized several critical issues, and was reminded of some nagging concerns about implementing computer-based project management in today's changing organizational cultures.
Certainly, we must acknowledge that teams have become a modus operandi, replacing traditional bureaucratic models, especially where projects are involved. With the diminution of traditional project functions and matrix management models, we are witnessing the disappearance of the project office. But is this consistent with what we are looking for from teams? One objective is to capitalize on various people strengths and knowledge, regardless of location and position within the organization, while freeing them from the bondage of hierarchical boundaries.
To make project management work, there must be personal strengths and knowledge in the discipline of project management, structured in such a way as to be available to the teams. It is not enough to expect that the individual team members will have this expertise. Rather, if the team model is to work for projects, there must be qualified project management practitioners assigned to the teams.
Where will these qualified project management practitioners come from? Certainly we don't pluck them from trees. And what kind of guidance shall be provided for them? Does each team develop its own approach toward project management and project control? Does each team, using ad hoc project management practitioners, reinvent the wheel and run on non-pneumatic tires?
I recently conducted a series of seminars and presentations on project management and project management software, during which I asked each group whether people were using project management software and which products they were using. In almost every group, there was an overwhelming preponderance of Microsoft Project users (even in excess of the reported 70 percent market share). Yet, hardly any of them could relate how and why the product was chosen. Hardly any of them could point to a needs analysis and selection specification, and report that the chosen product supported such needs. The fact that so many of these people were attending presentations on project management software must indicate that they are looking for something other than what they have.
This condition was in no way limited to just users of Microsoft Project. Many companies reported more than one product in use. Senior management, in an attempt to thwart the random buildup of multiple products, has often demanded that a single standard be selected. But that selection is often being executed in relative ignorance, by the wrong people.
Whether the organizational structure is a bureaucracy, an adhocracy (a term coined by Alvin Toffler in his 1970 book Future Shock) or a teamocracy (a term coined by David Cleland), project management expertise must be available and project management standards and practices must be in place. The organization's structure may be flexible and innovative, but the expertise cannot be lacking or expected to be substituted for by other disciplines. ■
Harvey A. Levine, principal, The Project Knowledge Group, Saratoga Springs, N.Y., provides training and consulting services to users and developers of project management software. He is also a past chairman of the Project Management Institute.
PM Network • September 1996