Tag Archive: consulting


How to Solve Problems More Effectively

Filed under: Consulting — Leave a comment
July 20, 2011

Most of what each of us does each day in our careers, especially for consultants, can fall under the category of Problem Solving. Therefore, it’s important that you are able to do so effectively.  And more than solving the problem effectively, it’s important to be able to communicate effectively in order to both determine how to solve the problem, and how to deliver your end message back to your audience.

A few years ago, I purchased the book  ‘The McKinsey Mind – Understanding and Implementing the Problem-Solving Tools and Management Techniques of the World’s Top Strategic Consulting Firm’  authored by Ethan M. Rasel and Paul N. Friga. This blog post is the combination of my experience regarding problem solving as a consultant, and some of the takeaways from the book I’ve incorporated into  my approach to problem solving.

Key Components of Effective Problem Solving:

  • Framing the Problem
  • Analyzing the Problem
  • Sourcing Data / Interviewing
  • Understanding the Results
  • Communicating your Recommendation

Framing the Problem

This involves utilizing some sort of structure to define the problem in managable component elements. Structure can help strengthen your thought process around the problem at hand. Consider using visual structures/diagrams to break the problem down. When you’re going through the process of breaking the problem down, ensure your components are unique and don’t overlap, while making sure to include any relevent issue into your structure. Over time, you will develop a set of tools that work for you, that can be leveraged time and time again, but remember, that every problem may be unique and any one tool isn’t a magic bullet. Early on in the process, as you identify key issues, come up with an idea, or a hypothesis of what the solution might be. If you have a hypothesis, you can attempt to prove or disprove it. In other words, don’t just search the haystack randomly, come up with the idea that there’s a needle you’re looking for first!

Also remember: “The Problem” is not always THE problem. Resist tempation to jump to the first conclusion, or the first diagnosis. Dig deeper, ask questions, look for facts. Always look to get to the real problem, though it might not be obvious or the first symptom you come across.

Analyzing the Problem

You’re hoping to identify the key drivers of the problem. It’s easy to get hung up on small details, to overanalyze (analysis paralysis). To combat that, take a look at the big picture, focus on the core issues, and ask yourself is what you’re spending time on getting you closer to your goal, or further away from it? Rule out what is NOT important, so right away you know you don’t have to waste any precious time on those things, look for some quick wins the can make big contributions to prove or refute your initial hypothesis. While you want to be correct, absolute precision might waste too much time, try to get into the right ballpark. If you’re finding it hard to find facts to support or refute your hypothesis directly, look for indirect indicators that may help you triangulate around the problem – use what you know, to help you learn about what you don’t know.

Sourcing Data

Data and facts are key to solving any problem. They are objective. They are also key to communicating out your solution back to the client. Don’t hide from the unpleasant facts, as that is only counter-productive to your problem solving effort. When researching and asking questions, don’t accept “I don’t know” as a valid answer. Everyone always has some sort of idea, or contribution to make. Most often, that response is the manifestation of the resistance to something and your challenge is to figure out the source of that resistance and adjust accordingly.  Start with available reports/statistics, look for key opportunities for investigation, and keep your eye out for best practices and if they are being followed.  Chances are the problem you are facing has been solved before, and thus, it’s important to retain and exploit your experience and your coworkers experiences to help solve similar future problems. To that end, knowledge management is important and part of the value that consultants should be bringing to the table. When it comes to data and quality, remember: garbage in, garbage out!

Sourcing Data: Interviewing

Go into interviews prepared. Know what questions you want to ask, and lay them out in a structured format, as sort of an interview guide or agenda. Consider whittling it down to the top 3 or 4 important questions and letting those spawn additional questions as the discusson goes on. Your time and your interviewee’s time is extremely valuable, be organized and efficent in order to gain the maximum value within the shortest amount of time. Listen. Really listen, and then guide as needed to keep the interview on track. Realize that your interviewee may be feeling stressed under pressure, and be sensitive to any fears they may have. Establish a connection, and explain positive objectives to them. Don’t leave your interviewee feeling regret twoards the process afterwards by being overbearing or too aggressive.  The most difficult interviews will be with the people whom feel their job is being threatened by you, handle those situations professionally and work through it for the benefit of the organization. Always ask an open ended question allowing your interviewee to tell you anything else that’s on their mind. And afterwards, follow up with a Thank you note – resist the urge to skip that small step, it’s important!

Understanding the Results

Approach the results with the same level of analysis as you did when first attempting to understand the problem. Check the data for accuracy, and what needs to be true for that piece of data to be a factor in the overall equation. Like back in math class, check your answer. How far off would your data/analysis need to be to completely change your recommendation?  The 80/20 principle holds true here, focus on what the 20% is doing right, and how you can bring the other 80% in-line. Charts can be helpful tools, and also be sure to keep daily track of what you learned that day that helped move your solution forward. For each piece of the analysis, ask yourself how is it useful and what recommendations it leads to? It’s your job as the consultant to provide insight into the problem you are solving, and you do that by making sound recommendations on the client’s problem. And lastly, don’t try to make the facts fit the solution, as it’s easy to fall into that trap when you’ve already made your hypothesis. Go back, create a new hypothesis if needed, but always ensure you are analyzing objectively.

Communicating your Recommendation

Communication and presentation skills are essential to effective problem solving. You can find the coolest solution ever, but it will mean nothing if you cannot present your findings and recommendations effectively to your clients. Think of it this way, you are selling something – in this case an idea/recommendation – and while you and your team may appreciate the value in that, you need to convince the buyers, your clients. Your presentation is the tool for getting that done and organization, simplicity, and meaningful information is essential for communicating the full impact of your idea. Speaking of meaningful information, charts are great, but they should serve a purpose and not just be there to look pretty. Bullet points are bad, visual representations of ideas are better.  In order to maximize buy-in, walk the key decision makers through your findings before the full presenation. This will help bring major objections out ahead of time, build consensus, and give you a chance to adapt to any external political realities. On presenation day, being flexible and respectful of your audience will go a long way!

The key to effective problem solving is taking a methodical, organized approach to analyzing the problem, and communicating effictively. If you can do those two things well, you’re going to find much better success as solving your problems more effectively.

Tags: , ,
Comment

How to Avoid Implementing a Horrible BPMS Design

Filed under: BPM, Consulting, Friendly Advice, Pegasystems — Leave a comment

One of the saddest parts of my job is when I hear from clients about #BPMS implementation disasters. Why? Because in almost every case it could have been avoided.  As consultants, we’ve all seen it… The client brings you in to help fight the fire left behind by an already in-progress, or already delivered application that was designed poorly and nobody bothered to tell the client that before they eventually figured it out the hard (and expensive!) way.  It’s just plain sad. While yes, it’s good for me, because I’m getting paid to help, I much prefer to get paid to help prevent such disasters and ensure success in the first place.

While I think this applies to every implementation, it is even more critical on the first or other early implementations while the client is still building their internal skillsets in the BPMS product.

I’ve noticed some commonalities I’d like to share with you:

  1. The clients hired outside consultants for expertise (usually from a single firm)
  2. If design reviews were done, it was by the same group of people who did the design in the first place
  3. Cost played a large factor in choosing which outside firm to bring in
  4. Implementation schedule was often rushed/aggressive (aren’t they all?)
  5. Vendor/Product guardrails weren’t properly followed
  6. Client employees may bring concerns/risks/issues to light, but backed down easily when the consultants reassured them

The above list may not be an exhaustive list of the warning signs for a potential disaster in the making, and may even all hold true for even very successful implementations, but the first key to prevention is awareness!

Let’s take a closer look at each one of these points.

The clients hired outside consultants for expertise (generally from a single firm)

The good news is: Clients are generally pretty good at understanding their own weaknesses, and know when they need to turn to outside help. This is when RFPs fly around, sales teams with polished presentations come in, and their best and brightest pre-sales technical teams come right along with them to amaze you with the speed and power of their skills. For the very first implementation, perhaps they turn to the software vendor itself even. There’s absolutely nothing wrong with turning to outside consultants for help, when needed. Perhaps the company has a standing list of approved contract partners they work off of to bring teams in. But generally, at the end of that process, a single firm is picked to help get the job done.

The bad news is: Clients don’t have the internal expertise in the first place, which also means they may not have the expertise to know if the people they are bringing in are true experts or not.  That same bright pre-sales tech team might not be the same team that shows up for the first day onsite. That’s not to say the team that does show up won’t be bright as well, it just means they are unknown. The client is trusting their chosen vendor to bring in experts, and guide the implementation in the very best way possible.

While being able to trust your vendors and contracting firms is important, until you’ve seen them succeed in your enterprise with the particular kind of task being asked of them, hope and blind faith is not a business strategy! To mitigate the risk of relying on a single outside firm for expertise contributing to a horrible BPMS design, consider using consultants outside from at least two firms. Like going, getting second opinions can be very valuable!

If design reviews were done, it was by the same group of people who did the design in the first place

Design reviews are an important part of your the BPMS governance process, and the Center of Excellence should be involved to some extent. This is critical early on as the team is maturing, because anything designed and built early on, will become the foundation for everything built in the future.  The issue with these problem design reviews were that the same people who did the design were the ones reviewing it, and obviously, no glaring deficiencies are likely to come to light during this process. Unless you are absolutely confident in your teams ability to produce excellent designs, I recommend having them reviewed by a separate team. Perhaps consider bringing in a 3rd party team specifically for these reviews. The cost of a second opinion is a small price of insurance to pay to protect against the implementation of a horrible design.

Cost played a large factor in choosing which outside firm to bring in

Business units & the IT teams that support them are under constant pressure to spend money wisely, and reduce expenses where they can. After spending potentially very large sums on money an a BPMS product, the thought of spending more piles of money on external consultants can be a hard pill to swallow. Sometimes these pressures cause staffing decisions to be a matter of cost. This can be fatal. Cheaper hourly rates do not necessarily mean cheaper long-term costs, especially in the scenario where you end up paying high-priced experts to come in and fight the fires in the event of a disaster. I’m not saying lower costs resources cannot be found that can do a good job, I’m just saying that it’s less likely, especially in a market such as BPMS implementations right now, and that the old magnums “You get what you pay for” and “Let the Buyer Beware” are in full effect. If you are choosing to go with lower cost service providers, ensure you do your due diligence to understand what the full expertise level of what you are buying is — and everyone you ask will tell you they are experts — you need to find this answer out externally, or via carefully designed interview processes and/or POCs

Implementation schedule was often rushed/aggressive

I’m not sure this needs much explanation, because so often this is the norm rather than the exception. The biggest problem I have with this is that it just amplifies potential issues. There’s less time to review for quality, less time to ensure the right solution is being implemented for long term success, less time to take a step back and see that something doesn’t look right, and — even if you do notice something is wrong, I’ve heard of project managers moving forward with the poor design anyway because they refuse to jeopardize the dates that were previously promised. This only exacerbates the problems in the long run. Agile and iterative methodologies are great when done correctly, but speed means nothing if you don’t do it right!

Vendor/Product guardrails weren’t properly followed

They’re called guardrails for a reason! If your consultants are actively advocating for designs that downplay or break the guardrails, that’s a warning sign. I’ve yet to come across an application that I needed to design a solution that significantly broke guardrails. Even in the instances when I did need to design outside of or bend the guardrails it was done in a very surgically targeted fashion, for a very specific purpose.

Client employees may bring concerns/risks/issues to light, but backed down easily when the consultants reassured them

Again, clients are pretty good at knowing what they don’t know, and knowing what they know pretty well too. If it feels funny and just doesn’t seem right, it probably isn’t. I’ve had clients who brought their concerns up to the previous consultants on multiple occasions and let themselves be satisfied with lengthy elaborate explanations that just confused them, so they let it go. Consultants hone their communication skills and messaging framing mechanisms to a fine art. Communication is a necessary skill for consultants, however, some become great bullshit artists! Remember: consultants are there to serve you, the client, and if something doesn’t feel right to you, don’t just give up at the first sign of resistance.

Recap on helpful practices to avoid this sort of disaster:

  • Like with doctors, sometimes a second expert opinion can be a lifesaver. Bring in multiple firms to work together if you can.
  • Design reviews should be done by someone(s) other than who did the design. That’s why it’s a review! These people should be your top experts in the product.
  • You get what you pay for, and design is not a place to skimp. Production support, small enhancements maybe, but please not on your whole design!
  • Take the time to do it right where you can. Lesser experienced teams sometimes take disastrous shortcuts when under pressure.
  • Follow the guardrails given by the product vendor, deviate from them only as rare exceptions, not for the basis of your design!
  • If it walks, talks, and looks like a duck. It’s a duck. Don’t let someone convince you it’s a swan!

If you or your team might be in need of a second opinion for a BPMS design review, or other services, let’s talk and see if I can be of any assistance!

Tags: , , , , , ,
Comment

Asking Questions

Filed under: BPM, Consulting, Friendly Advice — Leave a comment
July 10, 2011

I was a curious kid, I read a lot of books, I stuck my finger in light sockets, and I ask A LOT of questions. It was always why does this _______, what does that _________, how come __________, who, what, when where, why, and how. My mother and grandparents did their best to put up with my constant bombardment of questions, they took me to the library to find endless books about endless topics. Sometimes I’d find the answer, sometimes I’d be told I’d figure it out when I got older, sometimes i just forgot about one thing and moved onto ten more.

Today, as a BPM practitioner and consultant, I still find myself asking a lot of questions, just to different people and a different kind of question. Where does the process start? Who does what along the way? When do we know we’ve reached the goal? How can we make improvements? What are you unhappy about with your current system? Why why this proposed solution be a better solution? So on and so forth…

Many people think it’s about knowing the right answers, and while to certain extents that helps…. I think it’s even more important to know how to ask the right questions, and to know who to ask them to. Once you know that, the answers can be determined, but if you don’t know how to ask the right question, how do you know you’re getting the right answers? Furthermore, you only gain the right answers because at one time you asked the right question… How do I do this, How does this work, what happens if I, What have did I learn from this, What can be done better next time, etc…

As a child, success meant knowledge for the sake of having knowledge. It mean learning something new, just because. Success meant simply finding the answers to feed my curiosity. As an adult, and in my profession the real success comes with what I do with the answers I find out, but it’s the questions I ask that help me get there!

So, I’ll leave you with a question. Are you asking the right questions to be successful?

Tags: , , ,
Comment

Nine Men Can’t Make a Baby in…

Filed under: BPM, Consulting, Friendly Advice — 2 Comments

You’ve heard the popular phrase “Nine women can’t make a baby in a month.” I’ve often heard it uttered by the team being asked to deliver on unreasonable expectations when poor decisions by the powers that be led to those decisions being made, and those same powers that be are adding X number of resources to help. Essentially, what the team is saying back is that while the task at hand can be done, throwing more resources at the problem isn’t going to help speed the solution along any faster.

I have my own spin on the phrase and it is that “Nine men can’t make a baby in a month, or even 9 months, nor in any amount of time in the foreseeable future.”

What do I mean by this?

Well the issue of throwing more people at a solution and not getting to it any faster still exists, but now we have a new problem. Not only are we attempting to solve a problem by just throwing resources at it, we’re not even throwing the right resources at it for it to get accomplished at all. If you don’t begin with the right team, you’re not going to get the results you were hoping to get, no matter how positive your outlook, or how insistently you promised your superiors the job would get done.

With knowledge work especially, it’s the people and team you assemble that are going to make or break your solution. It’s not how much money can you, or can’t you, spend. It’s not how much time you do, or do not, have. It’s the people & their skillset that are going to help you to succeed. This is key to being successful.

How is this Relevant?

I cant count the number of projects I’ve been on, been privileged to knowing about, or heard about from various industry peers that have run into this exact scenario on an all too frequent occurrence. I’ve seen medium-to-large BPM software implementations with lofty goals (we won’t get into why the goals are so lofty in this post), with 40+ developers “working” to implement the solution.  In several of these cases, not only was throwing 40 developers on the problem the incorrect thing to do, they didn’t have the correct knowledge or experience to deliver quality results.   The results of having too many people? Well, maybe you spend too much money, have people doing very little at times, and have people walking on top of each other making things confusing. The results of have too many unskilled people and expecting the quality results? Disastrous.

There are only four outcomes of such a disaster:

  1. The entire program is scrapped, wasting millions of dollars of time, effort, and product licensing.
  2. Millions of dollars are spent to correct the situation by bringing in the team that should have been assembled the first time.
  3. The team suffers endlessly, realizing their mistake too late, but not having the right resources to fix it, and they go on supporting a horrible product
  4. Nobody bothers to realize the disaster, or pretends it doesn’t exist and goes on existing long enough to get promoted and start the cycle over again.

Don’t let this happen to you. Ensure you have the right team, with the right tools, in place to be successful – the first time. If you’re not sure if you have the right team in place to be successful, seek out professional guidance from someone you trust to help assemble the team and get it on the right track. Don’t just rely on the sales guy’s finely honed pitched as your litmus test.

A Major Problem…

Determining if you have the right team, first requires you or someone you trust to understand the skills and expertise it’s going to take to solve your issue, and how much work there is involved.  Many times, the company who’s paying for the team to come in doesn’t have the expertise internally, and they are trusting the team they hire to come in and help them. If you don’t have the expertise, just how are you going to verify who you’re bringing in (and all the people they plan to throw your way) have the right expertise?

You can’t hire a team to make a baby unless you understand that it takes a certain amount of time, and a couple of very specific people to do so. The same applies to your BPM implementation. You can’t ensure you’re hiring the right team if you don’t understand the right amount of time and skillsets it will take to be successful. I encourage some upfront investment in education on this point, or at a minimum some outside expertise to help you make the right decisions, even if that individual(s) are only there for this specific task & amount of time.

When you’re paying by the hour, you want to be sure you’re getting your money’s worth and I believe it’s imperative to interview each resource you’re putting on the project just as if you were hiring them yourselves. Ensure they can hold their own when discussing the product or service involved, and have the experience and can speak at length about that detail.

Expertise costs money. Junior resources can be cheap, and the cost savings can be tempting. Don’t fall into the trap of trying to take nine men and make a baby!

Tags: , ,
Comment