Understand the business
Adapt to your client’s process and culture
Despite what you may read, there is more than one right way to build software. Every client you work with will have a different process and a different culture. Often clients will bring in consultants to improve their software as well as their process, but many already have a process that works (well enough) for them. What if your client doesn’t use the Agile methodology and there isn’t a critical mass in the company to transition? Guess what? It’s not your client’s job to subscribe to your way of getting things done. You should always promote process improvements, but don’t let your preferences get in the way of solving the discrete problem you were hired to solve. Remember which problem you are tasked to solve.
Work within your stakeholder’s constraints
A long time ago, in a galaxy far away, I consulted for a company that is wholly owned by a parent company. The parent company insisted we use servers in their data center, which were literally 10 years old. The server constraint impacted every aspect of the software my team wrote, even down to the version of the .NET framework we could use. If the parent company allowed us to spin up a cloud service on Azure (or just a dedicated server on any random host), they would have saved tens to hundreds of thousands in long term costs. Unfortunately this was beyond my stakeholder’s control, and therefore beyond my control. If I had been a staff employee in this situation and I couldn’t fix the issue, I would quit. As a consultant, after ensuring the constraint was beyond my client’s control, I just added “build software as if it were 2004” to the list of non-functional requirements. This is an extreme case and a wholly artificial constraint, and frankly, I wouldn’t work with that company again. But what about the case of a healthcare company that is constrained by regulatory compliance on storing data in the cloud? Your client’s constraints are simply an extension of your requirements.
Take ownership of the project
Treat every project as if it’s your own. Even if your role is developer or architect, think about the big picture. What are the risks to the project? What will it take to succeed? Is there enough budget? Resources? Is there an issue with the CI build? Fix it (or work with Dev Ops to make it happen). Recognize the difference between accepting fault and taking responsibility. When a problem arises, the first step is not to determine who’s fault it is, but how to resolve the issue. Taking ownership builds camaraderie and instills respect from project stakeholders.
Whether you are working on a sweet new rich UI, helping the business flesh out requirements, or even developing a testing strategy: provide alternatives. If you give the stakeholder one choice, they may not think about other options until you’ve already implemented your proposal. Multiple choice up front will result in a more involved stakeholder which will in turn result in a solution that better matches their needs.
The best technical solution isn’t always the best solution
Usually the best technical solution is also the best business solution. Usually. It’s always your job to evangelize the best technical solution. What if your client is heavily vested in nHibernate (in terms of internal knowledge, shared libraries across projects, cross team resources etc.) but you objectively know Entity Framework is the superior ORM? Sit down, take a deep breath, and recognize that the best business solution always trumps the best technical solution.
Respond to feedback
Respond appropriately to feedback. If your various clients are consistently upset about your crummy delivery estimates, do everything possible to become better at estimation. Show them you are improving. Thank them for the feedback. Read Software Estimation Demystified. Estimate your personal projects. Work with a consultant who is good at estimating. Get better. That’s how you deal with legitimate feedback. On the other hand, you’ll sometimes have a client who tries to leverage the smallest imperfections into free work. You can usually spot these clients during the discovery phase before the project ever starts. Avoid these clients or build their BS into the price.
Wind down a project with grace
When you transition off a project, the client should know exactly where they stand. They should know how to maintain the software, how to extend it, and any limitations. Getting a call back in the short term because your software exploded is not how to gain repeat business. It’s your job to ensure the client has everything required for continued success.
It’s common knowledge that as a consultant, you are the authority on software development. Right? It is entirely true that you should be confident in the domain of your expertise. More important than being confident is being honest about the domain of your expertise. No one is an expert at everything and that’s OK. Side note: develop a network of consultants who you can lean on for those areas outside of your expertise.
Be a partner
Repeat business is the lifeblood of any consultancy. You earn repeat business through honest, open communication and delivering as promised. Turn the client/vendor relationship into a partnership by making yourself an invaluable thought leader and team member.