Asking questions is a skill. For a consultant, PM or a business analyst, it’s a critical skill. It’s about asking the right questions in the right way.

What are the right questions? That depends on your objective. Who, what, when, why, how are a good place to start. Thinking about your end goal will help determine what information you need.

• What are we trying to do?
• When do you need to have it done?
• Who will be doing the work, who will be affected by the outcomes?
• Why are you trying to achieve this?
• How have you done this in the past, how can we get started…?

These are all excellent questions. When the questions are framed this way the gap is context. When you start to form your questions, think about the people you will be asking, is there ambiguity in the context? Will you need to explain the background? Can your answer come in a yes/no format – this is not what you are aiming for most of the time.

Let’s look at an example.

Question:

Do you have a PMO?

Answer:

Yes or no.

This can be misleading when you go to implement a solution.

If you realize there’s more information, you might ask what does the PMO do? If you go down this route, you’ll get the information you need, eventually, but you are setting up more of an interrogation than an interview.

A new approach:

Question:

Often an organization has formal or informal project support, methodology, training and prioritization. How is this handled in your company?

Answer:

Depending on your client, you’ll get a different answer – what you will get, though is a conversation rather than an answer. The conversation will lead to a richer understanding of what, why, how, who, when.

If you think about the bigger picture of the information you need, you’ll start to form more open and encompassing questions and the result will be a better understanding of your client.

Do you have any success stories, or horror stories?

The big thing right now is e-reader comparison, will the iPad kill the Kindle? Is the Kobo reader the best thing since the printing press, should I buy the Sony reader. I have read a lot of these comparisons because I am an e-publisher in my other life. But what I notice when I come to use these comparisons to decide whether I want to buy a device, there are few if any comparisons to my requirements.

This could be because it’s hard for the person posting the comparison to know what I want – my requirements. I think, though that they could come up with a preliminary list. Some do, by default they compare what they think is important. Just like during the requirements gathering stage of a project. The Business Analyst goes in to the client meeting with a base idea of what they might want.

Do you complete a project based on that first cut of requirements? I hope the answer is no. By assuming you know what the client wants, you are guaranteed to have scope issues, stakeholder and client issues, and lots of workarounds.

In a project environment, you get to speak to the client. Take full advantage of that. Get their ideas, needs and wants on the table – at the start, and during the project. I think it’s important to remember that scope change is not a failure of the project, scope change properly managed will improve the client relationship and the success of the project. Scope creep is usually either due to poorly collected requirements, or to poor scope management.

And to those of you out in the Internet who are doing comparisons, please continue. You may not be measuring the comparison against my requirements, but you are doing a great job.

Success in your projects this week.

Perry

The dream of gathering absolutely complete requirements is just that, a dream.You will find no matter how detailed or complete, or ‘approved as final’ your requirements are, things will change. That isn’t a failure of the requirements, it’s a fact of project management.  If you try to perfect the beginning, you’ll never start your development or build phase.

If there is no element of uncertainty, I don’t think you have a project.

The PM’s job is to manage what happens: issues, changes, delays, opportunities. Doing a great job of gathering requirements only resolves the questions at the beginning of the project. The client or stakeholder, or sponsor will have new ideas as they get new information. The market demands change. The longer the time frame of the project the more likely you will have changes.

Doing a great job of gathering requirements is only one part of the project start. You need to develop your scope change management plan as well. That plan will include your process of assessing changes against the project drivers and making recommendations.

A good scope change plan will help the PM manage ‘pet’ ideas as well as fabulous ideas that everyone loves but will have a significant impact on the time, cost and quality of the original project.

Happy PMing