Using a POR to Enrich Your Company

What's old is new, what's new is old. There have been a lot of discussions over they years about having a plan of record (POR) to manage your software engineering or really any projects in your company. I will admit I am going to skew this toward technology companies as that is where I put this into practice, but it certainly applies in other industries. The ultimate goal of a plan of record in a tech company, is to make sure that all business stakeholders and engineering leaders are aligned. The goal is to get everyone working on the right projects and driving the company in the same direction. If you are unfamiliar with the concept here are some links that will either confuse or help you (maybe a little of both).

1. This is a link from Microsoft and I borrowed a bit of the first line of the article from here https://devblogs.microsoft.com/oldnewthing . This discussion is specific to particular product features and Microsoft jargon. This isn't exactly what I am after for this article.
2. This article talks about POR's and remote teams . Superficially, this is an interesting take because it mentions our post pandemic reality as so many teams are working remotely. It's also not exactly on point for me.
3. Here is a short video that describes a POR and is pitching a template that could be interesting. In general it is getting close to the point of this article.
4. Which brings us to something very close to what I wanted to say about POR. I love how this article describes how POR's can chain . You may have a POR for each member on your team that rolls up into the POR of the team which rolls up into a POR for your department which rolls up into a POR for all of engineering, and so on.

In real life, I have seen this work exceptionally well and I have also seen it fail fabulously. It really comes down to the amount of effort that has been put into creating the plan of record. Were all of the stakeholders considered? Did an outside factor come into play in a given quarter and blow up your POR (maybe an acquisition of another company, etc.). There can be many reasons why the best laid plans fall apart but in the end it's about accountability and measuring our progress toward our stated goals. How closely did we follow the POR for any time period (monthly, quarterly, yearly) and do we know why we deviated from the plan.

But first, we have to work together to create a plan. This means gathering all business stakeholders, project managers, and leadership and asking them to list out what they think we should be working on for the next month, quarter, or year and why. As an additional part of this exercise there needs to be some determination of the level of effort required or that we are willing to spend on each of these items. We should also have some definition of how we will measure the success of each item on the plan of record. Should this lead to an increase sales? Will it lead to faster software delivery times? Will it reduce the number of errors that customers encounter? Why are we doing this item and what are the ways to quantify if we are successful or not? The end goal of this exercise is to have a prioritized list of items that we want to work on that we think provide the most value to the organization at his moment in time coupled with what we think we can realistically do. This is likely going to be a heated debate but we want that type of passion from our POR team.

This is an appropriately complex problem because each stakeholder comes into the planning process with a different perspective and agenda. For instance, engineering will likely have several infrastructure and/or tech debt initiatives that they want to champion. While sales and the product team may be more focused on features that will keep us ahead of the competition or are required for us to match what our competition offers. This is exactly why we gather the stakeholders so they can pitch why their projects/initiatives should make the POR for any given month, quarter, or year. It's a necessary part of the process where everyone has to be open and work their way through to a final list.

Once we have a nice list of all of the items that our planning team thinks is needed/wanted along with time estimates for each of them we can begin to haggle over the limited resources the organization has to do the work. If we have a team of 20 developers, 5 quality assurance engineers, and 5 DevOps engineers, we have a finite number of resources to work on all of the items on our list. So the idea is to now take that list and put our limited time into an equal measurement. Whether we use hours, days, or weeks as a unit of measurement we essentially allocate resources to the POR and being the work of telling our teams what they should prioritize for the coming period(s). Unfortunately, not everything can get done because our resources are finite so we have to budget the use of those resources judiciously.

Next, whether the team uses waterfall, agile, or any other project methodology we further define the work into epics, stories, etc. Again, whatever is appropriate for how we run our teams (kanban, scrum, etc). We ask project management to do this task working with the team leads to make sure the projects are well defined and actionable. We then ask the team managers and leads to keep the team on track and within the POR's budgeted hours for each of the items on the POR that were assigned to their team. We also ask that they report on that progress so that the planning team knows how we are doing at any given time in relation to the plan. This likely involves using project tracking software of some kind (JIRA, Pivotal Tracker, etc). This could be where measurements like team velocity and other measurements are used to drive the teams and manage expectations.

The final step in the process is to measure the success of the team in following the POR. How did we intend to spend our time and how did we actually spend our time for any given month, quarter or year? Were we close? Did we get the most important work done? Did we estimate well or terribly? These are all questions that we can get answers to through the POR. We can describe what went well and why or how we ended up getting off track or staying on track with the plan of record.

The reason why I am a believer in having a POR is it helps keep teams moving in the same direction with purpose and intent. It's amazing what we can accomplish when we get our teams moving in unison toward common goals. It also is great to be able to report progress back to upper management, the board of directors, and ultimately to the shareholders in the business. The chances that those reports are positive are much higher if we plan well and stick to executing the plan.

If you have a few moments, I would love to hear your experiences with POR's, how you have approached them in your organization, what tools you have used to create your POR, and in general how it has worked out for you. Like most tools we apply to our business the more time we spend studying them and tweaking them based on our experiences, the more effective they can become. Happy planning and best wishes for the success of your POR's, may they enrich your companies and provide a better quality of life for your teams!