Time and budget overruns are so common in software development that they’ve become de facto standard operating procedures. A full two-thirds of enterprise IT projects run over budget by as much as 100 percent. Only a quarter manage to reach release within 25 percent of their original budget. Developers are constantly on the lookout for clever ways to keep their projects in line.
There’s an old joke that the three most important factors when buying real estate are location, location, location. That joke could be rewritten for software development with “communication, communication, communication” as the punchline. Change happens, and only by forging and maintaining two-way communication with clients can developers hit the ground running when it does.
What does that look like in practice? Here are some best practices for incorporating communication at all stages of software development.
Conduct a thorough discovery process before creating a budget
Discovery is the first line of defense against budget overruns. This is one of those areas where developers nod agreement and scroll past, but somehow, it’s still a major problem. The issue is that what many developers consider an acceptable discovery often leaves gaping holes in the knowledge required to create a realistic budget. Assumptions can be made about a client’s requirements that set the stage for major course alterations down the road.
The foundations of client-developer communication over the course of a software project is laid during discovery. Now is the time to encourage constructive feedback and questions about the development process as a whole. Extra effort here has a disproportionately large effect on final outcomes. Research presented at the 6th International Conference on Software Process and Product Measurement showed that spending more time on external planning in the discovery phase was the single most influential factor affecting a project’s success.
Developers are usually given semistructured business requirements at the first planning meeting. The client has a big picture idea of what is needed with some explicit requirements regarding important features. Some even have specific technology they want included in their stack.
The more detailed clients are, the more tempting it is for developers to skimp on discovery. They mistake a client’s firm vision for a higher level of technical understanding and fail to ask the right follow-up questions to properly define requirements.
The simple truth is, developers will run into trouble without interviewing representatives of all project stakeholders during discovery. Most change requests come from an incomplete initial understanding of what is needed. The best person to clarify what a specific stakeholder category wants is someone from that category. Without this step, developers can unknowingly waste time on a prototype that doesn’t have the necessary features or creates undue complexity.
Communication help catch mistakes like this before moving forward. Ensure all stakeholder representatives are included when wireframes and mockups are presented. Ask for input at every level of use and be open to constructive criticism.
Construct and use a time- and resource-based cost metric to aid in decision-making
Good communication means everyone is speaking the same language. Dollar and time amounts may seem arbitrary to clients who don’t have a clear frame of reference for judging development processes. This can be avoided by using a building-block metric to use when discussing options with the client. It’s also helpful for managing time and doing quality control.
To create the cost metric, developers first need to get assemble a granular view of costs. Consider what it costs to operate a set configuration of the team for a set period of time. Setting that time period at a week is helpful for companies using variable sprint lengths. Those with fixed sprint lengths can calculate their metric using that.
For operating costs, include everything it costs to run that team. Operating costs should encompass full compensation for team members, equipment, testing, regulatory fees, and any other peripheral costs. Leaving anything relevant out of this calculation invalidates the whole process, so be comprehensive.
Once the metric is established it can be used as a stable point of reference for relative costs. Negotiations about scope will be more productive with clients and developers on the same page.
Stay flexible with a change management phase
Change shouldn’t be a dirty word in software development. It happens for all kinds of reasons: user feedback, new management, changing legal or regulatory guidelines, or even market shifts that change a client’s focus. Instituting smaller changes as needed reduces the likelihood of needing bigger ones later on. That’s why it’s critical to give clients freedom to ask questions and suggest adjustments as the project evolves.
Having a change management process in place is common sense, but some developers forget to make this process completely transparent. Too often clients are simply given a point of contact for change requests with directions to call if they have any questions. The developer may be trying to be open to feedback, but in reality, the client may not have a clear frame of reference for how simple or disruptive their suggestion would be.
Discovery should be the first (though not the last) time the change management process is discussed. Get into the details here: Clients have to know exactly who can approve changes, when suggestions will be open, how soon changes could be implemented, and what the impact on development would be.
Aim for an informed change management process. “Informed” means the client is presented with current project statistics along with the projected adjustments required for the change request when the change is suggested. Use the resource-cost metric for clarity when explaining the impact on investment and time. Give clients the information they need to understand their request and listen to their response. With good communication there may be a middle ground solution that has a more manageable impact on the project budget.
Review the budget periodically
It’s easier to fix a small budget overrun before it snowballs. For nontechnical projects, the proportional budget overrun at the 30 percent checkpoint will usually be the same as after completion, but software development is harder to predict. Without careful planning a small error can drain the budget before reaching an MVP.
Calculate how much of the budget should be allocated to each sprint, then break that down by week and check in after every sprint. Evaluate whether the time estimates for each user story were realistic, making adjustments based on actual hours spent if need be. If there was a setback, consider how it will affect the overall timeline.
Keep clients in the loop here, as well. Don’t be afraid to suggest moving features to a later release to finish the MVP on time. The vast majority of clients would rather have a reliable, solid product to use while advanced features are under development than wait while schedule overruns are resolved. Open dialog also helps determine which features should be moved and which are essential.
Communication, communication, communication
Foster a relationship where clients feel comfortable bringing up ideas and sharing concerns. Find problems as soon as possible, and welcome feedback on how to solve them. Provide several channels for communication (email, post-sprint assessment meetings, Basecamp).
Push communication at every level—because the real secret to keeping software projects on budget is to not keep secrets.