What did that chap just say?

Business and IT, two bodies working for the same company on the same project separated by a common language. How many times in your working life have you as a business user come out of a meeting or workshop and thought,

"What on Earth were those techy guys going on about? A workflow with a field update and an outbound call to a web service to integrate with the outlying systems via the middleware tier, I have no idea what that means"

You are not alone in this, many's the time I have left a workshop and had a developer ask what the business users meant by:

"We need a solution which will enable our back office staff to get all the information necessary for fulfilment without having to go back to the front office B2B reps to get extra detail."

Neither of these statements are complicated per se but, one of my jobs as a consultant is to make sure that when communications happen between technical resources and business users that they communicate in a common language and my role is interpreter.

Luckily this is not a difficult problem to overcome. All you need to do is invest a little time in the technical team prepping them. Here is a short list of what I like to do to better faciliate the conversation

1. Get a list of all the issues that the technical team need to discuss up front, find out what the developer needs to know to complete the work. This way, you will be having the conversation.
2. Coach/Mentor your technical team. Have a pre-meet with the team to make sure there are some simple ground rules laid down:
1. Under no circumstances should the developer talk about code or offer to show it
2. Business users do not want to hear about the details, Workflows, Classes, Triggers, Unit tests. None of these should be mentioned
3. Where appropriate, try and ask the question to your own consultants. It’s their job is to translate between Business and IT

Communications between Business and IT need not be a stressful ordeal. With a little preparation then it can become a productive and stress-free experience.

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"