1. Collaborative Strategies LLC
Volume and Response
by David Coleman
Table of Contents
2 Background and Evolution of
5 The Rise of Program
14 Building or Evolving for
2. Collaborative Strategies LLC
Introduction As the number of projects and the level of project complexity increases,
knowledge workers find it necessary to interact with others, not only on the
project team, but often outside the organization. These increasing levels of
complexity at the task, project, and organizational levels have helped to spawn
a new class of software tools aimed at managing the complexity of these “wicked
problems.” This new class of tools is designed for program managers who have
to manage resources across multiple projects (portfolios of projects), in addition
to providing coordination, budgeting, and costing support. Transferring “lessons
learned” to projects in different portfolios for organizational learning is also an
important function of program management.
This white paper is divided into the following sections:
Section 1 provides background information on the evolution of project
management (PM) tools and how collaborative and other functions have been
added to these tools over time. “Interaction Management” is an evolving theme.
It includes embedding collaborative functionality in project management tools
to facilitate interactions between team members both inside and outside the
organization (value network).
Section 2 focuses on what it takes to manage a program successfully. It looks
at the limitations of today’s PM tools, which have evolved to handle multiple
projects, but do not handle the project meta data that is critical to a Program. This
section outlines 10 functional criteria that are critical for program management
(PGM) tools, and examines how complexity and collaboration challenge the
effectiveness of today’s PM tools. A scenario is used to highlight some of the
complexity issues in managing programs, as well as key differentiators between
PM and PGM tools (specifically templates vs. models).
Section 3 looks at whether PGM tools need to be built from the ground up or
can evolve from traditional PM tools. This section also examines the role of
information and knowledge in both PM and PGM.
Conclusion: After reviewing several leading PM tools, it was concluded that
very few of today’s PM tools meet the rigorous criteria for PGM but that Cyntergy
Technology’s Thumbprint CPM comes closest.
Glossary: Because terms in the project management and collaboration
space are often misused, a glossary of critical terms and definitions have been
1 Program Management: Managing Project Volume and Response Speed
3. Collaborative Strategies LLC
Background Project management tools were initially developed for trained project managers
to simultaneously manage the four elements of a project: resources, time, money,
and Evolution and most importantly, scope. Because all these elements are interrelated, each
of Program must be managed individually, and all must be managed together. PM tools
are focused on providing critical information (Gantt charts, resource lists, task
Management sheets, etc.) to the project manager. Today, Microsoft Project is the leading PM
tool in this area.
As the market grew, more and more of the users of PM tools were not trained
project managers, but knowledge workers who found themselves “in a defined
series of actions moving towards a specific goal… called a project.” They did
not have formal PMI (Project Management Institute) training as did many
professional project managers. Their primary experience was being on a
variety of different projects in their past. These new “accidental” project
managers looked for software tools to aid them in managing the increasing
volume of projects on which they were engaged.
Project Management Software Evolution
As our information and communication infrastructure became more sophisticated
in the 90’s, PM tools evolved from desktop to web-based tools with a browser
interface. As the Internet grew in popularity, some of the LAN-based PM tools
were re-written to run natively on the Web. CS began to closely track PM tools
in the late 90’s because they began to add collaborative functionality. We began
to call these web-native tools “Distributed Project Management” tools (DPM)
because they provided team members access to project data from anywhere.
Figure 1 shows the evolution of PM tools from inception to today. CS sees these
tools evolving in highly focused directions as we go forward. In an effort to
differentiate themselves, many PM tools are getting more process and industry
specific. CS sees this group of tools splitting off from general PM tools to focus
on a specific defensible niche, such as new product development or professional
services automation. For more information on both the general DPM market and
this new group of industry and process specific tools, see the CS DPM 2002-2003
Industry Report update (http://collaborate.com/announcements/announce_
A second trend for the higher-end project management tools has been to keep
adding functionality with the idea of evolving into portfolio and PGM tools. Although,
not yet identified as a trend, CS is seeing some vendors that have identified PGM as
a different challenge from traditional PM, and are building tools directly for program
managers much like Cyntergy Technologies has done with their Thumbprint CPM
2 Program Management: Managing Project Volume and Response Speed
4. Collaborative Strategies LLC
Complexity and Chaos in Program Maagement
Another trend that has evolved since the late ‘90s is an increase in complexity
and volume of projects that are part of a program, including the speed at which
program managers have to deal with project and portfolio exceptions to keep the
program on track. When you add the fact that most individuals running projects
are not professionally trained project or program managers, we have a recipe for
chaos and disaster.
Programs by their nature are complex because “all living systems and organizations
are complex,” notes David Snowden of the Institute for Knowledge Management
(IKM). Dr. Snowden distinguishes between complicated and complex though the
following example. “An airplane is complicated, it has many different parts and
interactions, which can be known, understood, engineered and managed. When
something is complex there are simply too many variables for it to ever be truly
known, fully understood or managed. Life is complex, organizations are complex,
and some projects are complicated while others are complex.”
CS sees software tools and infrastructures, like any tool, as an extension of our
mindset (our ideas, attitudes, information and beliefs) and a way to deal with
complexity. The organizational response to the increase in the number of projects
it has to deal with is called the Project Management Office (PMO). The PMO is a
central point for management, information collection, and decisions on groups of
interrelated projects. The PMO is able to see the big picture across all projects,
portfolios and programs.
1960-1980 1980-1990 1990-1995 1995-1998 1998-2001 2000-2002 2001-2005
Mainframe- PC-based LAN-based Web-native Web-native Web-native
based project project project project portfolio program
management scheduling scheduling management management management
tools tools tools tools (DPM) tools tools
AEC/Owner Specific New Product
Management process and Development
IT/SW project tools PS
Figure 1: Evolution of Program Management Tools
3 Program Management: Managing Project Volume and Response Speed
5. Collaborative Strategies LLC
Tools targeting the PMO not only have to deal with an increased volume of
projects, but also the need to be able to help the program manager manage the
interactions between project teams, teams on a group of projects in a portfolio,
or even teams working in different project portfolios. Figure 2 shows an
interaction management (IM) cycle, or what happens to an interaction between
two or more people on a project team. Multiply this by a 1000 and you will get
an idea of the volume of interactions being dealt with by program managers.
Task Management Task Notifications
Review and Response
Figure 2: Interaction Management Cycle
The PMO and program managers have to deal with a huge volume of information.
Not only do they need to see an overview of each of the project portfolios they are
responsible for in the program(s) they are managing, but if there is an exception
(problem, modification, issue, etc.), they need to be able to drill down into that
specific project and process to help a project manager handle that exception.
One of the biggest issues in PGM is to know 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).
4 Program Management: Managing Project Volume and Response Speed
6. Collaborative Strategies LLC
In other words, a PGM tool needs to manage data for projects and groups of
projects, as well as 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 of
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. PGM tools have
to facilitate this learning to rise above merely being multi-project management
As project management tools have evolved, they have added more and more
The Rise of capabilities. But have they added the right features and functions to make them
Program program management tools? We believe that there are 10 basic elements that
need to be managed through all phases of a project cycle. If the management
Management of these elements is important to a single project, think how critical they might
Tools be to someone managing a program of 50, 200 or 1000 projects? The basic
project elements inlcude:
1. Project Requirements
2. Organizational Options
3. Project Team
4. Project Planning
5. Opportunities and Risks
6. Project Control
7. Project Visibility
8. Project Status
9. Corrective Action
10. Project Leadership
PM tools generally deal with elements 1, 4, 6, and 8. PGM tools have to deal with
all 10 elements. They must do it in a way so as to not overwhelm the program
manager, while enabling them to dig deeper into any one of these elements if
needed. It has only been in the last year or so that we have seen some vendors
5 Program Management: Managing Project Volume and Response Speed
7. Collaborative Strategies LLC
adding functionality to their PM tools to help them deal with multiple projects,
and programs of projects. Accordingly, we have extended our list of criteria
(features/functions) that we use for evaluating DPM tools to include a number
of criteria for multi-project management and Program Management. This
white paper will focus mostly on the areas of communication/collaboration and
knowledge management, since that is where most of the innovation in DPM tools
has occurred to support program management.
Criteria for Program Management
We interviewed several program managers in a variety of industries as part
of our research for this white paper. We asked a program manager of a
large multi-company PMO what her three highest priorities were, and she
replied “Maintaining alignment across all parties, managing change, and good
communication.” Another program manager responded, “You need to know
before you have a problem, so the data has to be real, current, up-to-the-
minute information on where you are, so you can hedge risks rather than
reacting to results. Prediction is paramount. Program managers need to get
the information they need to make decisions before there are problems in the
projects and programs. They need to have this information roll up to the highest
level (when appropriate), so they can be proactive, rather than reactionary,
because reactionary is too expensive!”
In addition to general functions supported by most PM tools, we have developed
the following additional criteria required by PGM tools.
1. Communication: The ability to facilitate context relevant
communications between projects, portfolios and programs, generally
asynchronously (but sometimes synchronously) to cut the cycle time for
task completion. It must be flexible enough to support the value network,
yet have tight security, which manages access by project team members
outside the organization (and firewall) while supporting their interactions.
2. Security: Program security has some specific challenges that differentiate
it from project security. If you are a program manager with 500-600 projects
in the program, you can’t just invite everyone to every project, especially if
there is a high degree of overlap in the project processes and resources. In
addition, role-based security may not be adequate, as you may need people
in your value network to have access to project data and the project team for
only a specific part of the project or process, and then have less or no access
6 Program Management: Managing Project Volume and Response Speed
8. Collaborative Strategies LLC
3. Easy to use: Program managers are often executives without
sophisticated technical knowledge. If the PGM tool is not intuitive,
browser-based, and can’t display the status of projects, portfolios
and programs graphically at a glace (using a program dashboard), it
usually is not used with any frequency.
4. Business Logic: The ability to set business logic that can be
maintained outside the project, yet can be applied to specific projects
in the program within a specific context. This business logic is critical
for program managers especially for exceptions, changes, or delays.
5. Project Interdependencies: The ability to customize views and
reports so the program manager can see into a program, project or
portfolio at any depth necessary to resolve an issue. This also includes
the ability to see interdependencies or any resource conflicts across
projects, portfolios and programs.
6. Access to Critical Data Types: Ability to integrate with a variety
of data types, including LDAP directories, ERP data, XML data and
information from MS Project (scheduling tool).
7. Project Cost and Budgeting: The ability to deal with costs,
budgeting, change order costing, and activity-based costing for projects,
portfolios and programs.
8. Project Volume and Grouping: The ability to group all types of
information (schedules, documents, conversations, email, Instant
Messaging, presentations, etc.) within a project container, and see
all related information for projects in this container. In addition, the
ability to deal with a large number of projects without dealing with a
proliferation of templates, yet share the ability to re-use task, project,
and program information in a relevant context.
9. Program Decision Support: The ability to support critical program
decisions. This includes the ability to simulate task or project changes
and outcomes, revise decisions during the course of the project,
provide decision support tools to facilitate group or team decision-
making. This includes tools for risk assessment.
10. Reuse of Project Objects: The ability to capture specific processes and
expertise that are part of a task or project and store them for automatic
reuse in a similar context in another project or task. This process expertise
is not the same as process rules or logic (explained in #3), but rather is
how experience, information and program meta data can be captured
and applied in context as an attribute of a project object. These “project
objects” can be used to assemble new tasks or project processes.
7 Program Management: Managing Project Volume and Response Speed
9. Collaborative Strategies LLC
It is clear the PMO must deal with a complicated set of variables, including
but not limited to people, time, resources, processes and procedures, and
interpersonal interactions. It is also clear that program managers have to
deal with a large volume of projects and within a specific (and often rapid)
timeframe. As one of the program managers interviewed put it “… the volume
(of projects) and speed (reaction time) are really what separate a program
management tool from a project management tool. It is important for those
running large programs to understand that volume crushes and speed kills.”
Of course, “large” is in the eye of the beholder – as one organization may
consider 20 projects to be a high-volume while another deals with hundreds
or thousands of projects. The “process complexity and chaos” among projects
discussed in Section 1 often dictates the threshold of what is considered high-
volume. Nonetheless, the principal remains. There is often a tradeoff between
speed and complexity, or speed and project volume as we see in Figure 3.
• IM (interaction management) is focused on interpersonal interactions, and
usually uses some type of RTC technology for fast cycle exchange (speed),
but can only happen between a limited number of people (complexity).
• PM tools tend to use asynchronous communication and collaboration tools
and so have a slow reaction speed, and are limited in complexity (the
number of projects they deal with).
• MPM tools also tend to utilize asynchronous communication, but are able
to deal with a higher project volume and complexity.
• PGM tools use both types of collaboration for increased speed, and designed
to deal with project meta-data as well as a large number of projects.
LOW Process Complexity/Volume HIGH
Figure 3: Tradeoff Between Complexity/Volume and Reaction Speed
8 Program Management: Managing Project Volume and Response Speed
10. Collaborative Strategies LLC
The Template Trap
Templates provide the most common way to handle volumes of similar projects,
and re-use prior project frameworks and processes. Templates are an outgrowth
of desktop project scheduling tools and have been extended to the Web. It is
common for a project manager to initially develop the project plan in MS Project,
and then import the plan into a more sophisticated PM tool with collaborative
capabilities. The use of templates provides a good illustration of what the right
architecture for a PGM tool might require.
As PM tools evolved and were able to deal with more complicated projects,
project managers wanted to save the framework for the project (the schedule
and how the tasks and resources interacted), so they could reuse and quickly
build a similar project plan the next time. These project frameworks, called
“templates” have become very popular, and tools like MS Project come with
hundreds of templates for all sorts of project types.
Templates are a great way to store project information both in context and in
process. The problem is the proliferation and management of templates. As
one IT manager at Wal-Mart noted, “We looked at MS Project that was being
used by our new store group, but not very successfully. The templates created
in MS Project got to be large and voluminous. We wanted something more
flexible and useable by outside vendors and consultants.”
Instead of MS Project, Wal-Mart chose a model-based tool called Thumbprint
CPM (TCPM) from Cyntergy Technology. It was flexible and eliminated the need
to manage the proliferation of templates created in MS Project. TCPM uses a
model-based architecture to help program managers manage the large volume
of projects rather than a template-based architecture.
The template problem is similar to that of “mass customization.” The term
in itself is an oxymoron, but what it means is the ability to customize a mass
produced product like a car with a number of options, such that the sum of
the options makes the mass produced car unique to the person buying it. I
had a recent experience with this when buying a Mini Cooper (made by BMW)
last year. The basic Mini Cooper was the commodity. I upgraded to the “S”
(sport version), which came with a number of options like larger wheels, stiffer
suspension, etc. I got to select the seat fabric and color, the interior finish
(carbon fiber or chrome), the stereo equipment, sunroof, wheel color, racing
stripes, etc. If we imagine the basic Mini Cooper as a project template, then
the “S” model would be a specific instance of that template, which could be
9 Program Management: Managing Project Volume and Response Speed
11. Collaborative Strategies LLC
considered another basic template. Each of the options added to the car would
then generate a new template. Think of it as a project with a number of critical
variables changed. With 25 options, and 4 choices per option, it would be 254 or
almost 40,000 choices with each choice representing a template.
A good example of how the permutations and combinations of a template-based
architecture can explode is to look at a real world process that is used in projects
all the time. The AIA (American Institute of Architects) process for constructing
a building is a more complex process than the car example above, but is used
as a framework process all over the country. In using this process and asking
a few questions we can see how the number of variables (options) adds up
quickly. Questions like: “Are permits and approvals required? Which different
phases does the project include? Is the site already secured? Is it properly
zoned?” Based on questions like these, you end up with 75 million possibilities
(at least!) for a construction project that follows the AIA process. Factoring out
the more unreasonable possibilities, you would still have about 4 million options
or templates resulting.
One way to avoid the “template trap” is to take a different approach to solving
the problem. Cyntergy Technology has taken a model-based approach to
solving this problem for PGM. TCPM builds an underlying model for the program.
Projects included in the program use the same model, just with different
variables. The system is smart enough to understand the project context, and
can draw from other projects or programs in the database with a similar context.
Interestingly, this is done automatically by TCPM, and supports the immediate
application of new learning across the organization, without having to wait for
a “best practice” to be distilled and then actively found by a project manager at
a later date.
The Need for Speed
The other issue for program managers is speed. It is really the speed of
response, or the speed at which they can identify a potential problem and avoid
it. Either way, this “speed” usually requires some level of interaction with others
in the program. What role does collaboration play in dealing with the “speed” of
PGM, and how is it being integrated into both PM and PGM tools today?
It seems to be common knowledge that a project plan, while important to
prepare at the beginning of a project, never reflects what actually happens
during the project. One reason is that project plans tend to be static, while
10 Program Management: Managing Project Volume and Response Speed
12. Collaborative Strategies LLC
a project composed of coordinated tasks and actions is dynamic. The other
problem is that some projects are complex. We don’t know all the variables
up front, yet we treat them as if they were just complicated, and wonder why
things don’t work out?
The interviews with program managers revealed a common theme
- communication was critical. We define communication between two or
more people around a specific goal or task within a defined time period as
collaboration. Program managers found communication was important, but
collaboration was even more important. Not all communication is collaboration.
We refer to communication without purpose as “gossip”. It is most of what
happens when threaded discussions get off track. Every time you add a new
person to a project you increase the complexity of the communications for that
project exponentially rather than arithmetically. One of the most common
types of problems with program management is that the number of variables
proliferates organically until there are too many to manage.
According to Pat Carroll, head of the PMO for Wal-Mart’s Tenant Real Estate
Group (tasked with building and managing the physical store facilities):
“We looked at 15-20 project and program management tools. We picked
Thumbprint CPM (TCPM) because of its knowledge base, flexible reporting tools,
and because it is easily customized to each user. One of our ongoing issues was
to achieve better collaboration in the PMO, which could lead to a reduction in
number of project status meetings, non-productive time, etc. TCPM has become
our collaborative infrastructure, and has streamlined communications for
everyone in the group, enabling us to find out about project status by just going
to Thumbprint CPM instead holding meetings, calling someone, etc . Thumbprint
CPM information is almost in real-time, and it is up-to-date all the time. This
has eliminated the need for the PMO to meet every week to get project updates.
We now meet every other week. With a PMO staff of 12, that means we are
saving at least 48 hours each month just on project status updates!”
“Wal-Mart did not have a very sophisticated infrastructure for collaboration
when we evaluated the program management tools. It was mostly email and
phone calls, with an occasional group using products to share documents (like
Lotus Notes), or having a ‘virtual plan room’ out on the Internet,” noted the
IT Manager at Wal-Mart. “The fact that Thumbprint had a number of critical
collaboration capabilities built in, has helped adoption of the tool enormously.”
11 Program Management: Managing Project Volume and Response Speed
13. Collaborative Strategies LLC
The Introduction of RTC into PM
All the vendors evaluated for this white paper offered some level of
communication and collaboration within the project context through their
PM tool. Most often they offer asynchronous collaboration through threaded
discussions, common databases and email. However, in a complex process or
workflow, there needs to be a high level of interaction to deal with exceptions,
issues and other challenges. CS believes that real-time, or synchronous
collaboration technologies have matured enough to provide value in PGM tools
by cutting the cycle time for interaction.
Cyntergy appeared to be the only vendor evaluated that was deeply
committed to collaboration. This involved looking at PMO processes and
seeing where specific collaborative functionality could be applied to shorten
cycle time. Cyntergy was the only vendor that directly incorporated real-time,
presence-based collaborative functions (RTC) into their TCPM tool, before
being asked to do so by their customers. We inquired about RTC with each of
the other vendors evaluated, and got the same answer from all of them - their
customers had not asked for it yet. This is obviously a reactive vs. proactive
Let’s look at the AEC scenario below to see how RTC can cut cycle time in
various tasks and processes.
George is the program manager for Q-stores, a chain of
convenience stores in the Pacific Northwest. With the exploding
population (many migrating from a beleaguered California) Q-
stores has engaged in an expansion initiative that will generate
50 new stores over the next 2 years, that is almost 2 new stores
a month opening. George, a slim 50-year old with a full head
of hair, is now overweight and almost bald from the frustration
of dealing with so many projects at the same time. In addition
he is popping Rol-Aids like candy. George’s greatest frustration,
and source for cost overruns is that he can’t react in time to a
Bob is the site manager for Store 512, which is being built in
Sasquach, WA and is part of a group of 11 Q-stores being built in
eastern Washington. Bob reports to Roni, who works for the building
company Erect-IT that won the contract to do the 11 Q-stores in
eastern WA. Bob is on site and in digging the foundation for the store
has run into very large granite outcroppings that were not shown in
the initial land survey because they were located too deep. However,
the rock is too hard to break-up and will require blasting.
12 Program Management: Managing Project Volume and Response Speed
14. Collaborative Strategies LLC
Bob contacts Roni by cell phone and lets her know of the delay
and wants to know what they need to do to get a blasting permit.
Roni, who has dealt with this problem in two other stores in
Eastern WA, replies that Bob needs to go online and look at the
blasting permit process. Roni then tries to call George to advise
him of the potential delays and costs, but can’t get through on
the phone (its busy). She is online and can see an icon showing
that George too is on-line, going into the project for store 512,
she can IM George directly from the task that is at risk and whose
process now has to be changed. George replies back immediately
that because this specific problem has come up so often for Q-
stores that they have already secured a state-wide permit for
blasting (for foundations) and points Roni to the document on-line
that has the official state agreement for this. Roni reviews the
document and because Bob is manager of this store project he
also has the ability to see not only the IM interchange between
Roni and George, but also the document about blasting that Roni
The project management program automatically notifies Bob with
an SMS message to his cell phone that he has critical new mail.
Bob, goes into the construction trailer, logs onto the URL that is
displayed on his cell phone and immediately sees the conversation
between Roni and George, and the blasting permit document,
which he immediately prints out and posts (for when the building
inspectors come by). In addition, Roni, through the PGM program,
lets each of the other building site managers in her group know
about the new blasting permit.
The whole interaction has taken a matter of minutes, and Bob’s
crew can get back to work immediately. In the past this same
interaction may have taken days and even weeks, and cost Q-
stores a lot of money, while the building crews sit idle waiting for
the site manager to resolve this hard (granite) problem!
In the scenario, the PGM tool allowed the program manager, who is often
overwhelmed with input (from all media types), to avoid a disastrous cost
overrun in one of the project groups. Through presence detection, a group
project manager was able to contact the normally unavailable program manager
and find a general solution to a specific problem common to the geography where
all of her stores (projects) were located. In addition, she was able to share this
new knowledge with all of the store managers immediately, and was able to
incorporate this information into any new store projects in her geographic area.
13 Program Management: Managing Project Volume and Response Speed
15. Collaborative Strategies LLC
The interview process for this white paper revealed there were a number of
factors that were critical to successful program management. They can be
summarized as The Six “Cs” of Program Management: “Control the Chaos and
Cost within and between projects through better Communication, Collaboration,
Building or In researching this white paper, we looked at 30 different DPM tools and
Evolving for selected only five tools that seemed to have the most program management
functionality. We then composed a feature/function matrix and asked product
Program managers from each of the vendors to complete it, rating each of the features
Management? on a 1-10 scale. CS reviewed each vendor’s response with them to validate its
accuracy. The vendors evaluated included:
• Thumbprint CPM 2.5
• PlanView 7.3.2
• Primavera TeamPlay 4.0
• eProject 5.0
• Meridian Proliance 1.5
When evaluating these tools, it was clear the four tools besides TCPM were
all originally designed as project management tools. The vendors are now
focused on upgrading their tools to support program management functions.
Many of these vendors have realized that collaboration is a critical function in
portfolio management, and now see collaboration as a critical part of program
TCPM, on the other hand was the only tool we examined that was built from
the ground up to be a program management tool. Primavera and PlanView
have very strong project management functions and large user bases. It is
our belief their product management tools (if not re-architected) will eventually
migrate into good “portfolio” management tools, i.e. good tools to manage a
large volume of projects, but not as good at managing both the interactions
and interdependencies among projects and their underlying process model
that PGM tools require. Besides support for a high level of collaboration and
coordination, PGM tools require an underlying object and process model for
project components that are context sensitive, and which allow for the transfer
of process information within the PMO.
14 Program Management: Managing Project Volume and Response Speed
16. Collaborative Strategies LLC
Information, Knowledge and Program Management
The scenario in Section 2 demonstrates the ability to provide context relevant
process information in a way that can be easily used by the target (person)
and turned into knowledge through that use. We see this happen all the time
in complex projects, and see it as a critical piece of PGM functionality we call
“Process Wisdom.” Figure 4 shows how the five tools evaluated support “Process
Wisdom” and relate that to their effectiveness as a program management tool.
It is important to be specific in our terms. In the Glossary section, we
differentiate between data, information, knowledge and wisdom. In program
management, we deal with all four, but the most important ability any
program management tool gives you is the ability to see what is critical about
a portfolio of projects so that you or your team can make the right decision
about a specific project, process or task. These decisions, or judgment calls
require the wisdom of experience.
In program management, it is critical not only to get the right information in
the right context to the right people on the right project, but it is also critical
to share this information with other “right” people to get the full value of a
PM tool. All of the tools we examined in this paper have some collaborative
functionality, but most of it is focused on a team project space, where
documents and project plans can be stored. Program management requires
more than a tool that supports a virtual project team. For a program manager,
the interdependencies and interpersonal interactions between projects are just
as critical to manage as the project team.
Program Management Effectiveness
Data Information Knowledge Process
Management Management Management Wisdom
Figure 4- Process Wisdom and Program
15 Program Management: Managing Project Volume and Response Speed
17. Collaborative Strategies LLC
Conclusion Vendors who are evolving a PGM tool from a desktop scheduling tool, adding
collaboration functions, and additional modules to support cost accounting,
risk management, etc., have created just that…PM tools with collaborative,
accounting and risk management functions - not a PGM tool. In summary, we
believe that PGM tools require:
1. An underlying model of projects and their possible variations.
2. The ability to roll up project models into portfolio and program views.
3. A database or project objects that can be shared.
4. The ability to support interactions between projects and portfolios of
5. The ability to support interactions between team members on different
projects that have similar problems or issues.
6. The ability for the program manager to tie costs to specific tasks,
processes and resources and to allow simulations of project outcomes
as these variables are changed.
These six sophisticated features (on top of standard PM features/functions) are
required by PGM tools. Although one or two of the vendors evaluated had more
sophisticated task-based accounting and risk management than TCPM, it was the
overall ability and flexibility to support an underlying project/process model, re-
use some of the project framework (project objects) and the automated sharing
of critical information that lead us to see TCPM as the tool that came closest to
meeting all the PGM criteria we discussed in this white paper. While tools from
Primavera, PlanView, eProject and Meridian, all had sophisticated PM functions,
none of them were built to be PM tools, but rather they are desktop scheduling tools
that are being evolved into program management tools.
However, there is a paradigm shift that needs to occur if these tools are to evolve to
the PGM level. This shift requires the underpinning of a database to not only store
the project model and allow pieces of this model (project objects) to be shared
between projects. In addition, a consequence of this underlying project model
is “Process Wisdom” that automatically allows process information to populate a
project model and deliver this information in context to the appropriate project role,
so that it can be converted to knowledge through correct action and communication
for increased project success.
If you are interested in more information on DPM, project tools, and
program management, please see the Collaborative Strategies website at
www.collaborate.com or contact us at 415-282-9197.
16 Program Management: Managing Project Volume and Response Speed
18. Collaborative Strategies LLC
Glossary The following is a list of commonly used terms and their definitions that were
used in this white paper.
Task - An agreed upon action taken by one or more people to help reach an
agreed upon goal.
Project - Composed of a group of tasks managed in a coordinated manner to
help achieve a specific goal.
Project Management - The dictionary of computer terms defines project
management as “The process of planning, organizing, staffing, directing and
controlling the production of a system.”
Program - Defined as “. . . a group of projects managed in a coordinated way
to obtain benefits not available from managing them individually,” by the PMI
Guide to the Project Management Body of Knowledge.
Template- A template is a device to co-ordinate the production of a collection
of standard items. Template definitions from dictionaries include: Any structural
pattern which a set of forms fits or on the basis of which its members can be
specified. The Concise Oxford Dictionary of Linguistics, © Oxford University Press
1997; A pattern or model that is used as a starting point for an operation, with
the user adding to it or modifying it as needed. Compact American Dictionary of
Computer Words © 1995, 1998 by Houghton Mifflin Company.
Model – A dynamic superset of all possible variations and conditions within a
program. The underlying “model” for projects in Program Management means
that one does not have to build a new template for a project each time one or
more of the variables of that project are changed. The “model” also eliminates
the need to manage the rapid proliferation of templates that is common with
project management tools.
PMO - The PMO is “The group of technical, business and management personnel
assigned full time to a program or project in support of the Program/Project
Manager. The group may include personnel from participating organizations.”
Data - is bits and bytes.
Information - As humans we take that data and put it into context so it has some
relevance for us, which turns that data into information (an active process).
17 Program Management: Managing Project Volume and Response Speed
19. Collaborative Strategies LLC
Knowledge - Information once internalized (learned and understood), is still
information, it takes another active process (communication or application of
the information into some sort of action) to turn it into knowledge.
Wisdom – Is the experience to know when and how to apply knowledge for the
Any type of collaboration requires interaction around some type of information.
In looking at collaboration for the last 15 years, we have been able to reduce
collaboration to its component data types. They are:
• Structured data – the kind of data you would find in a field of a
• Unstructured data – this document is a good example.
• Tasks - an agreed upon action a person must take to reach an agreed
• Conversations – interactions (either in real-time or not) between
two or more people about one of the other data types for a specific
purpose or goal.
In addition, Collaborative Strategies has created a taxonomy to catergorize
over 1000 tools that boast collaborative functionality today (see figure 5
below). As mentioned earlier in Section 1, DPM tools, PM tools, and program
management tools would fall into the center square in the CS taxonomy, as
they do include “virtual workplace and process” functions. In addition, although
we have knowledge and document management in different categories in this
taxonomy, all project tools seem to have some rudimentary capabilities in both
of these areas, but it is not their primary functionality, which is to schedule and
coordinate projects, track resources, and support project teams.
Tools that support teams and by extension projects fall into our category of
“Distributed Project Management and Virtual Workplace and Process Tools. There
is a sub-category which we call DPM tools (distributed project management) that
are specifically focused on managing projects over time and space (see 2002
– 2003 DPM update http://collaborate.com/announcements/announce_6.html.
18 Program Management: Managing Project Volume and Response Speed
20. Collaborative Strategies LLC
Typical Participant Group Size Audio/Video
Virtual Classroom Tacit KM and
Distributed Intellectual Capital
Collaborative and Process
Unified and Wireless
Figure 5: Collaborative Strategies Functional Taxonomy
Collaborative Strategies has other resources available that cover the entire collaborative
marketplace. Please visit our website at www.collaborate.com, or email us at
firstname.lastname@example.org or contact us by phone at +1.415.282.9197.
© 2003, Collaborative Strategies, LLC. All Rights Reserved.
19 Program Management: Managing Project Volume and Response Speed