The Evolution of Program Management

Computer-based project management (PM) tools have been around almost as long as the PC, and mainframe based tools have certainly been around since the 60's. The dictionary of computer terms defines project management as “The process of planning, organizing, staffing, directing and controlling the production of a system.” Initially project management tools were developed for trained project managers to help them individually in managing a project. A successful project manager must simultaneously manage the four basic elements of a project: resources, time, money, and most importantly, scope. Because all these elements are interrelated, each must be managed effectively, and all must be managed together if the project, and the project manager, is to be a success. The software tools for project managers are focused on providing critical information (Gantt charts, resource lists, task sheets, etc.) the project manager needed to manage a project. Currently Microsoft Project 2003 is the leading tool in this area.

But somewhere along the way, more and more of the users of these tools were not trained project managers, but rather knowledge workers that found themselves in a defined series of actions moving towards a specific goal… called a project. They did not have PMI (Project Management Institute) training, and often the only training they did have was the experience of being on a variety of different projects in their past.

Often these new “accidental” project managers looked towards specific software tools to help them manage the increasing complexity (and number) of projects they were now dealing with. Often the PM tools were as complex as the project its self and took an inordinate amount of time and training to become proficient with the tool (See Figure 1). The example in Figure 1 shows a bubble chart view of projects in a company's marketing and sales departments, and is from an older version of a project management tool from Primavera. This tool in general took 3-5 days of class to learn how to use it. Often this learning overhead was too much and project managers resorted to the tool of last resort… Excel. Which is great for a task list, but not much more than that. There are no coordination or scheduling functions built into Excel!

Figure 1. Complex PC-based Project Management Tool Example

Project Management Software

As our information and communication infrastructure became more sophisticated (the Web, broadband, Wifi, etc.) many PM tools began to evolve in the 1990's from just desktop scheduling tools into tools that were front-ended by a browser, like some of the earlier versions of Primavera's TeamPlay. Eventually in the late ‘90's some of these LAN-based tools were re-written to run only on the Web. Or vendors developed new tools pm tools that only worked on the Web. We began to call these web native project management tools DPM -- distributed project management tools (See Figure 2) because the Web architecture allowed any team member anywhere to access project information and to collaborate with other team members inside or outside the organization.

Figure 2 graphically shows the evolution of project management tools, through today, were these tools are evolving in different directions. Some PM tools are getting more process and industry specific, and this group of tools has split off from the general project management tools and are focusing in a specific niche like AEC, NPD, PSA or IT/SW development (see: http://collaborate.com/announcements/announce_6.html).

A second direction is for some of the higher-end project management tools to keep adding functionality with the idea of evolving into program management tools. The third direction is for vendors to directly build a tool for program managers much like Cyntergy Technologies has done with their Thumbprint CPM tool www.thumbprintcpm.com.

In 2000, Collaborative Strategies started tracking these project management tools, as we saw a strong trend towards the introduction of collaboration and team functionality into the technologies in this area. We have produced an annual report on DPM tools since then and try to track the three different directions these tools are evolving.

Another trend we have seen since the late ‘90s is an increase in complexity: in the number of projects, the difficulty of the project and the number and difficulty of interactions between project team members and those outside the organization. Add this to the fact that most of those today running projects are non-professional project managers, and we have a recipe for chaos and disaster.

Figure 2- Evolution of Program Management Tools

To deal with this increase in project complexity many organizations created the Project Management Office (PMO) as a central point of information and coordination for projects. This increasing complexity and the organizational response of the PMO has lead to the development of a new discipline called Program Management (PGM). Program Management tools not only have to deal with more projects, but more complex and long-term projects. What is becoming even more clear, is that PM tools need to be able to help the program manager manage the interactions between (and sometimes within) project teams, teams on a group of projects in a portfolio, or even teams working in different project portfolios (see figure 3). Figure 3 shows an interaction management cycle, or what happens to an interaction between two or more people on a project team. Just multiply this by a 1000 and you will get an idea of the complexity that a program manager needs to deal with

Figure 3: Interaction Management Cycle

One of the biggest issues in PGM, is knowing what information to look at, because there is now so much available you can drown in it. Cliff Stohl, an astrophysicist, used to dealing with the complexity of strange and charmed quarks, gluons and the string theory of the universe notes that "Information isn't power. Hey, who's got the most information? Librarians do! It's hard to imagine a group of people with less power than librarians. Information is power? The whole idea is false." Stohl continues, "knowledge, dare I say wisdom, which we ought to be seeking, is, for the most part, not information, but a sense of understanding, a sense of judgment, a sense of when to ignore information." (From Changing How We Work: The Search for a Simpler Way www.simplerwork.com Copyright © 2000, The Jensen Group, Northern Illinois University).

In other words a PGM tool needs to not only manage data for projects and groups of projects, but has to help manage the relationships between project groups and team members. It also has to help the program manager see what is happening at a high enough level so that they can discern trends, see directions and head off disaster before it occurs. One way to do this is to make sure the transfer critical information (within context) occurs between projects so that the transfer of learning from one team to another is facilitated. In the past the only way this type of learning got transferred from project team to project team was if one of the team members moved from one team to another.

This combination of organizational complexity, the increased number of interactions between team members within and between projects, and the increasing number and complexity of the projects themselves, has created what is called a “wicked problem” for the program manager. “Wicked problems” are those where neither the whole problem nor the solution can be defined at the onset of the project”. Because projects often have changes to their goals and processes the further along they are, tools that will handle and help coordinate many projects need to include: project planning tools; project team interaction tools; and project execution tools. The next installment in January will look more closely at some of the critical criteria for Program Management (PGM) and determine which of the tools currently available meets those criteria.

David Coleman is the Founder and Managing Director of Collaborative Strategies. This column is his ideas and comments and do not necessarily represent the views of all of the analysts at Collaborative Strategies.