Consultancy and the Word "No"

I was enjoying the company of an ex-colleague, rail travel critic and long time friend Ben Baumguertel this morning on the 06:14 train into London this morning and the conversation roamed onto a topic that provoked strong professional reactions for both of us. Whilst discussing passed projects and clients we stumbled onto the topic of what actually makes a 'good' consultant as opposed to a green-horn consultant on their first client engagement and began telling each other of some parallels we had each encountered in our careers.  

The life of a consultant is often stressful, bouncing from industry to industry, each time being required to learn the political landscape, the stakeholders, the processes and procedures, governance, regulatory requirements, the list goes on and on. In each case however, one core principle seemed to be the same, in all client engagements, all industries, all projects, one simple core principle seems to be present. The ability to say 'No' in a constructive fashion.

We've all been there, you are sitting in a workshop, you've gauged the lay of the land and you are listening intently to both hear about the project as a whole and the particular component(s) you are responsible for when the dreaded line comes from nowhere "What we need to do is X". This instantly puts you in a bind, you need to be able to understand what has been said, think your way through X and apply as may use cases as the workshop has uncovered and also apply the benefit of experience to consider your response. Often you may have the luxury of stating something non-committal such as "let's take that off-line" or "I don't think we know enough to make that decision now" but, more often than not, the response in your head is like something off of lost in space "Danger Will Robinson, Danger".

It's at this point that the subtle skill of consultancy comes to the fore, the art of taking your time, I have learnt the hard way that shooting from the hip is a terrible idea in these situations. The idea has been made for valid reasons by a member of the team you will be working with for the foreseeable future, you simply cannot afford to sit there and simply state "No, that is not a good idea". It creates a perception of yourself as negative and blocking, you run the risk of alienating the team member who made the proposal and you are there to be constructive and helpful. You may be 100% right but the delivery is everything in situations like this.

I'm not going to be prescriptive in this as I don't actually know the answer and anyone that claims so it stretching the truth somewhat but what works for me is to share my relevant thought on the matter. Phases such as
"Will that work for all the use cases we have uncovered today?"
"I think that suggestion has merit but we need to fully explore that before we go too far down the path"
"That works for what we have but what happens when A, B or C occur? Will it handle them?"

Most of the time, my role has not been to dictate an entire solution to the customer but to work collaboratively with Business and IT to produce a solution that benefits all. Don't get me wrong, as the external consultant it's my job to spot things which will cause problems down the line and to provide the benefits of my experience to the project team as a whole and to make sure that the project will be a success but, in order to do this, you must learn the right way to say that simple two letter word that you've known from infancy

"No"

I Could Murder a Cuppa

During our annual meeting, we were set a relatively simple challenge, we divided into equal teams, and we were all set a simple process to document and present to the group. This sounded quite simple but it was very interesting to see different peoples' takes on the requirement.

Here is the exercise I'll be covering in this Blog. Making a cup of Tea:

1. Fetch the kettle
2. Open the lid on the kettle
3. Turn on the cold tap
4. Fill up the kettle to the max line
5. Turn off the cold tap
6. Put the lid back on the kettle
7. Put the kettle back on it's base
8. Plug the kettle in to the electrical socket
9. Turn the kettle on at the electrical socket
10. Switch the kettle on
11. Open the cupboard door
12. Get a mug
13. Put the mug on the worktop
14. Go back to the cupboard and get a tea bag
15. Put the tea bag in the mug
16. Wait for the kettle to finish boiling
17. Pick up the kettle
18. Pour water into the mug to the desired level
19. Leave for 3 minutes
20. Go to the drawer and get a spoon
21. Stir the tea and remove the teabag
22. Open the bin
23. Put the used teabag in the bin
24. Close the bin
25. Put the spoon down next to the mug
26. Go to the fridge and open it
27. Get the milk out
28. Open the milk
29. Add some milk to the mug with tea in it
30. Close the milk
31. Put the milk back in the fridge
32. Close the fridge
33. Pick up the spoon from next to the mug
34. Use the spoon to stir the tea
35. Drink

Now this simple 35 point process all comes from the simple requirement, make a cup of tea!

Now this is quitovee straightforward, any first year university student could have a reasonable stab at this with a high success rate but let's take it a step further. Let's say that you were meeting a customer for a discovery workshop and they passed you a requirement to make a cup of tea. You decompose it down into a series of managable tasks and race to the implementing of it but I've made a common and fatal mistake in the process list above. It's blindling obvious but has caused no end of problems in projects since the dawn of IT. I've potentially made some fatal assumptions: Do we have a kettle? Do we have Teabags? Does the customer want their tea without Sugar? The list goes on and on...

The point of this is that don't be in a rush to implement, think about the requirements,

• List all your assumptions, get them verified by the customer. 
• Think about your happy path and get this in place first
• Think about all your exception flows and hang them off the happy path flow
• Thnk about how you are going to test it?
• What are the pre-conditions?
• What are the post-conditions?

This is just as valid in Agile as it ever was with Waterfall approaches, admittedly in Agile you may proceed without knowing the full requirement but you should still attempt to flag the unknowns to be bottomed out later. Making sure that your requirements are fully thought out is the only sure fire way I've seen to prevent the 'ball of mud' coding pattern from becoming the predominent pattern on an implementation. An hour spent upfront clearing up your requirement and thinking your way through a problem will invariably prevent a throwing code at problems to make them go away.

This may be a very simplistic way of demostrating my point but it's a simple thing that if done incorrectly can have serious consequences? We could potentially have gotten to step 27 before we realised that we hadn't actually got any milk!



Finally, I suppose I should give the answer to my previous blog, this is quite simple once you start to dry run the principles in your head and you have ever got a divide by zero exception :). The answer is simply that the equations don't work as if X == Y then X-Y will always equal 0... Therefore, to divide by X - Y is to divide by 0 which cannot be done

Spotting a True Developer

I was thumbing through some old Maths homework set for me in my university days and I came across a practical joke that a lecturer set us that I think would be a marvellous addition to any technical interview when assessing would be developers.

The principle stems from a Mathematical fallacy which can be proven to the naked eye but, when you start to dig into it a developer should easily spot the anomoly as it can only be disproved by 'dry running' the concept in your head. Remember dry running you old school guys? A skill that has sadly seemed to have diminished as debuggers have gotten better and better. The good news is with SalesForce.com and it's Apex programming language the debugger is pretty basic and I personally am starting to see a slow resurgence of this lost, essential art!

On to the meat of this:

If we start with a basic principle X = Y it is safe to assume we can expand this as long as whatever we do to one side of the equation we do to the other side to keep it balanced so here we go.

1. Multiply both sides by X

    X^2 =X^2

2. Subtract Y^2

X^2- Y^2 = XY - Y^2

3. Now let's factor both sides and break it down into an easier to read format

(X - Y) (X + Y) = Y (X - Y)

4. Now we can divide both sides by X - Y to clean it up a bit

X + Y = Y

5. Now if we revisit our original principle that X = Y we can now express this as

Y + Y = Y or 2Y = Y

6. Now we simply divide by Y

2 = 1

And there you have it, we have now proven that 2 = 1 but can you spot the problem with this. I maintain my assertion that a true developer capable of dry running this will spot it in a few moments.


This is a common Maths 'joke' so have a go at it first before googling for the answer and I'll release the answer in my next blog but you shouldn't really need it as long as you maintain the basic principle X = Y

Until next time,

Chris