Win-win consulting
Ideas on how to survive unpleasant projects as a consultant
Mark Dominus has written a fine post about the most unpleasant experience as a consultant. This generated a discussion on HN in which I participated. Many fellow HNers encouraged me to write my comment in that discussion as a blog post. So, here it goes.
In any organization as a prospective customer, there are three forces at work that matter to a consultant: users, decision makers and finance folks. Ideally, the decision makers appoint a dedicated person (or team) who mediates users and finance guys to create a coherent road map for the system to be built. What tends to happen in practice is a combination of chance, human errors and conflicts in priorities.
To survive, we must understand ourselves as consultants, the terrain and the opposing forces (anything that prevents money getting deposited in the bank).
Consulting is a business => the individual consultant must shoulder quite a lot on himself:
* Advertising himself
* Finding work
* Meeting prospective customers
* Writing proposals
* Closing the deal
* Writing a contract
* Defining the scope of work
* Nailing what is to be done and what is to be avoided
* Constructing components of software
* (In worst cases) baby-sitting customer’s devs / ops
* Testing his modules
* Getting money in his account
So, when we talk with customers, there is inherent pressure in closing the deal versus precisely defining everything. Icing on the cake: back of the mind, you might worry about milkman’s bills and the birthday gifts to be brought for your kid’s friends. Always have a good runway: six months seems optimum. Technically, even three months should suffice, but it is insufficient for the edge case when these three things hold true simultaneously:
* You’ve to walk away from a customer in the middle of a project, and
* Dry sales pipeline, and
* Unexpected crisis at the personal front: very close friend in need of money for surgery etc.
God be with you.
Now, back to the main track. The key is to first understand the priorities of stakeholders. The contradictions are easier to grasp once we put ourselves in the individual’s shoes:
* [Convenience] The users want everything including the kitchen sink,
* [Accountability for the risk] They want it yesterday but won’t commit to it on paper since you’re in early sales stage,
* [Cost] The finance folks want stability and the most economical price,
* [Availability] The decision maker prefers to spend the least of her time to be spent on this activity, except when it’s her pet project.
These roles may be played by different people or the same person.
Again, we don’t have to agree, but acknowledge that things are meant to be imperfect. Most people are actually decent and rational. Now, somehow, the consultant must figure out a good path. To begin, he should have a good handle on:
* The industry in which the customer operates, e.g. BFSI, Energy, online marketplaces, food, fashion etc.
* The nature of the market: oligopoly, crowded, emerging et al.
* The level of Govt. regulation: HIPAA? PCI?
* The customer’s position: among top tier, mid-size, small firms.
* Customer’s customers: helps to track the wind.
* Standard pain areas in the market.
* How customer’s competition and partners survive the pain, specifically the differences among the customer’s approach and the competitor’s ones.
* The financial health of the customer: if possible, try to talk with their existing suppliers in other arenas (e.g. the guy who supplies printer cartridges, the cleaning lady etc.).
Based on that, assuming we’ve landed a hot lead, say that we want to convert it to money. There will be a lot of conversations over the phone, e-mail, chats, face to face; what is to be left out of those conversations is really context sensitive. The important parts are:
* What problem we’re going to solve for all stakeholders?
* How we’re going to solve it?
* Communicating our approach and progress on a timely basis.
* Improving Vulcan skills: like money, expression of anger is a great servant but a terrible master.
I leave out the details on the development process, since it depends on the individual.
Here are a few things which worked for me marvellously in certain contexts and doomed in others:
* Setting expectations by explaining the cone of uncertainty in the estimation process. Always be prepared for some customers, who deliberately mislead you that they don’t understand the mumbo-jumbo, projecting ignorance as a shield so that they can ruin you on payments. Mostly you should refuse such customers, unless you’re in an extreme crisis on multiple fronts.
* Writing use cases for the modules / systems I was supposed to work. Most customers say that they don’t want any time spent on “documentation,” to which I reply that writing a document is not “typing” but “nailing the thoughts to deliver higher quality work.”
* Creating mock ups using sketching tools (even Excel/LibreOffice can be good enough, if one is pressed too much for time) in the absence of UX designers on the team.
* Writing test cases before writing my code. Helps to ease the integration.
* Optimizing lazily: progressively refining the artefact (document / mock up / test / code).
* Knowing the expected value of each task: (amount of money * satisfaction * improvement in reputation) / (e-mail tennis * stakeholder’s understanding of requirements * payment latency * time spent)
Finally, reducing it to just one sentence: be nice, believe in yourself and humanity, be multi-dimensional and please heed Guy Kawasaki’s advice about reading voraciously and omnivorously.
