Attention!

The content on this site is a materials pilot. It represents neither changes to existing policy nor pending new policies. THIS IS NOT OFFICIAL GUIDANCE.

Overview

We’ll start with the highest priority rows of the Rubric and work our way through to the medium and lower priority rows. In this first course, you’ll touch on one lessoj from each of the primary indicators — outcomes-orientation, state capacity, procurement flexiblity, and iterative development.

Health indicator Topic
Outcomes-orientation Reading the map
State capacity Tech and product management
Procurement flexibility Progress and risks
Iterative development Demos not memos
Admin Course one - Report out

What this course covers

In this course, you will get a chance to engage with the highest priority elements of the project Health Tracker. The goal of this course is to build familiarity. When you are done, you’ll have a holistic sense for how the Health Tracker, as a tool, is really just the reporting stage of a process.

Subsequent courses will build your depth of knowledge regarding the practice of assessing software project management. When you are done with the first course, you’ll be ready to begin applying the tracker with confidence, and tackle the material in the second course.

Outcomes-orientation - Reading the map

Software project roadmaps are a powerful tool for orienting an outsider to the current state of affairs in the life of a service.

Ask to see the product roadmap and the overall roadmap.

  • Bad: There is no roadmap for the product / service or enterprise.
  • Meh: There is a roadmap but it is unclear when value will be delivered, product or enterprise roadmaps conflict.
  • Good: The roadmap captures how the product / service will evolve and demonstrates value to end users within 12 months, aligns with the enterprise roadmap.

State capacity - Tech and product management

Software projects are complex, creative projects that involve the orchestration of complex systems of hardware and software. The objective of this module is to lay foundations regarding the kinds of skills and capacities states should have for managing these projects. This will help you, as an SO, better support and evaluate the projects you are responsible for.

Ask the product and technical leads what their role is and what other responsibilities they have.

Look at the APD staffing plan vs. current staffing.

  • Bad: The state depends entirely on a vendor for vision and strategy.
  • Meh: State leads are identified but have limited time to lead the strategy and take direction from the vendor.
  • Good: State staff with IT experience have the bandwidth to lead the technical strategy with feedback from vendors.

Procurement flexibility - Progress and risks

Procurement flexibility is where the money meets the work. To understand that, we need to track progress. How are deadlines chosen? Who chooses them? Why? What stories are told when deadlines are hit and what stories are told when deadlines are missed?

Ask how the state knows what progress has been made.

Ask if there are known risks that may cause delay.

  • Bad: Little to no visibility into progress. Target dates and budget estimates are missed or frequently revised.
  • Meh: There's limited visibility into progress. Many dates are hit, but misses are surprising.
  • Good: State has full visibility into progress. Most dates are hit, and the state knows early on when and why they are not going to meet a date.

Iterative development - Demos not memos

The most important thing you can have in a project are demos, meaning working software. If someone gives you a report about a piece of software, the software probably doesn't work (ask me how I know). If someone shows you a video of a piece of software, the software may have worked once (ask me how I know). If someone shows you a piece of software, but they control it, the software barely works (ask me how I know). If someone lets you use a piece of software, they have confidence. It might work, it might break, but they have confidence.

Ask how the development and state team share in-progress work.

Ask to see progress. For example, join demos throughout development.

  • Bad: Nothing is shared until its completely finished, no code is shown.
  • Meh: In-progress work is shown, but it's always fairly polished, some code is shown.
  • Good: You see regular (once a month or more) demos ranging from very messy, incomplete work all the way to polished, finished products.