Project Planning Is a Contact Sport, Do It Anyway

Since the inception of Epiq Solutions back in 2009, we have tackled a range of advanced projects and product development efforts to get us to where we are today. Our SDR modules and turnkey RF sensing solutions all started life as an idea that then required execution by our engineering and production teams to ultimately deliver products to market. Like a lot of small companies, our early days were shaped by working feverishly on developing products that would bring value to customers. Working out of our COO Mike Shogren’s living room in those early days (which you can read about here) cemented a culture of scrappy (read: do whatever it takes) innovation. But recently, as we found ourselves with a growing list of both internally- and customer-funded projects and a growing team to execute those projects in a cost-effective way, it made sense to re-evaluate our project planning. We determined that we needed an approach to make sure our team members have clarity and focus on the right priorities across the right set of projects to deliver the most value for our customers. Much easier said than done.

Fundamentally, project planning is hard. Nobody has a crystal ball to gaze into the future, so trying to make educated predictions beyond a few months with any practical level of certainty is simply guesswork, which can make resource scheduling and product delivery really tricky. The start date for a project, especially customer-funded projects, could be two weeks or two months or two years from when a proposal is delivered to a customer (yes, this much delay actually happens sometimes). Once an engineering project starts, it often has its own unique “unknown unknowns”, especially when pushing the state of the art. Combine that with projects that often involve multiple functional areas of hardware, software, and FPGA development happening in parallel, and the planning challenge is further amplified. For internal projects that we direct and fund ourselves, we have more control regarding the timeline and milestones, but our goal is to have a lighthouse customer helping guide development to fill a real-world need they have and that is aligned to our roadmap.

Cage Match Approach: Project Planning, Three Months at a Time

In hopes of striking a balance between being adaptable to our customer's needs and not getting whiplash in the process, we started planning and prioritizing our work projects one quarter (three months) at a time back in 2020. We refer to this process internally as our quarterly project planning “Cage Match”, where we methodically plan our project activities each quarter that deliver the most value for our customers for a three-month window, while whittling down the lower priority, less urgent activities as we go. This doesn't mean that an entire project will run start-to-finish in a quarter. It means that our planning activities (where we break down our work into activities that are scoped for completion in a timeframe between one and four weeks) will be projected out for a three month window at the start of each quarter. The key here is that we are committing and prioritizing our team members’ time and resources for a specific time window, and we are willing to stick to that plan for the quarter.

Naturally, plans rarely go as expected (the “unknown unknowns”, as they say), so sometimes the scope of the activities for a project in a quarter may need to be reduced as unpredictable roadblocks are hit during development. The idea with this "fixed time, variable scope" approach is adapted from the folks at Basecamp, with the intent being that our team is willing to make bets in increments of three months to achieve specific goals for a given project. This may mean that we start a quarter with a set of eight development activities for a given project, but halfway through the quarter we realize that we are only going to get six of them done in the remaining time. We work to ensure that we prioritize the six that are most useful, with the two remaining that didn't get completed being up for grabs to be considered for the next quarter (and we may decide to focus on other higher priority features for the project that need attention during the next quarter). This mindset provides the flexibility to revisit our project priorities every three months and adjust as needed, while also minimizing the whiplash caused by changing priorities mid-quarter. Since implementing this approach, it has been an exceptionally rare case where we add activities to a project (or new projects) mid-quarter.

It is worth noting that the “fixed time, variable scope” mindset can be a challenge to get used to, especially as an engineer. The idea of adjusting what “done” looks like for a development activity to fit a given time duration can be unsatisfying, since engineers are often seeking a solution as they envision it, but which may take an indeterminate amount of time. The magic is in recognizing and tracking progress along the way to give sufficient time to adjust what “done” could look like within the time window allocated, while still providing some level of utility/value for the project or customer. This provides an opportunity to tackle additional, prioritized enhancements/improvements for the development activity in future planning periods with the benefit of all the insight learned along the way.

So, what does a quarterly planning session look like at Epiq Solutions and who is involved? Our product/project managers, project technical leads, and functional engineering managers are all involved, and use a customized Google spreadsheet with a set of processing scripts that run behind the scenes to gather the needed data and provide insight (more on the Cage Match spreadsheet later in this blog). The graphic below shows the major steps we use in our planning process:

More concretely, here is a summary of the planning process that plays out in the current quarter while planning the next quarter:

• 45 days out from the start of the quarter: The RF Sensing Solutions product manager and the SDR Modules product manager identify the list of candidate projects for the Cage Match that will likely have development activities performed in the next quarter.

• 35 days out from the start of the quarter: The list of "next quarter" projects is shared with the engineering functional managers and tech leads to confirm that it covers the projects being contemplated for the quarter.
  
• 30 days out from the end of the quarter: Starting with the list of "next quarter" projects, the tech lead for each project works with their project team for currently active projects, or the planned team members for new projects, to identify the urgent work that needs to be completed in the next quarter. This work is broken into activities that are between one to four weeks duration. Each activity is enumerated with a short description of the desired task outcome along with the people ideally slotted to handle the work and the estimated duration for each individual (in one-week increments).
  
• 30 days out from the end of the quarter: In parallel with the tech leads doing their planning at the project level, each engineering functional manager works with their functional team (hardware, software, FPGA, and test) to determine how many weeks of project work are available for each member of their team next quarter. A typical quarter has 13 weeks, but vacations, sabbatical, maternity/paternity leave, managerial responsibilities, ongoing customer support, and other necessary activities eat away at the time our team members could potentially spend on projects. It would be foolish to assume that each person gets the full 13 weeks towards projects, so this is a critical step to get a thumb-in-the-air of what reality looks like for each team member’s availability. It isn't intended to be perfect, but the big hitters should be accounted for here.
  
• 14 days out from the end of the quarter: At this point, the tech leads have enumerated their "next quarter" project activity requests in the Cage Match (what, who, and how long), and the functional managers have wrapped up their project work availability summary for their team (also in the Cage Match). From here, the most important thing is to identify anyone who is severely overloaded or underloaded. If someone is teed up for 23 weeks of project work in a 13-week quarter, that is a problem. Similarly, if someone is teed up for four weeks of project work in a quarter, that is also a problem. Both the functional manager for the overloaded (or underloaded) individual plus the tech leads vying for the time of the individual are involved to help resolve any workload issues. Adjustments are made directly in the quarterly Cage Match spreadsheet for each project. The goal isn't to get it perfect but to get it reasonable. An unofficial metric of "reasonable" is within +/- 15% of the number of weeks available to work in the quarter for the individual. Improving accuracy past this involves either time travel or crystal balls that we do not currently have at Epiq Solutions, so our time is better spent "doing" than trying to plan out with higher fidelity.
  
• 7 days out from the end of the quarter: Once the functional managers and tech leads have done their Cage Matching to balance things out, the final step is to determine if additional prioritization is necessary to whittle projects or activities down further based on the full scope of loading across our entire engineering team. Ideally, Cage Match balancing will resolve any surfaced issues sufficiently. If it doesn't, then we make decisions based on business interests, a deeper understanding of a customer's timeline, and any other project-specific factors at play. This final round of decision making is made by our RF Sensing Solution product manager and our OEM SDR Module product manager with Epiq Solutions’ co-founders (John, Aaron, and Mike (JAM)) getting involved to break ties if/when needed.
  
• Day 1 of the next quarter: The summary of projects plus work activities for the quarter is finalized and shared with all the teams. A list of project-level milestones is also summarized in an easy-to-read chart in the Cage Match so that it is possible to see ALL larger project milestones for the quarter at-a-glance in a single sheet. The tech leads for each project meet with their respective development teams during that first week to review priorities and answer any questions, and we get down to business. The summary of projects plus work tasks plus milestones should be gospel for the quarter and translated into Jira where they will be tracked for the quarter by our project managers.

What Is the "Cage Match" Spreadsheet?

We've often found that tools for project planning don't do exactly what we want. In some cases, this means that there isn't an easy way to script/interact with the data contained within programmatically. This is one of those areas where having some control over how things work is super helpful, and while it is often possible to hire expensive consultants to do your bidding, alternate off-the-shelf variants that get the job done are also out there. Thus was spawned our Cage Match Google spreadsheet backed with ActionScript that we are now using for quarterly project planning. This sheet fills five main voids:

1. It provides a way to collect the list of "next quarter" projects (and milestones) in summarized tables that can be viewed along with some high-level data we want to see regarding each project all on a single page.
   
2. It allows the functional managers to capture how much project time is expected to be available for their team members each quarter so things like sabbaticals, PTO, maternity/paternity leave, etc., isn't overlooked when planning.
   
3. For each project, we have a tab where the tech lead for the project can capture the activities plus team members they'd like to handle the development activities (as well as a high or low rating for the activities). These activities are broken into chunks of no less than one week and no more than four weeks.
   
4. It provides an automated way to calculate loading across the engineering team viewed in a concise manner, as well as at a per-project level.
   
5. The sheet can then be used to work through overloads and underloads for team members until we are satisfied that we have reasonable balance.

It isn't a perfect solution but thus far it has improved our ability to detect overloads early and mitigate them at the start of the quarter.

What About Projects that Span Multiple Quarters?

It is totally fair to ask how we handle projects where we KNOW they are expected to execute over the course of multiple quarters. Most projects at Epiq Solutions actually play out that way, typically lasting 6-12 months, which is totally compatible with this process. The key here is to acknowledge that we don't know what we don't know, and that detailed planning beyond a three-month quarter may very well be wrong three months from now. Typically, when a project spans multiple quarters, the technical lead and project manager should be able to identify the target dates for future milestones past the next quarter. Those milestones and dates are important to shape the overall scope of the effort, but ultimately the details for each quarter will often need to be re-assessed as they come. Our ultimate goal is to be able to tackle a coarser version of our Cage Match process for assessing functional area work loading by quarter for the next four quarters without getting into the detailed planning for any quarter other than the current one. This will help identify longer term functional area overloads (i.e., “hmm…it looks like we’ll need more embedded software engineers starting in 4Q22”) and help us drive our hiring plans for the next year.

No Perfect System

For most engineering projects that are pushing the boundaries of technology, we have found that relying on detailed, long-term project planning with any expectation of accuracy is unlikely, and ultimately, counterproductive. It is better to anticipate change and embrace detailed planning sessions that happen over shorter time horizons (in our case, every three months). Each new planning session brings another chance to adjust priorities and build upon whatever insight was learned in previous sessions. The clarity and focus that can happen with this mindset has made a big difference for our engineering project planning efforts, and hopefully the insight shared here will be useful to other companies struggling with the same challenges.