Why budgets bust in tech projects

When things go wrong in software development Jack

Making time to plan out projects, so that it's not just forever ongoing. People are not actively using the database. Transitioning to a database. Excel doesn't seem manageable anymore. How to have happy clients and developers is still a bit of a mystery. Did project management pretty poorly; hard to stay within budget. Seen many projects hit predictable pitfalls.

Things to watch out for or how to do it right? Project managers know what needs to happen, when, who needs to do something. Someone needs to own the process, but that person can be different than the people doing the work that moves the project forward. On schedule, on budget, on function. If you try to add more features, it's going to cost more.

1. Projects come in late 2. Don't do what they are supposed do 3. All budgets bust Hard to estimate exactly what things are going to cost before you dig into the work. When you get quote, ask developers what does that quote mean, what's likely to change it?

Biggest anti-patterns: 1. Decision making process fails People we were talking to were really happy, but then their ED was not happy. ED clearly needed to be part of the decision making process. Stakeholders who needed to be involved at all times were not. Can also go in the oppposite side of the spectrum, where the entire staff is arguing about all the details down to the button colors. In your organization, figure out who the stakeholders are that need to be involved. So there aren't these surprises down the road. Choosing points of contact can be helpful. But the point of contact has to know who they need to get approval from before responding.

2. Everything is as important as everything else We list out all the features. Clients have to put a number of what to work on first. If we ran out of budget, what can drop off. If nothing can drop off, make sure you have unlimited resources. As they see the timeline, budget, invoices, etc. can compare it to this list and reprioritize along the way. When you try to do everything all at once, money gets spent all at once.

Back in the day, migrations weren't a thing. Now you have migration. When you get your content out of your current site and put it into your new site, the structure is not exactly the same. There have to be transformations. If you want an automated content migration, expect that to be a big line item. Can take a lot of trial and error.

Design and development disconnect. If you hire a designer who is not doing the develpment, make sure those people are talking. Make sure designers know how to design for the web. Design can cost different amounts and can imply functionality in their design.

Project slowdown. Organizations are super busy, doing amazing work, their mission is more important than their website. To meet their mission they have to put their breaks on the tech project. The longer you put the breaks on a project, the most expensive it gets to keep it going or pick it back up. Try to put the breaks on it in an orderly way. Ask the developers how we can take a break in the least damaging way.

--

Sarah

Often take clients who are very injured by past vendor relationships. We don't make any guarantees up front and don't give a quote. Try to engage people in two week chunks. Will have a discovery workshop to figure out who are the stakeholders. On day one, we have our kickoff meeting with developer and client. Write out stickynotes of all the features we want to build. You always have epics like "I want a blog." And break those bigger tasks into specific individual tasks. Developers make a rough estimate of how difficult something is. Come back and the client does the prioritization or ordering. Developers just start at the top and work down the list. Start delivering immediately. Goes through internal testing first. Client gets best value if they are actively testing. Keep moving tickets through this system. 15 minute check in each morning with the client. Demo at the end of the two week block. Retrospective at the end: what went well, what didn't go well. Bill every two weeks. You can take it or leave it. You can say, this is great, we're done here. Or you can start a new 2 weeks.

How do nonprofits feel about this? Works for some nonprofits. Nonprofit point person really has to own it. Clients feel a lot of ownership over. A lot of nonprofits won't start, though, if they can't get board approval for an estimate. We focus our estimates on the goals rather than features.

Ask clients not to hide your budget. Compare quotes from different vendors. Estimate based on their wishlist. Agile is about dealing with the tradeoffs in the moment. Phases and minimum viable products are also key strategies.