Tuesday, August 19, 2008

Making your case

I am surprised at how often I've been on site with a customer and find out that the recommendations I end up making were actually already suggested by the DBAs and/or developers on staff. I wonder why the suggestions of the employees aren't heeded and a consultant gets called in instead? It would seem that the company could have more effectively used the money and time spent to have a consultant tell them the same thing their employees are already saying.

So, how does the staff DBA or developer get heard? It may not even be that what they have to say is set aside in lieu of a consultant's opinion. It may be a case where a DBA or developer suggests doing something that hasn't been done before and they can't get buy in from their managers and colleagues. Why?

It's an interesting issue. My experience has been that many times I will be able to make recommendations or solve problems that on site employees hadn't been able to work out for themselves either due to lack of experience or lack of time to devote to solving the problem. Fortunately, I don't think I've ever left behind recommendations that failed and cost the company I intended to help, but I can't even count the number of times that my recommendations mirrored those that one or more employees had already made.

So, how do you make your case? How do you get heard? Do you quit and contract back in as a consultant making 4 times more money? I've seen that very thing happen, haven't you? Do you offer to quit if your recommendation fails? Hardly.

I think there are a few things that can help anyone make a case for their suggestions/recommendations:

  • Outline the business case or situation in detail and note the business goal. Keep in mind that a business case is really a tool that looks at financial considerations. No matter what other elements may be viewed as relevant to the decision, if they can't be expressed in terms of their financial impact they'll have no influence on the results of your case.

  • Provide meaningful options to accomplish the task/project. If the question to be answered can only have a "yes" or "no" option, it's easy to point to the winner. However, when you need to ask "which way" something will be accomplished, it is important to provide the options to allow the reviewers to step back and review options that reflect the most relevant means of accomplishing the business' goals.

  • State the full costs of the task/project and any on-going support and of transition. This isn't just about the cost of doing the project, but costs of supporting it once it's over. Things like licensing costs, staffing costs and costs of ongoing problems the project didn't intend to fix (perhaps only postpone). The full cost isn't just the cost to do the project, but is the full cost to the business of making a specific decision.

  • Show both the good and bad impacts of change. It is possible that along with the positive consequences of the project, there may be some negative consequences as well. This could include positions needing re-defined, transition costs and ongoing process problems that the project won't resolve.

  • Ensure the benefits of your recommendations are attainable...and can be measured. Be able and prepared to show before and after comparisons.

  • Know what metrics play a role in the decision-making process (and how). There are a host of metrics (some concrete and some fuzzy) that are considered when any decision must be made. And many times there is no collectively agreed upon way of measuring them. The key is understanding what your audience is looking for in terms of metrics and what they are going to make a decision based on. You need to know what they're looking for, what thresholds are relevant to them, and how they are used to seeing these metrics presented and lay them out that way.

  • Tell a story. The bottom-line is that your case is made by answering two fundamental questions: "Should we do this?" and "Which way is most effective to accomplish it?" Write up your recommendations and plans as if you are telling a story that answers those questions. Establish the background, introduce the problem and define why it is important to solve the problem. If you don't solve the problem, what is the consequence? What are the various way sthat you could solve the problem, and what will happen to the organization in each instance? And based on all of that, what is the conclusion your want your audience to draw and the action you recommend taking? Make sure you tell the story first, and then fit it into the template of your case.

  • Everyone can learn to make a case strongly and effectively. You can make a case that is polished and persuasive. In time, results will back up your proposals and consultants can be used as they should be and not just to confirm what full-time employees already know.


    Narendra said...


    I agree with some of the points that you have mentioned. I guess, one of the main reasons behind management not listening to their staff, is the staff (DBA / Developer etc.) may not always be able to communicate the full picture to the management. If staff keeps talking technical language or something similar, which does not clearly communicate what management / business needs, staff might get ignored. BUT...
    Unfortunately, I have seen plenty of times, that "Who" says it is much more important than "What" is said. Management alomst always tend to weigh the communication, based on the person's role / position in the company. A suggestion made by a staff member (who earns, say, £100 a day) is deemed "less valuable" than the exact same suggestion made by a consultant (who earns, say, £500 a day).
    And then the (in)famous politics also plays an impotant role. Somebody in management, usually, had taken a decision to hire a consultant. And that "somebody" will get in trouble if people discover that company has ended up paying 4-times more money to the consultant, to solve a problem, which their staff could anyway have solved it.
    That also reminds me of one more reason. Sometimes companies just want to hire consultants to tell them that "2+2=4", because they can justify the inflated project costs and bill customer accordingly.
    I must say your post struck a cord and I could easily find myself related to it. (Now you know who I am...a cribbing staff member...hahaha)

    robert said...

    Narenda, I couldn't agree more: the very same thoughts crossed my mind and I believe that in the majority of cases this is the real reason - not that the employee did not make her case properly. It is strange: management know their own folks, their strengths and weaknesses, but if you get someone sent from another company with the label "XYZ expert" attached that guy is seen as flawless - certainly much more competent that those "locals".

    Another pattern I have seen frequently: own personnel is not allowed to investigate a certain issue that they announce to become a major showstopper. Then, it does become a showstopper and now, all in a hurry, management calls in an external expert, who - of course - gets all the resources to investigate. And of course he also gets all the credits, and sometimes this is used as confirmation that "our own people couldn't do it".

    Unknown said...

    I certainly agree with your thoughts. In some situations and companies there is another reason I’d like to share: By the time the screams of the end users have reached the level of management where money can be allocated to solve a performance problem safety is paramount. Management deems it safer to do nothing and not allow anyone to do anything than to attempt a fix. By bringing in an expert even if the fix does not work management can blame it on an outside entity. Certainly it is not management's fault if the ‘best’ is brought in. I think it goes back to a saying I once heard: “You never get fired by bringing in IBM”.