Occasionally ridiculed for being “not agile” or “too much documentation”, the “1 pager” continues to be used in many successful software projects and is the single most valuable centralised communication tool for ensuring decisions are clear and scope is maintained for diverse teams of designers, developers, testers and other stakeholders in an era of modern software development projects.
A good one pager process goes something like this:
An experienced member of the company drafts an initial document for management to review and sign off on. Any person in the organisation can draft the one pager, as long as they have a suitable level of expertise in the area that they are drafting for. The initial document should be short (one page) and defines the benefits, resources, timelines and expected costs that will be associated with the project.
The goal when drafting this stage is to allow the management team to review the project and decide whether additional resources should be allocated to the project or whether other projects should take priority over it.
The document is shared and if approved by management, additional resources can added to the project. Design, development, testing, project planning and other areas get involved, filling out their sections of the document and ensuring as much thinking about the project can be done up front, eliminating wasteful decision making later in the project.
If, after further research, the project can be delivered in accordance with the initially agreed constraints, it can then proceed through development without additional signoffs. If the project veers off track and becomes unlikely to deliver the expected benefits within the available time or budget at any stage, it can be escalated for review and additional resources can be assigned (or the project can be cancelled).
Long before I really understood the value of great project management, I used to laugh to myself every time I saw a one pager - after all - it was never just a single page.
Of course now I know better: the purpose of a one pager isn’t to keep the documentation to one page - it’s to keep the team all aligned, i.e. metaphorically all on one page.
The moment I realised the one pager was a communication tool (good) rather than more unnecessary documentation (bad) was a watershed one for me. That one realisation alone lead me to a much deeper understanding of the benefits of lean but structured project management approaches.
In any case, the benefits of one pagers are immense:
The one pager is a single, constant point of reference for any project for anyone who is interested in seeing what work is currently being delivered by a team.
It’s a simple concept with a simple name - used consistently, the one pager allows the team to worry more about the project and less about the process every time they start a new project.
It builds confidence in the team when used correctly - each member of the team knows that if the one pager is delivered successfully, the project will meet the management team’s expectations.
Conversely it forces management to choose their words carefully: If management signs off on a one pager and the one pager is delivered but the end result isn’t what they expect, the responsibility lies with the management team to ensure their approval process is improved.
The one pager allows for signoffs at different stages of the project, meaning the costs associated with the different stages of a project can be managed and contained sensibly and with management control.
It allows for easy delegation and divestment of responsibility: each stage of the one pager allows for further stages and has signoffs to ensure no resources are wasted and every stakeholder is included in the relevant discussions.
The one pager prevents discord and scope creep later in the project by ensuring every stakeholder has a chance to input in a project before it starts
(“You think this was a stupid idea now? Well why didn’t you say that at the start of the project? We each made the best decisions we could then - so let’s take responsibility for improving it rather than complaining about it”)
The one pager gives everyone in the team a structured way to input into a project, meaning everyone feels involved in the project, leading to improved productivity and a higher sense of ownership.
It allows project management to centralise the input of all project stakeholders and contributors, meaning projects can be planned with a greater degree of accuracy and in a more visible way.
It adds a set of checks and points of responsibility to ensure that projects either come in on time and budget, or are escalated back to management.
It creates a single format for management to compare and contrast different project ideas, ensuring that ideas can filter up from any area of the company for consideration.
The most basic one pager has two key sections that are relevant to different stages of the project - the header and the body.
The header section should give management all the information (at a high level) necessary to decide whether to invest further resources in the project. It should include:
Once the header is complete, a decision making team (management, the product owner, the one pager owner) should meet to discuss whether the project merits taking the next step and adding additional resources.
Often it is necessary to invest some time in creating the one pager. Prototypes, technical research and other aspects of a project may need to be carried out before bringing the one pager for signoff. These experiments and iterations should however be highly restricted in resources and scope until such time as the project becomes a company priority.
90% of a company’s ideas never get implemented, therefore it should be normal and necessary that a one pager, with relatively few resources invested at this stage, should be paused, cancelled or sent back for further research before the project should be expanded to the next phase.
Some companies add interesting additional requirements in their one pagers, for example Amazon require a fully written press release relating to the project to accompany the one pager, leading to a user and marketing focus of all their projects.
The body of a one pager should only be undertaken once the project has received management signoff (with the exception that any research already completed should be included here, and not in the header). Additional resources can now be assigned to the project.
Once the project is ready, all stakeholders in the project should meet to fill out the relevant sections. In a typical software development team, this includes:
The UI/graphic designers (who will create additional prototypes, high fidelity graphics and assets for the development team)
The developers who will be writing the code for the project. If there are a large number of developers, a lead or project lead should be nominated to ensure that the development side of the conversation doesn’t result in meetings devolving into technical discussions rather than purely user / project focused ones.
The QA team, which should detail their test plans and test acceptance cases in the document.
The project management function (scrum master, project manager, delivery manager etc)
Any other relevant stakeholders including marketing, support, operations who are required resources in the project.
Once completed and signed off, the project enters the execution phase. As long as it remains within the constraints of the one pager, there is no need to escalate or otherwise worry about failing to deliver the goals of the project. During this time, the header section of the one pager should not be updated (it has been signed off by everyone involved and therefore should not change without being escalated back to the management team).
During the execution phase of a project, the relevant stakeholders in the project are responsible for ensuring that the document is adhered to and reflects the work that is agreed. The entire team, but especially the project manager, needs to remain vigilant and escalate the project if it veers off track. If so, the project should be escalated back to the management team as quickly as possible.
Use Google docs or another similar distributed documentation tool to share the same document and make it available to everyone.
Lock the document and allow comments and suggestions only. Only one person (the document’s author) can approve edits to the document. This ensures that all changes to a project remain suggestions until approved by the author. It remains the responsibility of the author to accept and inform the team about updates to the document.
Ensure that all stakeholders have an opportunity to input into the document.
Incorporate a “future features” section in the document and use this when discussing the one pager as a team. This allows everyone to input ideas and suggestions, and have them added to the current project, or documented for future addition to the product backlog.
If the scope of a one pager needs to change but the overall project remains deliverable within the agreed time and budget for the project, no escalation is needed. If it is realised the benefits described by the project cannot be delivered in the available time, this should be escalated for discussion by the project manager.
Make the one pager accessible at all times. Two great place to place it are at the top link of your roadmap entry (using Trello or another Kanban/swimlane type tool) and the meeting invite when engaging in any project meeting.
Often the benefits of one pagers are not realised by each person individually and people don’t see the value in including “their bit” in the documentation. But the main benefits revolve around the different disciplines and stakeholders being able to input into the projects. Everyone has to input and everyone has to benefit from the one pager - otherwise it is not doing its job correctly.
Hard to define technical research that is performed in order to discover whether a project can succeed (e.g. if the technology works in the first place) should not be included in a project that has other success conditions. Instead, it should be run as a separate project, the results of which feed into the original project, and once completed, the project should kick off with a new or updated one pager.
We use 1 pagers in Fluid UI combined with Zenhub to manage our company roadmap.
Finally, you might be looking for a link to our own one pager template.
Happy projecting!
