It’s All About Asking the Right Questions

It’s All About Asking the Right Questions

How often have you seen a project, based on information received during a few initial discovery calls, quickly go off track after jumping into a job where many of the most important items were glossed over or totally forgotten about so now the real LOE is much higher? Why was the estimate off? Was it because the prospective client wanted an estimate before taking all the real requirements into consideration, or was it because someone didn’t want to take a chance on not closing the deal? Answering yes to either question puts you, the project, and the client at risk. So how can we get better estimates as quickly and prudently as possible? What types of questions can we ask to make sure we have a better understanding of what the client really needs?

Whether you’re a consultant or an on-site project manager you may have already experienced this, and said to yourself, I thought we had all the pertinent information, but how did we miss that one!
If this has happened to you, or your team, don’t be too hard on yourself because it happens more often than you think. A quick search on the internet will show over-budget or failed implementation rates of about 50-70% of the time. That’s high regardless of what metrics are being used.

If you think back over your career, how many times have you heard that a project release has been delayed is over budget vs. hey; we’re way under budget, have all the proper resources and a real shot at releasing this thing early? There’s no project tool, scrum leader, or sigma 6 master that can help you out of a hole here.
Obviously, the more project experience we have the better things have a shot at turning out okay, because we’ve learned from our mistakes and won’t be burned by this or that again, but there are probably some basic things that are missed even by more experienced teams. Here are some of the things we have identified.

• Not identifying the “real” stakeholders. We’ve seen many times where the appointed stakeholders are not the people who will use the new solution, nor are they the people who fully know how their current solution works. The importance of including the end user, power user, tribal leader or even the proverbial pain in the butt, upfront and from the beginning, is critical.
• Not asking the right questions. The right questions, depending on who and what you ask, will vary greatly. Management will want anything from a simple overview to granular reporting. Technology will want something that is secure, scalable and easy to maintain. The end user will want something that does their work for them, and the list goes on like this, etc., etc., until the real requirements are lost in the shuffle.
• Not being able to say NO to additional requests and changes when saying NO is required.

There are other things that could fall onto this list, but these are the biggest that we’ve identified over the years. So how have we tried to improve our delivery and results – by coming up with our own simplified one-page questionnaire that sheds insight into not only the solution requirements but also the business itself.
Here is a sample of some of the questions we ask that seem to naturally lead the stakeholder to reveal more information that they might not have thought of in the first place.

• Please tell us about you, the business, and your role within the business. (We’re identifying the real stakeholders here along with getting an in-depth view of the business and structure)

• Please list all the systems you use: CRM, billing, reporting, marketing, etc. (We do this a lot just because even if the current CRM project is in the spotlight now, it doesn’t mean that it won’t need to be developed with a long-term vision of how other systems need to integrate with it in the future. Basically, we’re ensuring that the foundation of the solution will support expansion over the years)

• What are the most important reports or metrics you use to run your business? (We do this because it reveals the technical aspects of a solution that an end-user might not know about or truly understand. It helps us design better database models and ways of storing data that will allow for better analytics in the future. This is something everyone requires now-a-days. It also highlights what is really important to the business, even when no one mentioned it in the discovery calls. If we can deliver a project that gives the business all the same and better metrics than they currently have, that’s called a win.)

• Do you believe you’ll need to change, improve, or implement new business processes to support your new solution or enhancement? (We love this one because it reveals resistance to change, one of the biggest reasons for failed CRM implementations. We use this answer to get ahead game by helping users through the process of change and showing them how the new solution will make their lives easier and the business better. This is where we also identify the proverbial pain in the butt that we mentioned earlier on in the conversation. We often feel like this is the most important question to ask)

While this is not an all-inclusive list of the questions we have or can ask, we’ve found it helpful to keep our questionnaire to a singular page which allows the user to feel like it’s not a burden to answer. We’ve also found that it helps them naturally reveal other insights that might be on the list of forgotten items that are now undermining our project.

There’s an adage (which is not very technical by nature but applies here) that states – measure twice and cut once. When we apply this adage to our thinking about what it takes to get to a successful outcome, we will ensure that we spend extra time examining and speaking with our stakeholders about their answers to our questions and look deeply into what those answers and the story their metrics are telling us. Between the two things we have a better shot of finding that “gotcha” before it gets us.