Building the Plan of Record
tl;dr To drive alignment within your organization: stack-rank your priorities, pick the ones you must accomplish, and write them down for all to see. For this, a POR is a useful tool.
What is a POR?
On its face, a Plan of Record (POR) is a deceptively simple document that states intended deliverables over a period of time. (For this reason, PORs are sometimes called “Plan of Intent”.)
A simple document, yet powerful. PORs are easy to consume and exceedingly clear in setting expectations. At the start of the period, the plan is immutable (hence, “of record”) so at the end of the period, accountability is straightforward.
As an historical aside, PORs draw heavily from the 1926 Essay “The Giving of Orders” by Mary Parker Follett, a Management Theorist with considerable social work background. In 1954, Peter Drucker popularized her ideas with the acronym MBO, “Management by Objectives”, a concept familiar to any MBA. Some of the world’s largest organizations adopted Follett’s principles in the 1920s and 1930s and continue on to this day. The ideas are old, but they work. WorkMarket adopted MBOs and the term “Plan of Record” on the arrival of WorkMarket’s CEO Stephen DeWitt (an HP alumnus) and adopted the practice into a version appropriate for our company’s stage. In this post, however, we’ll keep it general to all stages.
PORs are versatile. You can create one for individuals, for teams, for divisions, and for whole companies… and you can chain them. PORs at the individual level can fold up into a team POR, a team POR into a division POR, and so on.
With linked PORs, everyone can see how everyone contributes to meet the company’s goals.
Further, since PORs are “of record”, it behooves the planner to put in the effort to ensure plans are defensible to anyone, manager or otherwise, who might ask “is this the most effective thing we can be doing right now?”
Planning for the Plan
While you can apply myriad methodologies to build a POR, we’ll use the Engineering Team’s preferred framework, OKRs, by way of example.
If you’re unfamiliar with OKRs — Objectives and Key Results — this is the document to read. Briefly, OKRs are designed to stretch team capabilities. Objectives provide clarity of purpose (the Why) while Key Results provide measurable goals (the What) towards accomplishing that Objective. However, only a fraction of Key Results are expected to be accomplished in-period. While OKRs can surface dependencies between people and functions, they do not enforce these dependencies— that’s what our PORs are for.
You can stack-rank OKRs to clarify which are must-dos and which are stretch. The must-do Key Results are added as Commitments to a POR. The remainder remain off the official commitment list, waiting in the wings should the plan need adjusting in-period and/or if capacity allows.
As you add top Key Results to your POR, check your dependencies against any adjacent teams (including both upstream and downstream) to ensure that dependencies are understood, acknowledged, and linked. Generally, the first round of OKR-to-POR will get you 90% of the way there. Dependency discussions account for the remainder of your time.
Once done, delivery expectations for you, your team, your adjacent teams, and across the organization are clear, providing accountability throughout.
It’s all right there, in summary, in your POR.
ProTip™: Link your POR Dependencies to other PORs so there’s no ambiguity in the planning stages. Better yet, put them in the same shared version-controlled document.
POR Accoutrements
Ultimately, humans comprise organizations. Until the robots fully take over, it’s important to consider that we (sentient meat) require more than vanilla procedural directive.
Individuals’ should include in-period activities that extend the team’s core delivery requirements, including:
- Professional development goals (e.g. classes, conferences, etc.)
- Company initiatives (e.g. our D&I work)
- Long-term strategic planning
And so forth. While they’re not measured nor held to strict performance targets, POR accoutrements help contextualize the human element of the job. It also helps to declare — on-record — intention of purpose, enabling colleagues to understand and support each other’s personal and professional goals.
Ok, now what?
PORs are designed to provide a framework for what to do, not a prescription for how to do it.
PORs are not project plans (another topic well beyond the scope of PORs). However, writing a brief Project Plan for each of a POR activity is a great place to start.
For many on our Engineering Team, PORs flesh out fairly directly into project plans, two- to four-page documents that generate a blizzard of epics and tickets within Jira, our system-of-record for product management. Oftentimes, the work deliverable is directly translatable from the POR itself as the “How We’re Going to Do It” is fairly straightforward.
However it’s sliced, most POR commitments are easily consolidated into an epic (or two), making it easy to track progress by measuring the ticket velocity over our normal workflow against our epic completion percentage.
PORs are not meant to hold details: they are meant to keep top-level promises in focus.
ProTip™: Link your POR Commitments to your Jira Epics to make it easy to track work against plan.
Smart Promises
Of the available objective-tracking methodologies (Pure-OKR, KPI, SMARTTA, ETC, etc.), we use SMART goals as our WorkMarket’s POR Commitments:
- Specific: objectives are targeted on a category-basis and well-scoped
- Measurable: indicators of progress are often binary (i.e. done/not-done) unless otherwise specified (e.g. 10% improvement)
- Achievable: if it’s on your POR, you’ve agreed it’s achievable
- Relevant: planning should have ensured this work is defensible and therefore relevant
- Time-bound: implied due dates based on POR length (for WorkMarket, that’s quarterly)
SMART goals help reduce ambiguity in deliverables, helping align expectations between both managers and individual contributors.
Promises Promises
PORs bring clarity to commitments, but in a fast-paced environment, sometimes objectives that were once deemed immutable suddenly seem a lot more flexible, if not completely unnecessary.
And that’s ok!
PORs are meant to be an immutable record of work commitments, but that doesn’t mean they can’t be amended. As priorities change, so too can PORs provided those adjustments are indicated within and that they preserving the original plan. (Human tend to adjust targets should things not be going as expected, but it’s important to keep record for future learning and accountability.)
Say that an individual contributor required that an external vendor release a product by a certain date, but the vendor delayed the release of a critical SDK which would leave 80% of their commitments unmet. That contributor’s POR would be amended, and those misses will affect upstream commitments. If that contributor participated in the OKR process, finding a back-fill POR Commitment is as easy as picking a new Key Result to commit to with the remaining time.
Recall: PORs cascade. With fully-linked POR, owners have clear visibility into the impact of those misses across the org and can make informed decisions on how to go forward.
To that end, PORs should have a changelog to monitor adjustments. WorkMarket uses GSuite to automatically tracks changes, but we also indicate adjustments with different formatting. This way, PORs are always useful at-a-glance.
DRIs
An acronym that unpacks to Directly Responsible Individual, DRIs are a shorthand for “who’s accountable?”.
A POR’s owner is the one person directly accountable for its execution. If a POR for a team comprises many goals, oftentimes we’ll tag the DRI next to that goal for easier visibility into who is responsible for what.
In the case where many people contribute to the same goal (say, a team of customer support folks each working towards a response-time goal), the overall metric (say, team mean response time) is owned by the team lead. Just as PORs cascade, so do DRIs.
What about Agile?
Under PORs, waterfalls can seem tempting, but are ultimately counterproductive. In our experience, even the best-planned, well-intentioned, enterprise-grade client builds that are contractually fit to a waterfall model wander off-track before the first line of code is ever written.
PORs are promises of achievement, not a prescription for a specific approach. While sufficient planning will ensure that promises are well-scoped to time, ownership on execution is up to (and agreed upon by) the individual contributor.
WorkMarket has no central dogma on agile, but we do adopt scrums and kanban on a team-by-team level, depending on team function and SLA requirements.
POR Pitfalls
Like any management framework, PORs have their limitations and pitfalls.
Scope
Perhaps the most common mistake we see is improperly scoped goals. If goals are too specific, they might send a team or individual down a non-relevant path. If goals are too general, there’s no way to see if anything was actually accomplished during the POR period.
- Make WorkMarket a household brand. (This is too general for a POR goal, but might satisfy the O part of an OKR exercise. How do you measure success here?)
- Increase organic conversions on our website by 10%. (This is a good goal and reasonable commitment: it is not restrictive in terms of how and it spells out a reasonable success criteria. For larger companies, downstream PORs might specify activities on how that number might be achieved.)
- Have phone calls with all CFOs on the 2018 Fortune 500 to foster a personal relationship. (This is too specific: Are phone calls the only vector into the CFO’s office? Do we know if having a personal relationship with CFOs will matter at all in terms of marketing? What happens if CFOs no longer use phones and only e-mail?)
WorkMarket uses SMART goals to help avoid these scoping issues.
Misalignment
PORs cascade both up and down. Teams and individuals with adjacent PORs must collaborate and plan accordingly to ensure everyone’s goals are aligned. Managers often step in here to help drive alignment and shepherd the process along.
Mal-aligned dependencies can lead to some spectacular company-wide failures. For instance, if a sales team commits to start selling Widget A as part of their Q2 revenue goal, but the logistics team didn’t commit to shipping Widget A until Q4, then it’s unlikely anyone is going to hit their goals, setting the company further back from meeting their stated objectives. This sort of issue should surface itself in the planning phase, but it would be painfully obvious out at the company-level POR should insufficient planning be done.
In this regard, the POR is something akin to a checksum of the planning phase.
Applicability
Recall from our historical footnote, the underlying concepts of PORs drew from years of study in effective management (Management by Objective / MBO), but the framework itself doesn’t lend itself to all teams nor all companies.
By way of example, a small company (under 10 people or early horizon one companies) still discovering its product/market fit would be better to organize itself on OKRs with stated experiments rather than on strict plans with stated commitments. PORs, so far as WorkMarket (a horizon one/two company with established product/market fit) uses them, optimize for predictable delivery rather than potential moonshots.
This is a long-winded way to say PORs are useful for some organizations, but not all. YMMV.
Conclusion
PORs are a helpful tool for driving alignment and clarifying commitments across an organization. With sufficient planning, they are easy to build, easy to read, and easy to communicate. Further, they help measure both individual and company performance for transparency and accountability.
As frameworks go, POR’s convenience and conciseness make it a good choice for high-velocity companies with growing pains, like WorkMarket.
Thanks
Thanks to WorkMarket’s engineering leadership team, especially Mike DeLelys, for reviewing early drafts of this post.
Special thanks to Jake Dietrich for not only designing the images and graphics throughout, but for tolerating my general lack of design direction and providing numerous revisions in-result.
