Help The Client Help You

Another way to maximize your effectiveness is helping the client help you. The first step is to understand the client’s needs. Throughout this book, the client is addressed as though he or she is a single individual, and to some extent that is true. The person who signs your check is your client, and at the end of the day, you want to deliver what that person hired you for. Employees in the trenches will probably have different ideas about what needs to happen than the hiring manager. Acknowledge these ideas and navigate these needs carefully, because of the political and technical knowledge of the employees. However, keep your eye on what you were explicitly contracted to do.

Remember, it is in the client’s interest to maximize your productivity. However, the client will not take initiative in helping you; they’re pretty busy, otherwise they wouldn’t have hired you. You can be a standout consultant if you look beyond ‘getting the work done’ and really think about the larger picture and the client’s business, including competitors, new technology and the cost of hiring you. Once you let them know about anything that affects your productivity, clients are almost always willing to help. Make sure you alert the client to anything that may be hindering you. This includes lack of access to people or systems, as well as lack of understanding of the business, project or systems.

In certain organizations, contractors may be brought in not to do work, but to empire build. Dan was in a certain large company who hired him via a consulting company, but didn’t really give him anything to do. If you’re a developer who likes building software, this is going to be a frustrating position, since your skills and motivation will be wasting away. Make your concerns known, politely but repeatedly, to both the client and other employees. If you are going through a consulting company, let them know too. Make every effort to fulfill the contract, but if things don’t seem to be getting better, leave.

Beyond keeping your eye on what you were hired for, another valuable thing is to watch for needs that a client doesn’t even know they have. For example, using an open source database to cut costs, or using version control. This is secondary to getting your job done, but you can plant seeds for more work and build trust. It also might save the client money, and save you from doing scutwork, like writing yet another O/R mapping layer.

Techniques To Help The Client Help You

Some specific actions you can take to help the client help you include asking questions, figuring things out yourself, enabling the best communication possible, and approaching problems from a non technical viewpoint.

It’s fine to ask questions throughout a contract, especially at the beginning. Though you were hired for your technical competency, no one expects you to come into an entirely new situation and immediately understand how all the pieces fit together. However, there are techniques that make it more likely your questions will be answered. As you explore the system, begin to jot down questions. Then, find out how the client would prefer to answer your questions, be it email, phone, instant messenger or face to face discussions. Also, find out who should answer or dispatch your questions–the right person may be different for each question, but a technical person as initial contact works best. When you have a significant batch of questions, or you’ve run into a show stopper, use the client’s preferred method to ask the questions. Also, make sure you are polite, patient and persistent. Very often, the person with the knowledge to answer your question is the busiest person. Be polite, and ask them when you can expect an answer. Note that time and if it comes and your question has not been answered, ping that person again. Exploring the system and figuring out things for yourself can be useful as well. Before you embark on this, discuss how long you should spend with the client–it can be a poor use of time for you to figure out something that someone else knows by heard. Exploration can and should be used concurrently with asking questions; when you’ve sent off that batch of questions, see if you can figure some of them out yourself (given the consent of the client).

Additionally, make sure that information is communicated well. Written documentation is best. If you are having trouble getting written requirements, offer to write them yourself. Here's a good article on how to write requirements; he calls them ‘functional specifications’. These documents don’t need to be formal; wikis have worked well for two of the authors. Point out the benefits for the clients: you will be able to head off and work more independently, rather than asking clarifying questions all the time. If you can’t get the client to agree to write requirements, you should still avoid verbal requirements, which lead to misunderstandings. Rather, rephrase what you think you heard the client say, and then write the requirements yourself. Share them with the client if appropriate. Again, no need for formality, a simple email or text note can be enough. Beyond requirements, writing down other information, or getting the client to do so, is a great way to ensure that you have it in the future. Whether you send emails to yourself, keep a developers notebook, or have a personal wiki, having information in a written form will save you grief when you forget it.

Developers have a tendency to approach issues from a technical standpoint, often focusing on how to solve problems via software. You’ll be more valuable if you can ask questions and think about problems from different points of view. Some other viewpoints to consider: user, management, deployment, designer and DBA. Doing this will put you in the client’s position, and lets you know what questions to ask to help the client help you. Using these points of view, try to diplomatically point out solutions. Sometimes a fresh set of eyes can see new or existing problems, but, other times, everyone at the company knows about those issues – there may be political, historical, technical or business reasons for not addressing them. Be diplomatic; the new guy who rails about how crappy everything is has often not given much thought to how things came to be that way. His opinion may be discounted in the future, even when he has valid points. An example of a diplomatic way to approach changing the build process would be: “I notice that our deployment process has a lot of manual steps. I’m sure there are good reasons we’re doing it that way, and I wonder if you can help me understand why.” Do your best to understand the situation first, then if there’s room for improvement or education after you’ve found out all you can, propose it.

One time Dan was at lunch with a possible client, who had a crufty old user training system that was humming along. It was getting harder to maintain, but there was limited business value in rewriting the entire system. One of the employees of the client almost fell off his seat when Dan stated that as long as the system still had business value, it should not be rewritten: ‘I’ve never heard a developer say that!’ Dan was offered the contract.

Conclusion

In general, contractors need to be aware that they have the onus for being productive. The client will benefit and appriciate their productivity, but the contractor needs to be proactive in pursuing whatever information and access he or she needs. Think about the work you’ve been hired to do in terms of the larger picture and from different points of view, as that will help you do so.