waldo.jaquith.orgWaldo Jaquith – Open source, procurement, and gov tech.

Waldo Jaquith Open source, procurement, and gov tech. Home About Contact Speaking Back Org. chart chasms cause custom software project failures. Custom software projects fail at an extremely high rate in government, and that’s because of two core problems: the decision makers who set contractual requirements are far removed from users, and those decision makers are far removed from the software development team. These are really the same problem: decision makers are out of touch with key constituencies, which prevents them from grasping the underlying need and from understanding or controlling the work that’s being done. How does this happen? Under a traditional government contracting process, nobody ever talks to the users to find out what they want. That’s simply not a part of the process. Instead, a program office is aware of a need that they think is best addressed by software, which so they go to the procurement office to say they need to buy a thing. Nobody is in charge of saying wait, do you really need to buy that thing—how do you know?” If the program office has the budget, they generally get to make the decision to buy something. So the procurement office says you need to tell us your requirements, so that we can paste them into our RFP template. The program office then asks IT to come up with a list of requirements, plus they’ll toss in a few of their own. If they’re flush, they’ll pay a consultant to come up with the list of requirements. Whoever comes up with the requirements they do so by, basically, thinking real hard about it . Those requirements go in the RFP, which becomes part of the contract, and the vendor is on the hook to build software that does what’s required. Again, nobody ever talked to the users. Then it’s time to actually do the work. So the vendor assigns a team of developers to write code that meets the requirements, and they go away and spend months or years doing that, without the agency ever seeing or using that code until the very end of the project. The developers never get to talk to users, but they’re no fools—they are capable of seeing that the requirements that they’re building toward are Actually Bad, and that their employer has underbid and overpromised. But the developers don’t meet with agency leadership or even agency employees to communicate that. The vendor has a client relations person who gets updates from the team’s project manager, periodically meets with the agency’s project manager, and maybe talks to the contracting officer’s representative once a month. The result of this game of telephone is that the client agency has no real idea of how the work is going. Sure, they’re given quarterly stoplight charts that say everything’s going great, but it’s not—the developers know that this project is dead on arrival. And they tell their team lead that. And their team lead tells their project manager that the developers have concerns. And their project manager tells the agency’s project manager that there are some wrinkles but it’ll all be fine. And the agency’s project manager tells their change control board that everything is fine. And the change control board tells the CIO that everything is great, who tells the agency secretary that the project is on time and within budget. At every step of the way, people are lying to their superiors—this is known as strategic misrepresentation,” and is famously analyzed inUnderestimating Costs in Public Works Projects: Error or Lie? ” by Bent Flyvbjerg et al, which I recommend highly. (The paper answers the title’s question: lie. ) What’s to be done? The answer is, naturally, my hobbyhorse: pair user research with incremental delivery of software via Agile development practices. No project should receive funding without user research that validates the underlying problem and the proposed solution. Leadership needs to ask the right questions and require the right answers . Agencies need to use an Agile contract format with a time & materials contract type to allow for user-centered software development, incremental delivery, and to facilitate trivial termination of contracts when a vendor is not performing. Agency principals need to oversee the work , and their deputies need to oversee the work more rigorously still . In short: close up those gaps in the organizational chart that ignore user needs, and allow project statuses to be built atop layers of lies. If the users’ needs are understood, and the software is incrementally being delivered as it’s determined to solve user needs, that makes failure far less likely. Posted by Waldo Jaquith March 26, 2024 Posted in Government , Tech Tags: procurement Leave a comment on Org. chart chasms cause custom software project failures. Beyond the stoplight chart: How to perform Agile oversight at scale. Four years ago I co-wrote the federal government’s guide to budgeting and oversight of major software projects . In the intervening years, the advice contained in that document has been put into practice in a number of state legislature and governors’ offices, to the point where a new problem has appeared: How do you oversee software projects at scale? So you’ve left behind the fiction of stoplight charts. You’re getting demos instead of memos. Teams are ostensibly delivering software incrementally, based on constant user research. You have two, five, ten, thirty projects working in this way. But, oh no…you have thirty projects working in this way. Now your calendar is just demos of functioning software, all day, week after week. This is a great problem to have, but it’s a problem just the same. I have worked on solving this problem, and I’ve applied parts of a solution, but my solution is by no means a tested theory of change. But I think it’s important to work out loud, so what follows is the four-stage process that I recommend to anybody facing the problem of scaling up oversight of major software projects. (I wrote a bit about this last May, though targeted at agency heads, inHow an agency principal should oversee a major custom software project .” That’s meant for the actual head of an agency; this guide, on the other hand, is meant for their deputies, advisors, etc., for legislative staff in similar positions, and for state IT agencies and procurement shops.) Here are the four steps: 1. Get access to the backlog. 2. Require sprintly ship notices sent to leadership. 3. Engage with the ship notices. 4. Provide direct support. Let’s take each of these in turn. 1. Get Access to the Backlog Any Agile team practicing user-centered software development is going to maintain a backlog of user stories, in GitHub Issues, Jira, or a similar tool. (And if they are not, that is the biggest, reddest of red flags.) Tell the team that they need to provide you with access to that backlog, so that you can monitor their work. This is the single source of truth for any software project—without some serious deception, looking at this will reveal exactly how much work they’re getting done and how they are doing it. If the team is reluctant or claims technological obstacle, tell them that you’ll give them 30 days until you need access; they will use that time frantically getting their act together, like somebody tidying up their home before the house-cleaner arrives. When you have access to the backlog, periodically review it to get a sense of what they’re doing, why they’re doing, how it’s going, and the extent to which that’s rooted in user needs uncovered through one-on-one user research. Look at the software they’re developing to see those user stories realized in staging and production. It is important to fight the the urge to extract metrics from the backlog. You might think I can tally the story points completed per sprint to measure productivity,” or I can measure the time allocation per activity.” Down this path lies madness. A scrum team is a small, self-organizing, cross-functional group that incrementally builds software to...