What are Mid-Level Requirements – and Why Do We Need Them?

Published by Will Cuper

As we help our clients adapt to the State’s new Project Approval Lifecycle, we find we’re being asked to define “mid-level requirements” to support the alternatives analysis that happens early in the procurement process. For those who aren’t familiar with the Project Approval Lifecycle – a.k.a. PAL – the former feasibility study process has been divided into four stages, each requiring approval by the California Department of Technology (CDT):

  • Stage 1 – Business Analysis
  • Stage 2 – Alternatives Analysis
  • Stage 3 – Solution Development
  • Stage 4 – Project Readiness and Approval

The stages build on each other sequentially. As CDT’s instructions state, “The Stage 2 Alternatives Analysis Mid-Level Solution Requirements serve as a bridge between business objectives established in Stage 1 and the more detailed solution requirements developed as part of the Stage 3 Solution Development.” What does this mean? In short, we are helping our clients define what a solution must do – but not at the granular level needed for a procurement.

And why are agencies being asked for this level of detail during alternatives analysis? A quick review of approved feasibility studies for projects in the $6-$9 million range (submitted before the PAL process was implemented) found that feasibility studies included an average of only 51 requirements. Additionally, we frequently found ambiguous requirements that lacked the specificity necessary to estimate scope, schedule and cost, much less enable robust analysis of a range of solution alternatives.

Having developed feasibility study reports and requirements for the State over the last 14 years, Highlands Consulting is pleased to help pioneer the PAL guidelines – to help our clients ensure the success of their IT projects by clearly articulating the business need that links directly to a project’s objectives.