Top 6 Analysis Fails and How to Prevent Them

Every good innovator knows that analysis is always required. It helps ensure we are solving the right problems and building the right solutions. When done thoughtfully, analysis helps us pave a confident path towards value-add improvements.

So why is it so hard to get it right?

Unfortunately, “doing analysis” has become one of those ubiquitous phrases that can literally mean anything. Are you speaking with the client? Are you work shadowing your users? Are you head deep in a massive spreadsheet trying to find the answer to life?

It’s gotten so bad that when someone says they are “doing some analysis,” I imagine them gazing out of a window with a blank stare, lost in what certainly must be analytical-type thoughts. With this much ambiguity, its understandable that many analysis efforts do not achieve what was expected.

What Is Analysis Anyway?

Analysis is not a rigid methodology that can be replicated across any project. It can involve creating a detailed process model or high-level operating model. It can be data focused or conversation based. It can produce visual artifacts or spreadsheet lists. It can really be anything.

As a result, analysis is more of an art and should be flexible enough to meet what is required by the client – whether she is internal, external or even yourself. The goal of any good analysis should be the following:

Provide information that reduces uncertainty enough for the client to make a decision

What does that mean? After doing some type of analysis, I should be able to provide my client with some new insight, which gives them the confidence to decide on what to do next. This usually results in the client kicking off some sort of solution build, but it may even result in the client asking for a different uncertainty to be reduced (ie more analysis required).

Easier Said Than Done

If you’re like me, you don’t always achieve this on your first pass. So for all you struggling analyzers out there, I have complied a few of the biggest challenges experienced in creating useful analysis for our clients.

And for bonus points, I’ve also listed a few tips on how to minimize these as much as possible.

Enjoy!

Top 6 Analysis Fails and How to Prevent Them

1. Taking Too Much Time

Otherwise known as “Analysis Paralysis”, this is probably the most common and well-known issue in this space. More time spent does not always equal more value add for the client (ever hear of the law of diminishing returns). This is particularly important as resourcing tends to be available for a limited amount of time, and you may deliver a beautiful piece of analysis just as your development team is re-prioritized to another project.

Solution:  Ask the client for timelines at the start of any analysis and be sure not to breach that expectation. Balance how much detail can be collected with when a decision needs to be made.

2. Starting From The Solution

This fail is synonymous with Thomas’ thoughts on why starting with a solution is an issue. I am sure you have been on many projects where the first meeting is to discuss how a particular tool can be configured to deliver something. Something that delivers value? Well, if you didn’t start with asking these basic questions, you have no way of knowing:

• What are you trying to achieve / What is your goal?
• How do you measure it?
• What are the biggest issues preventing you from achieving this today?

Not knowing what the client needs is the quickest way to skew your analysis and deliver a questionable recommendation.

Solution: Ask the above questions at the start of EVERY project EVERY time. There is no substitute for really understanding your client’s goals and issues. This will direct your analysis scope to a more fruitful place.

3. Thinking That Completing The Analysis Is The Goal

Folks get so wrapped up in delivering analysis that we forget that this is not the end goal. Analysis does not deliver value on its own, as it needs to be used to create a solution. If you think that your end recommendation is a job well done, you may want to reach out to your clients to see if they really were able to finish the job you helped start.

Also, can you ever really complete an analysis? There will always be more levels of detail to explore if you keep going and going.

Solution: Like Fail #2, always prioritize the end goal of the client and not the fact that you need to finish this analysis for a project.

4. Choosing the Wrong Artifacts

There are so many types of analysis and tools we use to deliver insights, but its often we don’t always choose the right one. In my Tea Garden example, I was working with a very small and well-known process. Do you think my client would have found a BPM helpful if I had made one? If you have ever made a large spreadsheet or PowerPoint that was never touched by the client, you’ve felt this pain.

Solution: Spend time really knowing your client and the questions they are trying to answer. Once you choose your artifact, give the client multiple opportunities to redirect your efforts as you build out each iteration further.

5. Not Being Inclusive

Many times analysis is kicked off by one group that huddles together to figure something out. Then they hand-off their insights to the development team without much context or sponsorship afterwards. It was hard enough for that first team to determine what decision to make, but imagine being the next team that wasn’t even aware of how they got to their conclusion. Even worse, multiple teams may decide to analyze in parallel, ending with divergent projects and development.

Solution: Always speak up if you see that workshops only have one type of stakeholder. Success is significantly more likely if every type of business user and development team are analyzing together.

6. Not Prototyping

Finally, analysis can only take insights so far. At some point, a project team will need to build something to help their users visualize a realm of possibility and finalize requirements. Due to limits in prototyping ability or apprehension to building “throwaway work,” teams may try to glean all possible insights from spreadsheets or BPMs alone. Not surprisingly, once development starts and users actually see real solutions, whole new sets of requirements tend to be generated.

Solution: Be agile! Build in parallel or show users examples of possible solutions while the analysis is happening. This will help inspire the group and generate more specific requirements to action.

Final Thoughts

As always, we’d love to hear your own thoughts and stories on what makes or breaks analysis. In other words, don’t over analyze! Just comment and start a conversation with us.

Happy analyzing!