Figure 7-7: Planning effort over time using agile and classic planning methods.
Agile Strategy Plan to make planning a continuing effort throughout your project, rather than a single, large effort up-front.
The project manager leads the planning activity, and his key challenge in this area is to show the project team the value of planning in an agile environment. Your team needs to understand what to expect if you want their buy-in and support for the process. Management also needs to understand this new paradigm so that they can make decisions in the proper context. An up-front discussion with the entire team on how the planning process will be tuned for agility is critical.
An Agile Planning Tool
There is one planning tool that I’ve found to be exceptionally effective when used on the agile project. This is the Project Data Sheet (PDS). The PDS is a one- to three-page executive summary of a project that covers both classic and agile elements of project management required for success, such as a project description, objectives, milestones, timeline, and resource estimates. It gets the job done and is “light” enough that it doesn’t inflict undo pain on the team, which is exactly what we want in an agile environment.
First and foremost, the Project Data Sheet is a communication tool. By summarizing all of the critical characteristics of your project into the concise PDS format, you can easily share your project ideas with management, contributors, other project managers, and program managers to gain their support and feedback. If you find yourself running projects in an agile environment, it is likely that you have numerous smaller projects taking place simultaneously. Some projects are independent but many are interdependent. To keep the many projects aligned with business objectives and make the most efficient use of valuable resources, it is important that all project managers be able to concisely describe their project. Creating a “deck of PDS’s” allows management to readily assess the overall project portfolio without having to go into a question-and-answer session with each project manager just to get basic information. Everyone is stretched for time. Using the PDS format will greatly reduce the time and energy required of the project stakeholders.
Agile Strategy Use the Project Data Sheet format to create an executive summary of the project. The PDS, in turn, will provide a valuable communication tool in keeping the project on task to meet technical and business objectives.
The second major benefit of using the PDS format is that it is short and concise, unlike the comprehensive planning templates commonly created during classic PM (see Figure 7-8). When backed up by a detailed Gantt chart through the next major milestones, the PDS makes it significantly easier for the project manager to maintain the high-level and detailed parts of the plan as the agile project progresses. How many times have you seen teams put together fantastic in-depth plans that essentially become out-of-date as soon as the first unplanned event happens?
Figure 7-8: The basic planning tools in an agile versus classic environment.
An example of the Project Data Sheet is included at the end of this chapter. You can customize the template provided to encompass other key project elements that are unique to your environment. The main point to remember is that you’re trying to create an executive summary that can be quickly scanned for critical information.
There’s no doubt that project planning is a time-consuming yet valuable task. The unpredictability of the agile environment and very nature of innovative projects makes planning even more challenging. However, before any value of project planning can even be demonstrated, your project team must buy into and support the process. This chapter has looked at some alternatives to the standard project planning process that will help you to get that support from your technical team and, subsequently, add real value to project planning on the fuzzy front end.
Summary
By discussing the level of project uncertainty early in the planning process, you’ll set the tone for planning the rest of the project.
Agile planning is based on achievements and commitments to meeting them.
Network diagrams can clearly show the multiple pathways and decision points in an agile project.
The up-front planning effort should consist of a high-level network diagram showing pathways and decision points, plus a detailed Gantt chart looking out to the foreseeable horizon.
Make low-level planning a regular part of the project management culture.
Concise Project Data Sheets are an effective and “light” planning tool for agile projects.
Project Data Sheet Workflow
This section describes how to use the Project Data Sheet (PDS) when initiating a new project. This process will guide you through the fundamentals of project planning in a logical and concise manner, subsequently creating an executive summary of your project.
The PDS is a communication tool. By summarizing the critical characteristics of your project into the PDS format, you can easily and expeditiously share your project plans with stakeholders (e.g., sponsor, functional management, team members, other project managers) to obtain their support and/or feedback.
The PDS is designed so that individual sections can be easily included or omitted from the final output. Also, there are many different types of projects, and one process does not fit them all. You are encouraged to customize this process where applicable by modifying or adding sections.
Creating the PDS is an iterative process. It generally works well when a small core group (sometimes only the project manager) creates the first draft and then reviews/discusses it with the larger team, perhaps at a project kickoff meeting or project start-up workshop.
An electronic copy of this workflow and template can be downloaded from http://www.xocp.com.
Identify the Project and Project Team
Uniquely identifying the project itself, as well as the project team, is a simple step toward eliminating confusion and setting project accountability. In the PDS, only the names of the respective individuals are included. It is also a good idea to clarify the roles and responsibilities of these individuals; however, this should be done in a separate document from the PDS, such as the Communications Plan, so that adequate detail can be included.
Project Manager
This is the person responsible for managing the overall project.
* * *
Project Sponsor
This is the primary person who wants the project done and who is authorizing that resources be expended to complete it.
* * *
Team Members
These are the people who are contributing to the project.
* * *
Define the Project
A well-defined project sets clear expectations for the project manager, project team, project sponsors, and functional management. Everyone needs to know why they are doing the project and what they hope to accomplish. A good project definition can also head off confusion down the road by identifying, up-front, any ambiguous areas and challenges. It clearly differentiates what “is” and “is not” included in the project.
Why are we doing this project?
This is the project Problem Statement. It frames the project context for people not intimately involved. Since not all projects are undertaken to address a particular problem, this section may be omitted if appropriate or combined with the next section. However, if there is a particular problem that this project is intended to solve, then a problem statement is very valuable.
The problem statement should be included in the project description section of the Project Data Sheet.
* * *
What is this project trying to accomplish?
Write one or more high-level Objective statements describing what you hope to accomplish by undertaking this project. These statements are succinct and are essentially describing the scope of the project. To aid in bounding the scope, you may want to include an “Is/Is not” list to help minimize future scope creep.
These statements should be copied to the project objectives section of the Project Data Sheet.
* * *
How will the team approach the project?
This section should capture the technical and/or business approach to the project at a high-level. Discuss the methodologies that will be used to complete the project (not the ones used to manage the project), as well as how and where work will get done.
These statements should be copied to the approach section of the Project Data Sheet.
* * *
How will you know when you’re done?
This isn’t always clear, especially in a technology or product development environment. However, defining your success criteria will aid in planning the overall project.
You should start with the above-mentioned Objective statement(s) and translate them into major Deliverables that, when complete, will indicate that a key milestone has been reached or the project itself is complete.
For projects that may be open-ended, these major deliverables should reflect your thought process in approaching the project. While milestones may change as the project progresses, it is still important to capture the general direction that the project is taking so that resources can be planned, dependencies identified, etc.
The information collected should be copied to the deliverables section of the Project Data Sheet.