Untitled Document
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.
1
Print this article
Email this article
Talk Back!
Write to Editor
