www.eatingpolicy.com Open in urlscan Pro
172.64.147.169  Public Scan

URL: https://www.eatingpolicy.com/p/project-vs-product-funding?utm_campaign=post&utm_medium=web&triedRedirect=true
Submission: On June 17 via manual from NO — Scanned from NO

Form analysis 7 forms found in the DOM

<form class="_form_1h9fv_13"><input class="_emailInput_1h9fv_26" placeholder="Type your email...">
  <div id="error-container"></div><button
    class="pencraft pc-reset pencraft _buttonBase_kqk6u_1 _button_kqk6u_1 _buttonOld_kqk6u_37 _buttonOldColors_kqk6u_56 _priority_primary-theme_kqk6u_249 _size_md_kqk6u_127 _fill_filled_kqk6u_371 _grow_kqk6u_32 pc-justifyContent-center" tabindex="0"
    type="submit">Subscribe</button>
</form>

POST /api/v1/free?nojs=true

<form action="/api/v1/free?nojs=true" method="post" class="form _form_1mxvn_6" novalidate=""><input type="hidden" name="first_url"
    value="https://www.eatingpolicy.com/p/project-vs-product-funding?utm_campaign=post&amp;utm_medium=web&amp;triedRedirect=true"><input type="hidden" name="first_referrer"><input type="hidden" name="current_url"
    value="https://www.eatingpolicy.com/p/project-vs-product-funding?utm_campaign=post&amp;utm_medium=web&amp;triedRedirect=true"><input type="hidden" name="current_referrer"><input type="hidden" name="referral_code"><input type="hidden"
    name="source" value="subscribe-widget"><input type="hidden" name="referring_pub_id"><input type="hidden" name="additional_referring_pub_ids">
  <div class="_sideBySideWrap_1mxvn_10">
    <div class="_emailInputWrapper_1mxvn_57"><input type="email" name="email" placeholder="Type your email..." class="pencraft _emailInput_1mxvn_23"></div><button type="submit" class="button rightButton primary subscribe-btn _button_1mxvn_76"
      tabindex="0"><span class="button-text ">Subscribe</span></button>
  </div>
  <div id="error-container"></div>
</form>

POST /api/v1/free?nojs=true

<form action="/api/v1/free?nojs=true" method="post" class="form _form_1mxvn_6" novalidate=""><input type="hidden" name="first_url"
    value="https://www.eatingpolicy.com/p/project-vs-product-funding?utm_campaign=post&amp;utm_medium=web&amp;triedRedirect=true"><input type="hidden" name="first_referrer"><input type="hidden" name="current_url"
    value="https://www.eatingpolicy.com/p/project-vs-product-funding?utm_campaign=post&amp;utm_medium=web&amp;triedRedirect=true"><input type="hidden" name="current_referrer"><input type="hidden" name="referral_code"><input type="hidden"
    name="source" value="subscribe-widget"><input type="hidden" name="referring_pub_id"><input type="hidden" name="additional_referring_pub_ids">
  <div class="_sideBySideWrap_1mxvn_10">
    <div class="_emailInputWrapper_1mxvn_57"><input type="email" name="email" placeholder="Type your email..." class="pencraft _emailInput_1mxvn_23"></div><button type="submit" class="button rightButton primary subscribe-btn _button_1mxvn_76"
      tabindex="0"><span class="button-text ">Subscribe</span></button>
  </div>
  <div id="error-container"></div>
</form>

POST /api/v1/free?nojs=true

<form class="form _form_1mxvn_6" action="/api/v1/free?nojs=true" method="post" novalidate=""><input type="hidden" name="first_url"
    value="https://www.eatingpolicy.com/p/project-vs-product-funding?utm_campaign=post&amp;utm_medium=web&amp;triedRedirect=true"><input type="hidden" name="first_referrer"><input type="hidden" name="current_url"
    value="https://www.eatingpolicy.com/p/project-vs-product-funding?utm_campaign=post&amp;utm_medium=web&amp;triedRedirect=true"><input type="hidden" name="current_referrer"><input type="hidden" name="referral_code"><input type="hidden"
    name="source" value="post-end-cta"><input type="hidden" name="referring_pub_id"><input type="hidden" name="additional_referring_pub_ids">
  <div class="_sideBySideWrap_1mxvn_10">
    <div class="_emailInputWrapper_1mxvn_57"><input class="pencraft _emailInput_1mxvn_23" type="email" name="email" placeholder="Type your email..."></div><button tabindex="0" type="submit"
      class="button rightButton primary subscribe-btn _button_1mxvn_76"><span class="button-text ">Subscribe</span></button>
  </div>
  <div id="error-container"></div>
</form>

POST

<form method="post" class="form comment-input" novalidate="">
  <picture>
    <source type="image/webp" srcset="https://substackcdn.com/image/fetch/w_64,h_64,c_fill,f_webp,q_auto:good,fl_progressive:steep,g_auto/https%3A%2F%2Fsubstack.com%2Fimg%2Favatars%2Flogged-out.png"><img
      src="https://substackcdn.com/image/fetch/w_64,h_64,c_fill,f_auto,q_auto:good,fl_progressive:steep,g_auto/https%3A%2F%2Fsubstack.com%2Fimg%2Favatars%2Flogged-out.png" sizes="100vw" alt="" width="64" height="64" style="width: 32px; height: 32px;"
      class="_img_16u6n_1 _avatar_u4hgo_1 _object-fit-cover_16u6n_5 pencraft pc-reset">
  </picture>
  <div class="pencraft pc-display-flex pc-flexDirection-column _flexGrow_1w60r_230 pc-reset comment-input-right"><textarea data-gramm="false" data-gramm_editor="false" data-enable-grammarly="false" name="body" placeholder="Write a comment..."
      style="height: 96px;"></textarea>
    <div id="error-container"></div>
    <div class="pencraft pc-display-flex pc-paddingTop-8 pc-justifyContent-space-between pc-alignItems-center pc-reset"></div>
  </div>
</form>

POST /api/v1/free?nojs=true

<form action="/api/v1/free?nojs=true" method="post" class="form _form_1mxvn_6" novalidate=""><input type="hidden" name="first_url"
    value="https://www.eatingpolicy.com/p/project-vs-product-funding?utm_campaign=post&amp;utm_medium=web&amp;triedRedirect=true"><input type="hidden" name="first_referrer"><input type="hidden" name="current_url"
    value="https://www.eatingpolicy.com/p/project-vs-product-funding?utm_campaign=post&amp;utm_medium=web&amp;triedRedirect=true"><input type="hidden" name="current_referrer"><input type="hidden" name="referral_code"><input type="hidden"
    name="source" value="subscribe_footer"><input type="hidden" name="referring_pub_id"><input type="hidden" name="additional_referring_pub_ids">
  <div class="_sideBySideWrap_1mxvn_10">
    <div class="_emailInputWrapper_1mxvn_57"><input type="email" name="email" placeholder="Type your email..." class="pencraft _emailInput_1mxvn_23 _emailInputOnAccentBackground_1mxvn_49"></div><button type="submit"
      class="button rightButton primary subscribe-btn _button_1mxvn_76 _buttonOnAccentBackground_1mxvn_89" tabindex="0"><span class="button-text ">Subscribe</span></button>
  </div>
  <div id="error-container"></div>
</form>

POST /api/v1/user/profile

<form class="form " action="/api/v1/user/profile" method="post" novalidate=""><label for="name">Name (Required)</label><input autofocus="true" type="text" class="profile-name" placeholder="Type your name..." name="name" id="name"><label
    for="handle">Handle</label><input type="text" class="profile-name" placeholder="Type your handle..." name="handle" id="handle"><label for="bio">Bio</label><textarea class="profile-bio" placeholder="Say something about yourself..." name="bio"
    id="bio"></textarea><input type="email" class="profile-email" placeholder="Your email…" name="email"><label class="profile-signup-checkbox"><input type="checkbox" name="free_signup" checked=""> Subscribe to the newsletter</label><input
    type="hidden" name="confirmation_redirect_pathname" value="/p/project-vs-product-funding"><input type="hidden" name="photo_url"><input type="hidden" name="user_id"><input type="hidden" name="needs_photo" value="false"><input type="hidden"
    name="token">
  <div id="error-container"></div>
  <p class="left hidden">undefined subscriptions will be displayed on your profile (<a>edit</a>)</p>
  <div class="modal-ctas">
    <p class="skip hidden"><a class="small">Skip for now</a></p><button tabindex="0" type="submit" class="button primary">Save &amp; Post Comment</button>
  </div>
</form>

Text Content

EATING POLICY


SubscribeSign in

Share this post

PROJECT VS PRODUCT FUNDING

www.eatingpolicy.com
Copy link

Facebook

Email

Note

Other

DISCOVER MORE FROM EATING POLICY

In business, culture eats strategy. In government, culture eats policy. Here
we'll talk about the problems of state capacity (government's ability to achieve
its policy goals) and how to fix them. From the author of Recoding America.
Over 2,000 subscribers

Subscribe
Continue reading
Sign in


PROJECT VS PRODUCT FUNDING


MODERNIZATION SHOULDN'T EVEN REALLY BE A THING AT ALL.

Jennifer Pahlka
Jun 03, 2024
53
Share this post

PROJECT VS PRODUCT FUNDING

www.eatingpolicy.com
Copy link

Facebook

Email

Note

Other
13
Share


Photo credit: Scott Robinson, CC BY 2.0 DEED

A few months ago, I made a slide deck about the differences between funding
technology as projects and funding them as products1. Every time I’ve shown it
since then, people have asked me for a copy of the slides, so I thought I’d
share them here in case they can be helpful more broadly. I also wrote up the
narrative that goes along with them and included it in my Congressional
testimony in January, so I’ve adapted that below. A link to the slides
themselves is at the end.

As with most of what I talk about, this is nominally about technology in
government but applies far beyond tech. We need to acquire ongoing capabilities,
not static things, in lots of parts of government.

***

We procure and fund software as if it were static, and thus make it both worse
and more expensive. This is best illustrated through a series of graphs, each
one entirely fictional but representative of two fundamentally different
approaches to funding software.


Subscribe



Government typically follows a “project” model. The following graph shows the
number of staff who work on an IT project at its outset, as requirements are
being developed, a request for proposal written, bids from contractors sourced
and evaluated, and a winner chosen. The contractor, once hired, brings a team to
develop the software based on the RFP, and the staffing levels (counting both
internal and contracting staff) shoot up. There is a development period,
followed by a short period of “user acceptance testing,” and then the project
falls into “operations and maintenance,” (or O&M), which is generally a
different color of money than the development funds. (This is a huge problem
worthy of a separate discussion, but see here for a start.)



Contrast this with a typical “product” model, in which, instead of a
requirements gathering phase up front, a small team, often but not always
internal to government, conducts what are called discovery sprints to better
understand the problems the software is supposed to address. If some parts of
the proposed solution are riskier than others (for instance, it’s not clear
whether a data integration will work well), they find ways to test those
problems first, before an entire software solution has been built. They may
develop prototypes to help question their assumptions, and they engage with
users from the beginning. Product teams almost always leverage contractors, but
the contractors are there to complement a core internal team which holds the
product vision and provides clear direction to vendors. Staff is added slowly
over time as the team learns what they need, but doesn’t dramatically ramp down
once a first or even second version is shipped. As my colleague Dave Guarino
quips, “Google didn’t lay everyone off after they put up search.” Indeed, they
invested more.



At this timescale, there seems to be an obvious reason to prefer the project
model: the minimal ongoing expense. This is what appropriators and oversight
staff in Congress and elsewhere seem to be looking for as a sign of success. But
as anyone following government technology appropriations knows, this is not the
right timescale to look at. What happens next on the project line is one or more
of the following scenarios: the software doesn’t work well for its users, and
funds are sought to fix its defects; it quickly becomes outdated, either by
changes in the technical environment, the policy environment, or other external
factors, and funds are sought for modernization; or new needs have emerged that
the existing software doesn’t address…and funds are sought to meet those needs.
Thus, the actual project model line looks more like this in the medium term: 



And then in the longer term, as modernizations fail, needs escalate, and even
more money is allocated, like this:  



Here is where the slow and steady product line starts to look a lot more
attractive, on a purely cost basis.



But cost is far from the only reason to prefer it. Having a consistent team over
time may look like an unwanted ongoing expense, if we assume that development
work is at some point “done,” but that is not the case. (“Software is never
done” was one of the precepts of the Software Acquisition Practices report I
contributed to for the Defense Innovation Board). If software isn’t updated, it
rots in a variety of ways. O&M should be relabeled ROT. (Someone please
backronym that for us.)2

Leave a comment



The product model is not only less expensive in the long run, it results in
working software that doesn’t need “modernization” of the kind you’ve become
used to hearing about because it’s constantly being updated and improved. To
extend Dave’s quip, you don’t hear about Google pausing search for a
modernization. Google Search first came out in 1998, and I doubt its code base
today bears much relation to what existed then. But Search is a product, not a
project. It never went into O&M. It changed daily, not every other decade.

If you’ve worked in government you’ve seen Whong’s Law in action: “Every
government agency, everywhere is working on a “new system”; It will solve *all*
of their data problems and will be ready to use in 18-24 months.” The joke, of
course, is that it will always be ready in 18-24 months, and in the meantime,
because the new system will solve all problems, no improvements can be made.
Have a need? Find a workaround for the time being…which turns into effectively
forever. When I worked on unemployment insurance in California during the
pandemic, the team had been working on a procurement for a new system for eleven
years. The request for proposal hadn’t even gone out for bid yet, so the start
of development was at least a year away (probably a lot more), but the team had
been in this "find a workaround” state, in which problems get kicked down the
road (or more accurately, kicked into the requirements of a mega-project that
will take another decade to build) since the last modernization shipped. Of
course the UI system in California couldn’t scale to meet demand. It had been
rotting for decades.

In contrast, New Jersey’s unemployment insurance team was making improvements
every few days throughout and beyond the pandemic. The Department of Labor just
crowed about that state’s successful new system, a success built on “a
continuous approach to IT modernization over an all-or-nothing strategy.” Dave
Cole, New Jersey’s Chief Innovation Officer, said at the press conference: “Far
too often, other states, large and small, have spent hundreds of millions of
dollars to do one monolithic overhaul of their UI technology and applications,
only for the resulting experience to remain just as confusing, just as
frustrating, and just as demoralizing for claimants and state UI staff.” It’s
great to see a state escape that trap. More eyes should be on New Jersey.

Products also don’t wait to meet their users until they’re in a “testing phase”
at the end, when some of the engineers have already been moved to other projects
and the project’s budget is almost entirely spent. Understanding users — not
documenting requirements, as the two are different — is what that tiny initial
team is doing, and what the growing team does along the way.



The biggest difference between the project and product models is that the steady
investment over time delivers effective service to the American people. Periodic
investment in “projects” is how we get backlogs and confused and frustrated
constituents.

Share

A summary of the differences in these models is below3:



As much as it's tempting to hold agencies accountable for their addiction to the
project model, this is not something they can fix on their own. Congress would
need to enable ongoing funding streams (in addition to procurement changes
previously discussed) in order to see agencies develop in the product model.
Congress should work with OMB and agencies to change the laws, regulations,
processes, and practices that impede agencies from operating in the product
model.

***

That last sentence is a bit of a doozy, I admit. It’s the kind of thing one says
in the written version of Congressional testimony, as if it were something that
one could just do, or that anyone in Congress actually wanted to do. But it’s
our jobs to make it a priority for them, and as we do, we need to figure out
tactically how this will really work. I hope you’ll contribute to that plan.

In the meantime, here’s a link to the slides. Feel free to use them with credit,
but let me know if you do, and in what context, and how they are received.


Subscribe


1

My best shorthand for the difference here is that project management is the art
of getting things done. Product management is the art of deciding what to do.
(Thank you to Bennett Hillenbrand for that line.) (See Chapter 10 of Recoding
America for more.) But obviously, there’s a lot more to it.

2

Update: 20 mins in and we already have a winner here. April Harding suggests ROT
could stand for Recurring Obligations for Technology. I love it.

3

In the chart (which is an image from the slides because Substack doesn’t seem to
do columns), I list Byrne’s Law under the Product Model side. That’s from my
book Recoding America. This is Mike Byrne’s assertion that most government tech
projects could cost 10 percent of what they do and still provide 85 percent of
the functionality. This is not quite the same as the concept of a minimum viable
product (MVP), which would be far less than 85 percent of the functionality, but
in the same general direction.




SUBSCRIBE TO EATING POLICY

By Jennifer Pahlka · Launched 4 months ago

In business, culture eats strategy. In government, culture eats policy. Here
we'll talk about the problems of state capacity (government's ability to achieve
its policy goals) and how to fix them. From the author of Recoding America.


Subscribe


53 Likes
·
4 Restacks
53
Share this post

PROJECT VS PRODUCT FUNDING

www.eatingpolicy.com
Copy link

Facebook

Email

Note

Other
13
Share
13 Comments


Kevin Sutherland
Jun 4Liked by Jennifer Pahlka

I love this post! As someone who has been either planning and delivering large
system modernization projects for over 20 years, it really resonates!

Unfortunately, my experience is states are not equipped / able to shift to a
product funding model for many of the reasons so beautifully articulated in
Recoding America. To name a few:

1. State organizations are primarily functionally organized. I.e., IT is a
separate hierarchical structure from the business areas.

2. The current technology is like an archeological dig site with layers upon
layers of older, highly coupled, poorly understood technology making it
challenging to even identify a "product"

3. The accountability paradox is deeply ingrained in the culture and behaviors
of staff.

In my experience, the desire to move to a product model will fall short unless
these issues can be resolved. Interested in thoughts from the community on how
to address.

Expand full comment
Like (2)
Reply
Share

2 replies by Jennifer Pahlka and others

Dave Rooney
Embracing Agility
Jun 3Liked by Jennifer Pahlka

Great post! I worked on a team from 1992-1998 in the Canadian federal government
that used this model (fund the team, not projects). There were a few capital
investments over that time on new server hardware, for example, but the ongoing
operating costs were really just the costs of the team.

We did *great* work, at least according to the people who used the systems we
produced. We were responsive to their needs and could pivot quickly when there
was a change in the business. I wish more organizations today we like this one
was 25-30 years ago!

Expand full comment
Like (2)
Reply
Share

2 replies by Jennifer Pahlka and others

11 more comments...
Top
Latest
Discussions

Stop making people do the wrong jobs
Public servants are largely doing a great job — at the wrong jobs. What might a
second Biden term do about that?
Apr 28 • 
Jennifer Pahlka
44
Share this post

STOP MAKING PEOPLE DO THE WRONG JOBS

www.eatingpolicy.com
Copy link

Facebook

Email

Note

Other
23


Public input is not user research
OMB is right that we need new methods of engaging with the public that don't
allow for capture by special interests. Service design provides some…
May 17 • 
Jennifer Pahlka
37
Share this post

PUBLIC INPUT IS NOT USER RESEARCH

www.eatingpolicy.com
Copy link

Facebook

Email

Note

Other
9


Upset about FAFSA? Here's something you can do about it
How can 70,000 emails from students applying for aid fall through the cracks?
Mar 15 • 
Jennifer Pahlka
41
Share this post

UPSET ABOUT FAFSA? HERE'S SOMETHING YOU CAN DO ABOUT IT

www.eatingpolicy.com
Copy link

Facebook

Email

Note

Other
9

See all


Ready for more?


Subscribe


© 2024 Jennifer Pahlka
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great culture
Share
Copy link

Facebook

Email

Note

Other




CREATE YOUR PROFILE


Name (Required)HandleBio Subscribe to the newsletter


undefined subscriptions will be displayed on your profile (edit)

Skip for now

Save & Post Comment


ONLY PAID SUBSCRIBERS CAN COMMENT ON THIS POST

Subscribe
Already a paid subscriber? Sign in

CHECK YOUR EMAIL

For your security, we need to re-authenticate you.

Click the link we sent to , or click here to sign in.

This site requires JavaScript to run correctly. Please turn on JavaScript or
unblock scripts