How to Be a Good IT Customer

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.

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 ever-changing needs.

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.

Building trust

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 analysts.
2. Ensure software developers understand the business problem they are trying to solve.
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.