Week 3 of Annual Planning in an Agile World is all about the benefits of planning and funding in discrete and regular increments. If you’re interested in reading about how I got here, you can find the previous posts here: Annual Planning in an Agile World: The Problem at Hand (creativeopsgroup.com).

In last week’s post, I talked about creating what I call “Organizational Epics.” They are defined by gathering the Voice of the Customer and gaining a deep understanding of your business processes, as well as any root cause analysis done on processes that are less than optimal. I also talked about linking these Epics to cross-functional organizational priorities and a Value Stream (aka End-to End Process).

The next step as you think about funding, is understanding if these Epics are:

• Foundational Epics – work that must be done as a dependency to enable other scope items.
• Operational Epics – work that must be done in order to “keep the lights on.”
• Strategic Epics – work that will enhance the organizations’ ability to delight customers, gain market share, or disrupt the industry.

It is important to understand this level of detail so that work can be done in the appropriate order, thereby increasing overall throughput.  But the real key is that the Epics should be distinct and achievable. If your Epic is “Implement a new ERP system” you should probably stop your planning there. An ERP implementation goes far beyond an Organizational Epic, will take multiple years, doesn’t account for any foundational or planning work, and realistically doesn’t need $10M+ in funding for next year.

If the strategic organizational goal is to replace the existing ERP system with a SaaS product, Functional and Technology leaders should then look at breaking that Elephant into more bite-sized pieces. Related to an ERP, a starting list of Epics might be:

1. Develop System Architecture for a SaaS-based ERP (2 months, foundational)
2. Gap Analysis of Current and Future State Architecture (3 months, foundational)
3. Foundational infrastructure upgrades (9 months, operational)
4. Organizational Impact and Readiness Assessment (3 months, foundational)
5. High-level ERP Scope Identification (6 months, foundational)
6. Data Preparation (9 months, foundational)
7. Create an RFP for an ERP (2 months, foundational)

The above seven items are primarily foundational Epics that should be completed prior to even selecting an ERP system. The above discrete pieces of work can easily be estimated and funded, and a good Project Manager could look at each of these items, understand what needs to be accomplished, and ensure execution of those items within set timeframes. Using the above perfect-world estimates, this work would take about 12 months holistically and are the appropriate first steps organizationally and technically. It would be easy for a Resource Manager to estimate the amount of work necessary for any of these items.

Conversely, many organizations leaders think “Well, our IT department already knows all this” or “our data won’t take that long to prepare” or even “we’ll figure out the requirements during the RFP process” but this is flawed thinking. Many times, I’ve been the recipient of project and program budgets based on SWAG estimates that are underpinned by the shaky foundation of a list of unknown assumptions and risks (which never appear in the business case slides or excel workbooks).

At that point, the business case has been approved by the board, the funding is ready to go, and project and program managers are brought on board to lead these huge efforts. But as the work gets going, problems begin to arise almost immediately.

If you’ve ever heard the expression “We’re changing the tires on a car moving 60 mph” you know exactly what I mean.

• The front line becomes over-worked and exhausted from trying to get the foundational work done while also doing the operational and strategic work.
• Leadership becomes frustrated with the lack of progress across multiple initiatives and pushes harder for results.
• RAID (Risk Assumption Issue and Decision) logs begin to bear disturbing fruit.
• The level of complexity on all programs and projects increases drastically, leading to a lack of understanding around goals and vision at an organizational level.
• Project Managers spend more time trying to pull together those Silo’d leaders to educate them on the foundational issues instead of focusing on the work.
• Competing priorities overlap, timelines extend, and budget and resource management becomes extremely difficult.

If the organization would only plan differently these issues wouldn’t be so prevalent in the project world today.  If organizations were to follow a more Agile planning process:

1. Work would be prioritized based on customer needs and wants.
2. Barries to achieving those needs and wants would be documented and understood cross-functionally.
3. Strategic goals are broken down into Epics that can be discretely funded, managed, and completed on time and on budget.
4. The PMO focuses on managing the existing capacity against the organizational backlog to ensure value is consistently delivered in the most cost-effective way.