Program Management


Published on

Published in: Business, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Program Management

  1. 1. Collaborative Strategies LLC Program Management Managing Project Volume and Response Speed by David Coleman Managing Director, Collaborative Strategies Table of Contents 1 Introduction 2 Background and Evolution of Program Management 5 The Rise of Program Management Tools 14 Building or Evolving for Program Management 16 Conclusion 17 Glossary
  2. 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 provided. 1 Program Management: Managing Project Volume and Response Speed
  3. 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 ( 6.html). 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 tool. 2 Program Management: Managing Project Volume and Response Speed
  4. 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 Web front-end based project project project project portfolio program for LAN-based management scheduling scheduling management management management tools tools tools tools tools (DPM) tools tools AEC/Owner Specific New Product Management process and Development industry IT/SW project tools PS Development Automation Figure 1: Evolution of Program Management Tools 3 Program Management: Managing Project Volume and Response Speed
  5. 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. Project Meeting Meeting Results: Status Reporting Notes, Decisions Task Management Task Notifications Team Member 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” Copyright © 2000, The Jensen Group, Northern Illinois University). 4 Program Management: Managing Project Volume and Response Speed
  6. 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 (MPM) tools. 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. 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 after that. 6 Program Management: Managing Project Volume and Response Speed
  8. 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. 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. Interaction Program Management Management Response Speed Project Multi-Project Management Management LOW Process Complexity/Volume HIGH Figure 3: Tradeoff Between Complexity/Volume and Reaction Speed 8 Program Management: Managing Project Volume and Response Speed
  10. 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. 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. 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. 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 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 Rol-Aids 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 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. 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 has reviewed. 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. 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, and Coordination. 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 management. 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. 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 Thumbprint Plan View Primavera Meridian eProject Data Information Knowledge Process Management Management Management Wisdom Figure 4- Process Wisdom and Program Management Effectiveness 15 Program Management: Managing Project Volume and Response Speed
  17. 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 projects. 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 or contact us at 415-282-9197. 16 Program Management: Managing Project Volume and Response Speed
  18. 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. 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 greatest effect. 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 database. • Unstructured data – this document is a good example. • Tasks - an agreed upon action a person must take to reach an agreed upon goal. • 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 18 Program Management: Managing Project Volume and Response Speed
  20. 20. Collaborative Strategies LLC Portals and Online Communities RTC: Web/ Typical Participant Group Size Audio/Video Conferencing and Virtual Classroom Tacit KM and Distributed Intellectual Capital Project Management Virtual Workplace Collaborative and Process CRM Collaborative Content Management LMS, LCMS Unified and Wireless Messaging Synchronous Asynchronous Figure 5: Collaborative Strategies Functional Taxonomy 2002-2003 Collaborative Strategies has other resources available that cover the entire collaborative marketplace. Please visit our website at, or email us at 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