Summary

• All projects need some type of operational infrastructure to operate efficiently.

• Agile projects need an infrastructure that's more focused on managing the execution phase of the project rather than the planning phase, which a majority of available software tools are geared toward.

• Project management infrastructure offloads administrative PM tasks from the project manager, thereby enabling him to focus on higher-level duties.

• Ideally, project management infrastructures should have specialized and dedicated resources allocated to develop, support, and operate them, including a process developer and program analyst. These resources are part of the umbrella project management office, but generally outside of any specific project team.

Sample Agile Project Management Infrastructure

Figure 10-4 illustrates the architecture of an operational PM infrastructure. The operational PM infrastructure described here refers to a program (i.e., a group of related projects with common overall objectives), but it can be scaled back for a single project.

Figure 10-4: Architecture of an operational PM infrastructure.

An integrated PM infrastructure is an efficient way to capture and distribute critical project information to various stakeholders (i.e., management, project managers/leaders, and contributors). This is especially true for agile programs that are composed of many individual but linked projects. A change in one project may have a ripple effect on several other projects. Likewise, a shift in high-level strategy or functional direction could also have a ripple effect through various individual projects. It is generally preferred to have a dedicated resource, such as a program analyst, to own the collection, analysis, and dissemination of information that flows through the operational infrastructure.

Operational PM Infrastructure Workflow

The following table describes a manual implementation of an operational PM infrastructure. The primary intent is to show how the major pieces of the PM infrastructure interact with each other to efficiently create the project information needed by management and project managers to drive programs forward. Detailed descriptions and instructions for individual PM tools/processes are available as separate documents, and the chapters where you can find them are cross-referenced.

An electronic copy of this process can be downloaded from http://www.xocp.com.

Working Teams

Overview	This section represents all of the working teams in an organization. Working team is defined to mean groups that are working on completing a given (i.e., part of a) project, whether large or small. In many cases, teams are aligned with projects. However, a working team can also be a small group that is quickly brought together to solve a particular issue and later disbanded, a functional group working on process improvement activities, or a management team dealing with steering the overall program. There are two ways for project teams to get program information, on demand or via formal reports, which are discussed below.
Information on demand	Project information is often made available online via the Web or a shared drive. These repositories of project information can be accessed by team members on demand and, ideally, are managed by the Program Analyst. This is the best place to get real-time data and information since it should be updated continuously as new data flows in.
Reports	The second, and arguably more valuable, way that project stakeholders can receive project information is via reports. The Program Analyst is responsible for organizing and analyzing the project data and then generating certain regular reports, which are described below. The current report formats should be customized to meet the needs of individual team members.

Operational PM Data

Overview	This section is the main repository for project management data. Ultimately, this data is processed and analyzed (by the Program Analyst) with the objective of providing valuable support information to the various project managers to use in leading their projects. PM data may be generated and collected in many forms, including all of the elements described below.
Project Data Sheets (PDS)	See the Project Data Sheet Template and Workflow (Chapter 7) for details. Project Data Sheets are core elements in the operational PM infrastructure. These can be thought of as project executive summaries that are used to quickly and efficiently communicate the project "plan". Because they do not require extensive detail, they can be created with minimal effort by project leaders and/or project managers.
Gantt charts	These are detailed project timelines. While the Project Data Sheet describes the high-level project milestones, the Gantt chart contains the individual tasks leading up to each milestone, along with their respective characteristics such as owner, duration, dependencies, etc. Not all projects require detailed Gantt charts depending on the overall scope, but when applicable, they are a good way to think through the sequence of project details.
Network diagrams	See the Project Data Sheet Template and Workflow (Chapter 7) for details. Network diagrams provide a high-level view of the various project pathways and decision points and can be invaluable in guiding a project in an agile environment.
Action items	See the Action Items Tracking Process in Appendix C for details. These are the many tasks that get assigned during the project execution phase but do not make it onto the project Gantt chart. It is critical to stay on top of action items, as well as tasks in the Gantt chart, for overall project success.
Issues tracking	See the Issue Tracking Process in Appendix B for details on identifying and categorizing project issues. Basically, this is a way to track real-time issues. The objectives of having such a process include prioritizing activities, identifying cross-project influences, and maintaining visibility on key issues so that they are driven to resolution. Lessons learned in resolving issues can be added to the knowledge base to help with future similar situations and to keep different parts of the team from wasting time by revisiting closed issues.
Risk identification, assessment, and mitigation	See Risk Management Workflow (Chapter 8) for details. Risk management should be initiated during the tail end of the project planning process and reassessed periodically throughout the project. There are many benefits to employing a risk management process. They include setting realistic project expectations by maintaining visibility of risks, quicker recovery of problems through previously conceived contingency plans, and lower impact of potential problems through preventative actions. There are four basic parts to the Risk Management Workflow: Identify potential risks. Assess the risks. Make plans to address the risks. Reassess the risks throughout the project.
Project status reporting	See the Project Status Reporting Process in Appendix A for details. Status reporting is a key PM element during the execution phase of a project. The primary intent is to have a consistent mechanism for project managers to report their progress against plan. Using a consistent process enables status to be easily rolled up to the program and business levels.
Knowledge management	See Lessons Learned Process (Chapter 5) for details. Emerging and agile organizations that are developing new project management infrastructure will inevitably go through some iteration as the new PM processes are tuned to their project and business environment. The fast pace of the agile environment often encourages us to forget our mistakes and just move on. This approach is probably the most effective at solving the immediate problem at hand, but is generally detrimental to the longterm development and optimization of the infrastructure. While we may have the good intention of going back to amend the processes and practices after the dust settles, it is easy to forget or never find the time to do so. The process should therefore be designed to be "light" enough so that it can be easily and frequently used to capture the lessons learned from the most recent projects and other significant events.
Meeting minutes	See Project Communications Plan (Chapter 4) for details. Meeting minutes, when captured properly, provide an excellent condensed history of a project. While we don't usually plan to look back very often, when we must, good meeting minutes are incredibly valuable. Additionally, the process of taking, condensing, and distributing meeting minutes is good discipline for project managers and helps set team expectations and tone for meetings. All project meeting minutes should be archived and made accessible to the team.
Meeting calendar	See Project Communications Plan (Chapter 4) for details. In an agile environment where there are numerous interlinked projects progressing simultaneously, it is necessary to coordinate communications/meetings at the portfolio-level, as well as at the project-level. Without this higher-level meeting coordination, it is very possible that the organization will experience redundancy on some issues while letting others slip through the cracks. The program should maintain a rolling meeting calendar, viewable by all team members, showing all of the various meetings taking place, their objectives, facilitator, and primary attendees.

Reports

Overview	This section represents all of the reports (organized and actionable information) that can be generated from the PM data previously collected after it's been properly analyzed and put into consistent templates by the Program Analyst. The Program Analyst and Process Developer should work together to understand the needs of their customers and continually improve the reports to meet their requirements. A few core reports are described below, but many other custom reports can be created as well.
Portfolio view	See the Portfolio Prioritization Process in Appendix D for details. This core report is designed to provide a one-page snapshot of all program activity. It is broken down into several categories: Strategy: The high-level goals of the business and the approach for attaining them Business Objectives: Concrete deliverables and/or milestones that, once achieved, will lead to the attainment of the business strategy Programs: A grouping of projects that, taken together, will lead to fulfillment of one or more deliverables/milestones required of a business objective Active Projects: Those that are staffed and actively being managed. Inactive Projects: Those that have been identified to be critical to overall success, but for which there is no current staffing. These projects are kept on the portfolio view so that they do not lose visibility.
Program status update	This core report is basically a roll-up or summary of multiple project status reports to the program level. It is designed to give a high-level snapshot of the progress to plan across multiple projects simultaneously. It includes general (Red-Yellow-Green) status and a summary of current issues and risks, but leaves out the details included in the individual project status reports.
Resource allocations	This core report is designed to give a high-level view of resource utilization approximately 3 to 6 months out, based on current project plans. A bar chart or pie chart graphic is very effective at conveying this type of information. A primary objective of this report is to provide a basis for an operational hiring plan for the program.
Management dashboard	This report is a combination of the Portfolio View, Program Status, and Resource Allocation reports. Through analysis and consolidation of related information, the Program Analyst highlights the critical few program elements that need management attention.