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.
Involve the staff who use the tools in the development of the software (co-design), this creates buy-in, accountability, and a better user experience. At NJ office of innovation we do this as much as our agency partners can make time for. Currently along with USDR the UI team is working with appeals staff to design their own tools and they love it. By applying a service design process we look at the resident experience and the staff experience and design for the interaction.
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!
Oh, I should also note that the team consisted of full-time employees augmented by consultants (really, we were contract developers). The only RFPs what were issued were for the contractors and not the systems themselves.
Love this analysis. I've spent 95% of my professional life in the private sector, and have seen (and am fighting) the same addiction to projects - even when you're working in a product company that should know better.
Discovery sprints are one of the most important parts of the equation for me. Orgs that use them spend a tiny % of the total cost and manage to avoid enormous amounts of wasted effort - but the idea that you're investing time and money on something that might result in a "we shouldn't proceed with this" decision rubs a lot of people off the wrong way (sunk cost addicts!!)
Yes, and this makes me realize I need to do a better job explaining that discovery sprints don't necessarily lead to products. They are a way to learn how not to build the wrong thing. I think I'll do a separate post on this. Thank you for the great comment.
I've been getting more involved in budget and program discussions in my org and the project-modernization cycle is so accurate it's making me dizzy. I was already grateful that the origin of my project's funds was unusual for having a multi year ramp up structure, but I didn't consider that it may be a model or even the reason for why I have good support when other projects seem always trying to stave off annihilation.
Really interesting post. I hadn’t realized that government software products are often dysfunctional in this way but it makes a lot of sense when you describe it with these charts.
It’s really an error to think of software engineers as interchangeable building blocks, to assume that if feature x can be built by a team of y software engineers in z months, then any software engineers will do. A team with experience on a particular codebase can easily be 10x as productive as an equally expensive team of replacements brought in. Get rid of your productive teams and you can easily end up sinking many millions of dollars into projects that produce zero output because their expertise in this particular system cannot be replicated.
Since the software application resource loses its business value over time, it ROTs.
Especially in the context of outdated software. It conveys the idea that the software is disconnected from modern standards, practices, or updates, making it less effective to business.
This is great. The article overlaps a lot with what Mik Kersten has to say in his excellent book Project to Product.
What the author refers to as that moment post-launch of a project when one finds "the software doesn’t work well for its users, and funds are sought to fix its defects" is what Kersten refers to as the "watermelon phenomenon". Projects that are "green" on the outside (all on track) but "red" on the inside (falling way short of the promised value).
Kersten also describes the "project end fallacy", where cost centre accounting necessitates that the focus become the successful reduction of cost after the initial launch launch. This fallacy gives rise to costly, unintended consequences.
- Massive accumulation of tech debt
- proxy measures like timeframes trumping the actual delivery of value
- unsustainable staff resourcing where everyone is over capacity because the effort to maintain projects post-launch is hugely underestimated/underfunded.
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.
Involve the staff who use the tools in the development of the software (co-design), this creates buy-in, accountability, and a better user experience. At NJ office of innovation we do this as much as our agency partners can make time for. Currently along with USDR the UI team is working with appeals staff to design their own tools and they love it. By applying a service design process we look at the resident experience and the staff experience and design for the interaction.
I love what your team is doing! And the results speak for themselves.
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!
Oh, I should also note that the team consisted of full-time employees augmented by consultants (really, we were contract developers). The only RFPs what were issued were for the contractors and not the systems themselves.
We need more of that!
Love this analysis. I've spent 95% of my professional life in the private sector, and have seen (and am fighting) the same addiction to projects - even when you're working in a product company that should know better.
Discovery sprints are one of the most important parts of the equation for me. Orgs that use them spend a tiny % of the total cost and manage to avoid enormous amounts of wasted effort - but the idea that you're investing time and money on something that might result in a "we shouldn't proceed with this" decision rubs a lot of people off the wrong way (sunk cost addicts!!)
Yes, and this makes me realize I need to do a better job explaining that discovery sprints don't necessarily lead to products. They are a way to learn how not to build the wrong thing. I think I'll do a separate post on this. Thank you for the great comment.
Ridiculously Operate Technology!
I've been getting more involved in budget and program discussions in my org and the project-modernization cycle is so accurate it's making me dizzy. I was already grateful that the origin of my project's funds was unusual for having a multi year ramp up structure, but I didn't consider that it may be a model or even the reason for why I have good support when other projects seem always trying to stave off annihilation.
Investment Required Over Time (iROT)
Great article. Thanks for all your insights on Government IT. I’ve been thoroughly enjoying your book ‘Recoding America’.
Really interesting post. I hadn’t realized that government software products are often dysfunctional in this way but it makes a lot of sense when you describe it with these charts.
It’s really an error to think of software engineers as interchangeable building blocks, to assume that if feature x can be built by a team of y software engineers in z months, then any software engineers will do. A team with experience on a particular codebase can easily be 10x as productive as an equally expensive team of replacements brought in. Get rid of your productive teams and you can easily end up sinking many millions of dollars into projects that produce zero output because their expertise in this particular system cannot be replicated.
Retain Old Technology?
ROT - Resource Out of Touch
Since the software application resource loses its business value over time, it ROTs.
Especially in the context of outdated software. It conveys the idea that the software is disconnected from modern standards, practices, or updates, making it less effective to business.
This is great. The article overlaps a lot with what Mik Kersten has to say in his excellent book Project to Product.
What the author refers to as that moment post-launch of a project when one finds "the software doesn’t work well for its users, and funds are sought to fix its defects" is what Kersten refers to as the "watermelon phenomenon". Projects that are "green" on the outside (all on track) but "red" on the inside (falling way short of the promised value).
Kersten also describes the "project end fallacy", where cost centre accounting necessitates that the focus become the successful reduction of cost after the initial launch launch. This fallacy gives rise to costly, unintended consequences.
- Massive accumulation of tech debt
- proxy measures like timeframes trumping the actual delivery of value
- unsustainable staff resourcing where everyone is over capacity because the effort to maintain projects post-launch is hugely underestimated/underfunded.