A challenge faced by organizations attempting to adopt agile practices is deciding what project management documents are valuable – which traditional lifecycle ones should be maintained and which can be discarded?
This is more common than one might assume owing to the reality that very few companies are able to implement a specific agile methodology exactly as this is usually not going to meet the needs of all of the different types of projects within their portfolios. What works well for a “start-from-scratch” application development project may not suit the needs of a business process improvement engineering initiative even though agile principles could help both.
While this is not intended to be an exhaustive list, here are some of the documents which should be used regardless of whether a waterfall, pure agile, or hybrid approach is followed.
- Project charter: In its most basic form, the charter authorizes the existence of the project and helps to align customer, stakeholders, and team on the expected outcome for the project. Without an approved, distributed charter, the team runs the risk of significant shifts in overall project direction beyond those which even agile approaches can address.
- Project plan: Size, content and structure can vary between projects, but there is still the need for a document which formalizes governance structure and processes for the project, identifies assumptions, prioritized constraints, resource requirements and provides an understanding as to how the project scope will be delivered and over what timeline. This latter information could be documented using a WBS and schedule on a traditional project, or via a work items backlog and iteration or sprint roadmap on an agile project.
- Decision records/requests: Regardless of how flexible a project is, there are going to be key decisions on which fundamental project outputs rely which should be formally documented, approved and shared. The volume of these is likely to be smaller on agile projects as compared with traditional projects.
- Change requests: Similar to decision requests, while these might be used to a lesser extent on agile projects given the likelihood of scope being the most variable constraint, there is still the need to formally acknowledge the decision of the customer to extend or reduce other constraints. One example of this might be the decision to close the project after the completion of the current sprint if the customer’s needs are met in fewer sprints than originally planned.
- Risk register: A disciplined risk management process is critical for both agile and traditional projects otherwise team velocity is likely to be a fairly unpredictable forecasting measure.
- Action and Issue logs: Although these are less used by the team on an agile project due to the use of standup scrums or similar tactics, the role of the PM is to remove hurdles from the team’s path and these logs will be a crucial communication tool with key stakeholders.
- Status reports: Performance measures will vary between agile and waterfall projects, but there is still the need to keep key stakeholders apprised of quantitative and qualitative information on a regular basis.
- Project close out report: Although this report can contain significantly more, at its most basic, it should provide an understanding of what was accomplished or delivered vs. what was expected/planned, and list outstanding activities or next steps to facilitate transition.
Purists from both waterfall and agile schools are likely to take exception to what they may perceive as too short or too long a list of PM documents. As with most PM practices, this list only reflects the “what” and not the “how” (or rather, “how big”) – that I leave to the individual practitioner as “just right” is always in the eye of the Ursine beholder!