Recently, inside of one month, several of our partners all asked us essentially the same question:
“Why do the web development projects we do in-house always go over budget? Can you help us figure that out?”
Short answer: we sure can. While every project is going to have its own circumstances, there are common threads throughout (1) the types of companies that struggle with getting dev projects done on-budget, and (2) the way the projects themselves are managed.
These partners of ours who asked this question, like a good number of the creative agencies and consulting firms we work with, have some development capability in-house. The capability is usually pretty limited, though, and development is not their core competency. They built their business on other strengths — marketing strategy, graphic design, creative thinking. Not development.
That, more than anything, is foundational to the three primary reasons projects go over budget when a company that doesn’t specialize in development tries to do development in-house:
1. Projects aren’t scoped right from the outset
One clear way of getting something done within the budget is…get the budget right in the first place! It’s incredibly important to ask the right questions in order to understand the customer’s needs, and to be able to foresee complications (and opportunity!) in their responses. Most customers can’t describe what they need in a way that is conducive to getting a good result from a development team.
So you need translators — people who can take customer needs and pry them apart, augment and enhance them so that the right solution can be created. This is the business analyst or solution architect.
You also need the experience of someone who has been through lots of development projects, and can assess appropriate budget for risks and unknowns — risks driven by things like third-party integrations, and how well-defined (or not) requirements are at the start. This is huge, and leads to our 2nd point…
2. The process isn’t designed to expect the unexpected
All too often, a project that requires development is managed in a way that isn’t designed to be flexible. The contract is rigid, the process is pure “waterfall”, and there aren’t appropriate expectations set about how to handle the unexpected.
To combat this, it’s important to:
- Build contingency into the budget to allow for things not foreseen at the beginning. If you budget purely on the known quantities at the start and expect those to be static, you will lose nearly every time. Much like a home renovation project, there are guidelines for how much contingency you should add in for known quantities. The degree of risk can be assessed by an experienced architect.
- Set expectations with the client that things are going to come up mid-project, and the team will need their input to arrive at the best solution. Be flexible; be willing to revisit decisions made during strategy or design when new information comes to light. Ignoring that new information and simply saying to a development team, “That’s the way it was designed, just do it,” pretty much guarantees you’ll blow the budget.
- Develop with an iterative process. Do small chunks of deliverable work, and review those with stakeholders every week or two (we do two week sprints at RocketBuild). All too often, organizations will do lots of design up front, then chuck it over to development and say, “Call me when it’s done.” That’s a recipe for disaster. At minimum you need to have internal review cycles, and if possible you should include the client in these sessions as well. These interim review points allow for adjustments and problem solving before anything gets too far off course.
3. They don’t have dev leadership
Any highly functional team needs leadership. When an organization doesn’t have development as a core competency, they often aren’t going to have a fully equipped team that includes senior leadership, whose purpose is to both enable developers and be their representative within the organization’s leadership.
What we often see instead is a company (that doesn’t really have development as part of their core purpose) will hire a developer or two to do the work, but not a leader who can mentor them, set policy, design/implement processes and best practices, establish performance metrics, and work with other leaders to ensure that other company processes are compatible so that developers can do their best work.
But that leader (and the other roles that make up a well-rounded dev team, like technical project managers, architects, and QA) can be very expensive to hire full-time. In the end, though, because of project budget overruns caused by an absence of those roles, it can be even more expensive to not have it.
It doesn’t have to be this way
The good news is, you can take steps to help ensure projects stay in-budget.
- Ensure technical risks are appropriately assessed and built into the budget.
- Design a flexible process to deal with unknowns and set expectations appropriately.
- Establish strong senior-level engineering leadership that can coordinate efforts with other departments and enhance developer efficiency.
If you’re not comfortable tackling any (or all) of those, we’d be glad to set up a free technical project review. We will work together to create a technical requirements document, cost estimate, and timeline. Everything your team needs to ensure your next project stays on budget.