Project Manager. With the previous two roles defined, the project manager doesn’t have to develop or maintain tools and processes, become an expert user of tools, maintain detailed project data, or watch for low-level problems. She should be examining the environment external to the project (to ensure that the project remains aligned with core business objectives), facilitating the resolution of conflicts and issues (identified by the program analyst), managing communication with key stakeholders, performing other duties described in Chapter 5, and generally guiding the team and project forward.
Agile Strategy Break up your project management duties into three distinct roles—the process developer, the program analyst, and the project manager—to both facilitate the operation of your project infrastructure and motivate your PM team.
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