Whether you're commissioning a software development project or you're a software engineering team manager, you need your development team to be able to deliver what you need, when you need it, and to be able to respond efficiently whenever the project requirements change. But even with the best software development teams projects often go off the rails, coming in late or failing to meet requirements. Why does it sometimes seem like development teams just can't get the job done?

The problem is often lack of clarity about what "the job" is. The assigned analyst might authoritatively declare that a particular function is unimportant, then later on a more senior user might declare that feature to be a critical requirement. Or a requirement might be underspecified, and the programmer might find that the only person who can clarify matters is on vacation until past the project deadline. These problems can be avoided by making sure that the customer, i.e. whoever is driving the requirements and paying for the software, commits to a certain level of engagement throughout the project. Here are some guidelines.

Who's the real stakeholder?

Early in the project, it's important to clearly understand who the customer -- i.e., the key business stakeholder -- really is (or a proxy to the customer, such as an analyst). The customer has the decision-making authority to guide the software developers. Too often someone is chosen because they understand the business, are interested in technology, and have time to take on the role. But another senior user might have the authority to reject the system after delivery. It's important to work out who's who up front, and establish lines of communication with analysts and users who really understand what the software needs to do and have the authority to drive the project.

What's this thing for, anyway?

Businesses are continuously innovating and adapting, which usually implies requirements changing during a software project. Obviously engineering teams need to be able to respond to these changes. But engineers constantly make design decisions, which make certain kinds of changes easy and other kinds hard. They can respond to changing requirements much more efficiently if they have a basic understanding of the business they are writing software for. The customer should therefore engage the software team in conversation about the underlying business problems that they are trying to solve, proactively and continuously throughout the project. When the requirements change in mid-project, the engineering team will be ready.