Wednesday, July 30, 2014

Using S.M.A.R.T Goals to Add Value Every Day

In an earlier post, I discussed the importance of not just working hard but adding value. The lesson of the roofing contractor mistaking hard work with value and assuming he earned the right to his fee simply because he worked hard is one with revisiting. As I mentioned in that post, work every day to ensure you are adding value to yourself, your firm, and your customers. Otherwise, you will fall short of your goals and have a hard time extending your relationships with your customers over time.

So how do you do that? In my experience, a good place to start is to set measurable goals for the initiatives on your plate. As a consultant, it is your job to ensure you know what the goals are for “this” project. It is also my experience, though, that many people struggle to set truly measurable goals that meet the need and deliver value. You need to develop your goal setting skills so that you can drive that discussion and assist your clients in defining measurable goals you can all get behind.

So what is a measurable goal? Personally, I like the S.M.A.R.T model for goal definition:

S = Specific
M = Measurable
A = Achievable
R = Realistic
T = Timely

If you do a Google Search for the term “SMART Goals”, you will see that there are approximately 35 million items returned in the search results. So I suspect I am not alone in my preference to use the S.M.A.R.T. Goals model.

So what does this mean? Well, the worst example if a goal I have seen lately was a goal that a Sales Rep defined with a client. The client was working to build an application security program, and we were working with individual contributors and managers who knew the importance of application security. They needed executive support to truly build and evolve a program, though, since doing so required access to human and capital resources.

The goal that was presented to me in my first meeting with this client was “CIO Awareness.” That’s it...nothing more. In reaction to this, I somewhat apologetically asked, “How do I know when I am done?” The folks in the room, including the Sales Rep who worked with the client to define the goal, all just sat there staring blankly at me. So I cut to the chase. “Guys, with all due respect,” I said, “this isn’t a goal, its a theme. I agree that making your executives aware is important for the success of the program, but aware of what?  How will we do that, and by when. Really, how do we know we have successfully informed the CIO of what we need to inform him to drive the desired results of getting more headcount and budget for the program? Also, how do we know how much headcount and budget we need so that we can make the right business case to the CIO. This goal needs work.”

Fortunately for me, everyone in the room agreed, and we set out to craft truly S.M.A.R.T. goals.

So what does a S.M.A.R.T. goal look like? In the example above, do you think that “CIO Awareness” is specific? Measurable? Achievable? Realistic? Timely? I think not. What if the goal was something like this:

“Deliver Quarterly Business Reviews (QBRs) to our CIO starting next quarter in which we focus on educating the CIO on the outcomes of the current program in terms of risk identified through scanning our applications, risk reduction through educating the development teams, and remaining risk to be addressed. Provide estimates of headcount and budget to further reduce risk to meet with corporate Application Security Policy, and gain approval of additional headcount and budget spending by the end of the year.”

In this example, we have clearly indicated what information we need to share with the CIO to make him aware of the current program, risk inherent in the corporation, and what is needed to reduce risk to an acceptable level. We have specified the forum in which we will communicate this information, and we have also defined the specific outcome (gaining approval for more headcount and funding) that we are striving to achieve and a timeline (by the end of the year) in which we must achieve the approval.

I think we have covered S-Specific, M-Measurable, and T-Timely.

What about A-Achievable and R-Realistic? Well, that is up to the team defining the goal to determine. One approach to assessing whether the goal is achievable is to brainstorm on all the things that could go wrong that would affect your ability to achieve the goal. Then assess the likelihood of those things happening. For instance, you may realize that the CIO is known for not showing up for meetings called by his subordinates' subordinates. So, can you increase the chances of the CIO showing up by having your boss set up and attend the meetings? Is there a better forum other than a meeting to communicate what is needed and get his feedback? Can his assistant help ensure he shows up? What can you do to ensure the goal is achievable?

Likewise, look that the time component - is it realistic to gain the CIOs approval for additional headcount and budget by the end of the year, or is more time needed? How many QBRs will you hold with the CIO before the end of the year? Will you have collected enough data to present a sound business case in that timeframe? Will you have enough touch points with the CIO to make your case effectively? When are budgets approved - what are the chances you have missed your opportunity if you wait until that end of the year? It may very well be that the goal is achievable but not realistic in the time you have given yourself...so be realistic about what you can really do.

Setting S.M.A.R.T. goals and developing a plan to achieve the goal allows you to evaluate each day if you have taken steps that bring you closer to achieving the goals that deliver the value necessary. You can take this step with your customers (as described above), with your manager (setting a goal around a promotion and knowing what you need to do to get there), and with yourself (developing a new skill, finding work/life balance, losing weight, etc.)

Focus on developing goal setting skills and significantly increase your ability to deliver value.

Wednesday, May 14, 2014

Top Consulting Skills: Ability to Understand, in Detail, the Current State


Things are not always what they seem, and the best consultants assume that many things are not at all as they seem. The current state is often a matter of perception. To complicate things further, each stakeholder often has a completely different perception from one another.

Often times, a consultant is brought on board by a senior manager or executive who has determined that there is a challenge that needs to be addressed that can’t be addressed internally. The business may lack the time, the expertise, or both, to solve the issue. So here you are.

The first thing most consultants will do is to speak with the executive to understand why they were brought on board. What is the problem from the executive’s perspective? What has she done to try to address the problem? What has work? Has not worked? Why?

While the executive may be a wealth of information and she will often speak with authority on the problem, simply listening to the executive and then driving to a solution would be a mistake. In all relationships, somewhere between “my truth” and “your truth” is “the truth.” This means that the consultant needs to talk to many stakeholders to get different perspectives. He must learn where there is alignment and misalignment. Where is there agreement and disagreement?

So, first, the consultant must find out who the most affected stakeholders are and talk to each of them in detail. As he speaks with each stakeholder, he should ask “who else will be affected by whatever decision we make on this matter?” The answer will present an additional list of stakeholders with whom the consultant should speak. In other words, don’t get a list of interview candidates from your sponsor, meet them, and call it a day. Look for additional perceptions that may be critical to formulating the right assessment of the current state.

The consultant needs to learn from multiple stakeholders at different levels in the organization:

  1. What are the motivations of each stakeholder? How do those motivations shape the stakeholder’s point of view?
  2. What is believed to be the problem? How is each affected by the problem?
  3. What symptoms are presenting themselves in support of the problem statement?
  4. What have they tried to solve the problem? What has worked? Not worked?

Individuals can be motivated in a lot of different ways. Some will be motivated by a successful outcome - finding the best way to resolve the issue and drive forward successfully. Others are motivated by fear. “If I talk to these guys, will I loose my job or sense of autonomy or ownership of the solution?” Knowing how one is motivated allows you to frame questions in a way that allows the stakeholder to be the most receptive and to apply judgement to the information you are gathering.

Additionally, many of us will often confuse the symptom with the problem. Is the problem that we have too many meetings making it hard to get work done, or is the crazy meeting schedule a symptom of some other problem, such as a lack of clear direction, lack of clear decision making ground rules, or lack of sufficient resources.

Getting to the heart of the current state is a critical first step in the consultative process. Do not get consumed with solving the problem at this point. Just stay focused on understanding what’s going on. You will get to problem resolution later.

Wednesday, May 7, 2014

Consultants ARE sales people

While I did work in a stand-alone, boutique consulting firm for a time, most of my career has been in embedded services organizations within software companies. In these organizations, the companies typically have a dedicated, product sales team who is also expected and compensated to sell professional services (PS). The Services Practice Manager and some senior consultants often support the Product Salesperson to sell PS. Let’s face it, selling product and selling services are different, even for a “consultative” salesperson. Products have features and functionality that can be more easily compared to competitive solutions. Products can be demonstrated, they can be touched, and the value can be illustrated visually in the sale process. OK, its not quite that simple, but the fact is, when you buy PS, you are buying access to people. You can’t illustrate the value of PS by demoing a person. Or can you?

I believe that while consultants are not salespeople in the traditional manner - they don’t carry a bag and are not paid on a commission basis, they are salespeople. (I am not speaking about partners in stand-alone consulting practices, by the way.) The way we sell as consultants is through being a solid consultant and demonstrating what we know and our approach to the consultative process..

Whether its in a pre-sales capacity, supporting the product sales team, or in post-sales delivery, consultants need to sell the prospect or customer on the fact that she knows the space and has the expertise needed by the customer to meet their needs and objectives. One way we do this is by joining the product sales team in pre-sales meetings to understand the customer’s pain, learn about their success criteria, and start discussing a model that can be used to ease that customer’s pain and drive to full attainment of their success criteria. We build credibility during pre-sales that should drive the deal and set up a successful engagement. What we do in pre-sales is very similar to what we do in post sales: We ask insightful questions, listening (a lot), and provide some amount of consulting throughout the conversations, giving the customer a strong impression that we can help.

We, essentially, provide a demonstration of our model and approach as well as highlighting the specific skills of our consultants through this process. The customer is most likely speaking to multiple organizations and will determine which consulting team is best equipped to help them meet their objectives through their people, process, and technology.

Inevitably, potential customers do not view the consultant who sells as a salesperson. This works to our favor, of course. For right or wrong, there are often negative connotations of “salespeople” and, even though the consultant is on the call to help scope and close a deal, we are viewed as subject matter experts, not salespeople. If we play our cards right, we will foster a strong, trusting relationship with the the customer, and the customer will be willing to share concerns, pain, and needs with us in a way they won’t with someone in a traditional selling role.

“Selling” doesn’t end when the ink is dry on the contract, though. Once we start a project, we will get introduced to new stakeholders - folks who were not part of the pre-sales process, who don’t know us. We need to convince them that we can do the job, that we can help them meet their objectives - we are back to "selling." Then the consulting begins. Throughout the engagement, we learn, we listen, and we advise. In the words of Peter Block, we “help our customers ask and answer their own questions,” and we show the customer a vision for a better and less painful future. Throughout the engagement you will, at a minimum, be selling your ideas and your vision for their future.

As a consultant becomes more senior, she is expected to help drive follow-on PS and product sales. Again, we are not “the” salesperson, but we are trusted advisors who work with our customers more closely than a salesperson ever really could. We have the ability to not only ensure “this pain” is addressed, we have the ability to learn about other pain the customer has that “we are able to address” through our products or services.

A colleague of mine, who once worked for a Big 4 consultancy, shared with me that his previous firm offered a training program they called something like, “Helping Your Customers Buy.” Notice that the word “sell” is no where in the title of this class. This is because, for many consultants, being perceived as a salesperson is seen as a negative. The message of this training, though, is that if you knew your customer has pain that you can address, why would you not talk with them about that, even if it means they have to sign another Product Order Form or Statement of Work?

Think about it, when you are not feeling well, and you go to see your doctor, the doctor works to diagnose the source of the pain you are feeling. If he identifies another health issue while investigating the pain you had when you came in, he doesn’t refrain from saying something simply because the new issue is not the pain you came in to discuss and/or because it could cost more money to get the health issue resolved. Rather your doctor speaks with you about what he found, the concern and/or risk, and what next steps he recommends. You, of course, have the right to a second opinion, or to ignore the problem, but knowledge is power - the doctor knows this - and you now have new information to help you improve your overall health.

So how do you “sell” without “selling”? It is actually easier than it seems in my opinion and experience. Years ago, one of my company’s customers was struggling. They were using all aspects of the product they purchased - 100% utilization, but they did not feel like they were really getting value from their spend with us. They were questioning whether they should renew the contract. (Think of the guy at the gym who goes faithfully but is not losing the weight he wants to lose.)

The Account Manager (salesperson) suggested that they meet with Professional Services to see if there was anything we could do to help them get value. They knew they should be getting value, and they were open to talking with us. The Rep asked me to join a call with the customer. We had a preliminary conversation about what they were doing and why they thought they weren’t able to get value. I asked a lot of questions and learned a lot. I felt strongly that if one of my consultants could work with them for 2-3 weeks, we could develop a "path to value" for them. They agreed, and we got started with  a three-week, billable services engagement designed to find that path.

In the first few days, the consultant realized that many of the things they were doing with our product were redundant and not adding value. Her first recommendation was to turn off a slew of things they were doing with us - a scary thought for a SaaS company that makes money on consumption of the product. Still, she knew it was the right thing to do. The customer complied, consumption went down, and the customer instantly trusted the consultant to do right by them.

Over the next week or two, the consultant identified a number of things they weren’t doing with our product that they really should do. She made recommendations and help them set up those things. Unfortunately, they didn’t buy enough of our stuff to do everything that she was recommending. The end result was that the customer called their Rep and bought more of our stuff - more than doubling their spend with us. The consultant was not in “selling” mode at any point in her work. She was acting as a highly-skilled consultant, understanding what they needed, and advising them of how to meet their needs. Success!!

So, worry less about whether you are “selling” and worry more about listening to your customers, understand where they have pain you can address, and help them buy when that is the right thing for them to reduce their pain.

Sunday, April 20, 2014

Reminder: So, Why Do You Hate Submitting Your Time Sheets - A Survey

World-Class PSO is an organization that is passionate about building World-Class Professional Services Organizations. We believe that time tracking and professional services automation (PSA) are critical components of building such organizations, but we recognize that the current tools on the market fall short of meeting the needs of busy, often traveling, consultants and hourly contractors. This impacts the quality of data and the ability for practice managers to make data driven business decisions. 

We are conducting a survey to better understand why consultants and hourly contractors struggle to get their time sheets submitted on time and/or accurately. If you are one who is required to submit time sheets as part of your job, your response would be appreciated. 

This 21-question survey will take less than 10 minutes to complete (it took us 4), and all respondents who complete the survey will receive a $10 iTunes Gift Certificate through email. 


Thanks in advance for your participation! 
The Team at World-Class PSO 

Saturday, April 5, 2014

So, Why Do You Hate to Submit Your Time Sheets?

World-Class PSO is an organization that is passionate about building World-Class Professional Services Organizations. We believe that time tracking and professional services automation (PSA) are critical components of building such organizations, but we recognize that the current tools on the market fall short of meeting the needs of busy, often traveling, consultants and hourly contractors. This impacts the quality of data and the ability for practice managers to make data driven business decisions. 

We are conducting a survey to better understand why consultants and hourly contractors struggle to get their time sheets submitted on time and/or accurately. If you are one who is required to submit time sheets as part of your job, your response would be appreciated. 

This 21-question survey will take less than 10 minutes to complete (it took us 4), and all respondents who complete the survey will receive a $10 iTunes Gift Certificate through email. 



Thanks in advance for your participation! 
The Team at World-Class PSO 

Wednesday, January 8, 2014

Answering the “So What” Question

I have read and reviewed countless consulting reports and sat in on way more consulting sessions than I can count, and I think the biggest issue I have seen in them, besides the poor grammar, is the level of information assumed by the author (the consultant) on behalf of the reader (the client). We assume the reader knows what the chart on page 2 is telling them. We assume the reader knows what the “obvious” next step is based on the information provided. In the end, we produce documents that are often well-written but don’t actually say anything actionable.

Years ago I took over a small consulting group at a software company. The consultants on the team were tasked with analyzing large quantities of data to help their clients understand the current state and, presumably, how to address problems. The first iterations of these reports were often full of beautiful pie charts, bar charts, and line graphs meant to articulate the current state of a series of key performance indicators (KPIs). I was new to the space and just learning myself. So I was actually the perfect reviewer of these docs. Why? Because I had almost as much knowledge on the subject as our average consumer of the report on the client’s side. If I couldn't understand what was being said, chances are they could not either. So, when I reviewed these docs with their beautiful graphs and charts and no description by the author of what the charts represented (is it good or bad and what steps could the team take to improve the resulrs), I broke out my red pen (or turned on Track Changes in Word). The most common comment I made was a simple “So What?” around the words or images that seemed to me to say nothing on which I could truly act, because I really didn’t know what the author was saying, or more often, why she was saying it at that time.

As a consultant, you are also an educator. Your customers often hire you because you have a breadth of knowledge that they don’t have. Maybe they have their own corporate perspective, but they are looking for you to shed light on the industry perspective, the competitive landscape. Maybe the challenge at hand is brand new to them - they are greenfield and need some serious hand-holding. Maybe, still, your day-to-day contacts are just as knowledgeable as you, but they need an “independent third-party perspective” on the subject, and the ultimate consumer - their boss or their boss’ boss - knows very little on the subject.

In any case, you need to provide the proper context on the problem:

  1. What is the problem?
  2. Is this problem unique to your customer or something you’ve seen before (some how it is comforting to know you are not alone in this, after all)?
  3. If it is something you’ve seen before, what aspects of the problem and/or solution are unique to your client?
  4. What evidence exists that supports the existence of the problem?

As you provide evidence that support your thesis, explain what you are seeing (or showing) and why it is relevant, but don’t stop there. Make clear and actionable recommendations to your client with regard to what they should consider doing next. Where possible, cater your recommendations to what you believe will work in their organization. (I prefer to see the recommendations in line with the problem statements and evidence, and I tend to highlight the main recommendation statement in bold to make all recommendations easy to find. I always summarize all recommendations in the conclusion of the document for those interested just in the Cliff Notes version of your report.)

Before you ship your deliverable off for an internal review or to the client, especially the client, read every line and review every chart, graph, table, picture, icon...you get the point. Ask yourself, “So What?” but ask from the reader’s perspective: Given what I know about the ultimate consumer of this material, have I made it clear to her/him why I made this statement or have presented this chart? If not, you have more work to do. Do not leave the information in your report to interpretation. Make it clear what you are saying and why you are saying it. Your client can certainly debate your theories and recommendations, and they should, but first they need to understand them.


Using the “So What?” litmus test consistently on every report, slide deck, and even in all of your conversations with the client will ensure you are truly being clear with your intentions, ideas, understanding, and perspective. Only then can your client think intelligently about and challenge your perspective and, ultimately, make the best possible decision about next steps.

Thursday, December 19, 2013

Tell Them What They Need to Hear, Not What They Want to Hear...Diplomatically

I don’t espouse the concept “the customer is always right.” Let’s face it, customers are humans and no human is always right. Additionally, customers hire us because they know they are not the experts in the area where they need help. You, the consultant, are the expert. By design, you know more about the subject matter than they, have seen numerous situations similar to what they are experiencing, and have the battle scars to help them through this challenging time.

With that said, it is not your job to tell them what to do or to push them to do what you want them to do. As Peter Block wrote in his book, Flawless Consulting, your job as a consultant is to help the customer “ask and answer” his own questions. So, first, you need to work very hard to understand this customer’s political, economic, technical, and environmental situation. You then need to understand the current state of the challenge at hand, including what they have already tried to do to resolve the issue. You also need to determine their desired future state...what does success look like for them?

This isn’t easy to do. Often times, the customer has a vision for how they want to solve the problem. They may want to rely on you to implement the solution and worry less about whether you have a perspective to bring to the table that may present a better solution.

In the past, I have had to discuss risky decisions that put my company or my customer’s company in unacceptable levels of risk, concerns with scope changes that may affect project timelines and budgets, and process and standard operating procedures (SOPs) that are making the work harder to complete than it should be. In most cases, when I have approached the customer, making it clear why I could not do what they asked but provided alternatives that either solved the same problem or came close, I ended up with a happy customer. Sure, I may have caused some amount of grief initially when I explained the concerns and challenges with their request, but they soon forgot that when I delivered on my promise of what I could do.

A few years ago, I was managing a consulting team that worked on ongoing projects for our customers. We had a project manager (PM) change on our side. The project was well underway, certain SOPs were in place, and the customer had well engrained expectations for how things would work. They had extremely high expectations with regard to turn around times on certain pieces of work, and timeliness and quality could not be sacrificed.

My new PM identified a serious policy violation in one of the SOPs employed by our team and the customer. He knew we were handling a key aspect of the project in a dangerous way, but he felt the customer’s PM had provided instruction and we had to “trust” that their PM new what he was doing.

It didn’t take long for our customer’s management team to learn about the SOP, and when they did, their PM and we were in a lot of trouble. The management team felt exactly as my PM did – this is wrong and we have to stop now. The only difference was that they said something. Additionally, while both parties, their PM and our team can share the blame for letting this SOP stand, our customer’s management team held us MORE accountable. Why? We are the experts. They hired us to do this right, and we let a poor practice stand. They were right. We should have had the courage to discuss our concerns about the practice with the customer’s PM and, if he didn’t agree to a change, let that PM know that we had to escalate because of the seriousness of the risk we saw in the practice.

Back when I was a PM implementing software solutions, it was not uncommon for a customer to request a change that was difficult or costly to implement. It was my job to ensure we understood the need, why the customer was asking for the change, and the specifics of the change. It was also my job to work with my project team to understand the implications of the change: What is the technical solution? Do we have all of the information we need? Does the requirement conflict with any other requirements already in play? What is the level of effort required? Will we stay within the customer’s budget or meet their launch date if we move forward with the change? If the answers to these questions are negative, it was then my job to have a heart-to-heart with the customer. If, for instance, this new request conflicts with the project charter or other requirements to which we have already agreed, we need to discuss the impact on the overall project and whether this change will fundamentally change the objective and outcomes? We may need to call on our executive sponsors to make the ultimate decision as to how to move forward, and for some stakeholders, our suggestion to call in the sponsor may not be seen as “working with” them as a team. It can get sticky pretty quickly…”You want to go over my head?” Well, yes, as a matter of fact we do. How you do it requires tact and probably support from senior members of your team.

If the new requirement does not create a conflict with the charter, but does introduce significant rework, many man hours of new development, and/or put the project budget or schedule at risk, you need to have that conversation, too. Notice, in neither scenario am I suggesting you say “no” to your customer. Rather, you must be clear what the implications of the change is and let them decide. If this change is critical and getting it in is more important that the budget or schedule, they will sign your Change Request (CR) and you will get what you need to move forward.

In another example, I worked with a customer a few years back who insist in implementing a custom process to manage the workflow for a key part of the program managed by my services teams. While there are times when a custom workflow is necessary, this custom request not only added no additional value, it created significantly more work to implement and maintain than our standard process used by countless other customers. The custom process introduced too many opportunities for human error that caused us and the customer pain. We struggled to identify a way to illustrate to the customer why this process was flawed. We were not able to be clear with regard to the pros and cons of the process. We needed to do a better job to help the customer understand and acknowledge the risk he is introducing. I often wonder if the team has ever been able to tell the customer what they needed to hear and implemented a solution that recognized the clients situation as well as what we knew to be best practices.