This second article in our series on Program Management (PGM), focuses on what it takes to manage a program successfully, and 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 examines in detail the 10 functional criteria that CS sees are critical for PGM tools, and moves on to examine how complexity and collaboration challenge the effectiveness of today's PM tools. By using a typical PGM scenario to help explain some of the complexity issues that define PGM we can highlight some of the key differentiators between PM and PGM tools (specifically models vs. templates).The Rise of Program Management Tools
As project management tools have evolved, they have added more and more capabilities. But have they added the right features and functions to make them 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 of these elements is important to a single project, think how critical they might be to someone managing a program of 50, 200 or 1000 projects? The basic project elements include:
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 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 after that.
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, IM, 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.
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 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 1.
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.
Figure 1: Tradeoff Between Complexity/Volume and Reaction Speed
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 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 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 25 raised to the 4th power, 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 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” on the Internet. The fact that Thumbprint had a number of critical collaboration capabilities built in, has helped adoption of the tool enormously.”
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. [WSD2] 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 approach.
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 RolAids like candy. George's greatest frustration, and source for cost overruns is that he can't react in time to a situation.
Bob is the site manager for Store 512, which is being built in Sasquatch, 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.
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 has reviewed.
The project management program automatically notifies Bob with an SMS message 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 PM 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.
The interview process 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, and Coordination.
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.
The Business of Going DigitalDigital business isn't about changing code; it's about changing what legacy sales, distribution, customer service, and product groups do in the new digital age. It's about bringing big data analytics, mobile, social, marketing automation, cloud computing, and the app economy together to launch new products and services. We're seeing new titles in this digital revolution, new responsibilities, new business models, and major shifts in technology spending.