Ross Hamilton, Director, Lab49
Joe Morrison, Managing Consultant, Lab49
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.
Being open-minded pays
Software can be built to behave exactly as specified. Or (much better), the
customer can engage the technical experts in discussing innovative ways of approaching
the business problem. For example, this could include opportunities to streamline
the business, leveraging the latest technologies to improve performance, or
building an architecture that is readily adaptable and supportive of the customer's
For example, a client recently asked Lab49 to build a batch-based system to
replace a legacy system, for pricing a large portfolio of bonds. The large computational
requirements for generating cashflows for the portfolio implied that only a
couple of sets of prices could be generated throughout each day. The Lab49 team
counter-proposed a system that modeled the portfolio of bonds on a more granular
basis such that cash flows could be computed on demand in response to real-time
inputs. This required less coding and could be delivered more quickly, allowed
more flexibility and configurability, and provided a better solution to the
customer's problem. This improved outcome was possible because the customer
was willing to discuss the underlying business problems with Lab49 and engage
in a dialog to identify the best solution.
Communicating at the right times
Issues, risks, dependencies and other impediments always surface during development,
may of which require the stakeholders urgent attention. The last thing they
want is for the development team to make important decisions around scope or
the relative priority of features. So, when the team raises issues in real-time,
the stakeholder must respond accordingly.
Specifying requirements is a tremendously difficult task. If the customer doesn't
describe what he wants in enough detail, developers may build the wrong thing.
But provide too much detail, and the developers may be pinned down and miss
major opportunities to speed delivery. The best compromise is to discuss short-term
requirements in a focused forum and stick to that plan for a complete development
cycle (typically 2-3 weeks). Don't change the requirements in mid-cycle or the
code will come out a mess! At the end of each development cycle the business
stakeholders should review the work to date and provide guidance. At this point
the requirements can be changed with minimal disruption.
Periodically throughout the project it is wise to pay attention to who is delivering
for you, and how frequently and consistently is it being delivered. Without
being intrusive, you and the project stakeholders need to let the developers
know you care about the project and value their work. Engineers, like everyone,
thrive on success and positive feedback. When you see the fruits of their labor,
you should acknowledge that. In return, the team will trust you more, and you
them, and that's the kind of relationship that maximizes productivity.
What versus how
All of this does not mean that you and the customer have a license to get involved
in all details of implementation. A balance needs to be struck between collaborating
with the engineering team and intruding in their space. If the engineers are
good, you should give them leeway to decide when to write test cases and refactor
their code, and you'll get the best possible product. If the engineers are bad,
don't micro-manage them. Get rid of them.
The formula for good change management
Putting this all together, the formula for running a successful software project
in a rapidly changing business environment is:
1. Establish lines of communication with the right business stakeholders and
2. Ensure software developers understand the business problem they are trying
3. Have stakeholders provide input to the development team at the end of each
development iteration to correct course, explore opportunities for optimization,
and build trust.
4. Ensure stakeholders are engaged and responsive to issues as they are raised.
5. The rest of the time, let the developers do their thing.