PM Golden Rule: Open questions!

Pierrick -

The best way to start a project or to determine the cause of an issue? Asking questions, a lot, the more the better!
But always keep in mind: there are no stupid questions but there are useless ones. Your client, like anybody else, has a limited time of attention for you so wasting some on unnecessary question will only lead to an incomplete comprehension of the product.

Open Questions

The best way to achieve that is to use the famous 5 Ws and 1 H. You don't know about it? Make sense, like most of people!

To make it simple, they're the words you should always use to start your questions:

  • What
  • Where
  • When
  • Who
  • Why
  • How

There is no order to respect, just keep using them until you go to the very depth of the need or issue. Now let's see how we can use them with a concrete example and the questions to avoid, of course.

Automate salaries

Sounds appealing, right? I'm using this example because it was one of my first task as a team leader and the one where I did some mistakes with my questions.

Basically, the client wanted to automate the salaries' payment for all employees based on excel import and validation between departments. Let's get started!

Good
  • Client: I would like to automate salaries' payment
  • IT: Sure, how is the current process working?
  • Client: Currently, we're using excel to check the validity of data and upon validation, insert them into another application which will proceed to the payment with the bank
Bad
  • Client: I would like to automate salaries' payment
  • IT: Sure, is there an existing process?
  • Client: Yes there is
  • IT: Ok, how does it work?
  • Client: We've an excel to check the validity of data and upon validation insert them into another application which will proceed to the payment with the bank

Do you start to understand what I meant by useless question? On the right, we used a question and gained absolutely nothing from it. On the left, even if there is no process, the client will just tell you and you can ask: "How would you imagine it?". Let's keep digging!

Good
  • IT: Who's involved in the different part of the process?
  • Client: Data validation is made by HR department and the manual insertion by the Finance department
  • IT: How the data are validated by HR?
  • Client: They're checking all values, in a line, when summed up are equal to 0. It should be automatically done by the application
Bad
  • IT: Who's involved in the different part of the process?
  • Client: Data validation is made by HR department and the manual insertion by the Finance department
  • IT: Should we automatically validate data?
  • Client: Yes, it would be helpful
  • IT: How does it work?
  • Client: HR are checking that all values, in a line, when summed up are equal to 0

It may sound as a useless improvement since it's only one or two more questions but imagine a way more complicated project where you'll end up with 20 questions instead of 10 and a 1h meeting instead of 30 minutes. Moreover, by asking closed questions, you're directing your client into your way of thinking (IT mind) and not their (Business mind). Let's finish our example with few last questions.

Good
  • IT: You mentionned another application to proceed to payment. Who's in charge of it?
  • Client: John Wick, I will share his contact with you. Nice guy but be aware of its dog
  • IT: When would except this project to be released ?
  • Client: We don't have a specific expected date but the sooner the better
Bad
  • IT: You mentionned another application to proceed to payment. Is there a documentation?
  • Client: Honestly I don't know about that
  • IT: Can you check and come back to us with this information?
  • Client: Ok
  • IT: When is the release date?
  • Client: I would say the sooner the better

I think you start to have a good understanding of what I meant in the beginning of this article. I haven't go through all steps of the project like the UX/UI, technologies used, … I just wanted a simple set of questions so you get my point and can apply it on your own products.

Pieces of advices

As mentioned above, I couldn't go through every single parts of a product life when taking requirements so here are few advices.

  • Do not force yourself to use all the Ws and H, adapt yourself to the project. On this example, I haven't used "why" because the project is straight forward and easy to understand
  • Start your questions as wide as possible and from the answers get deeper into different subjects. It will help you to understand the bigger picture
  • Never start to think with a IT mind, like thinking the DB when the customer explain the business. It has been one of my biggest mistake at first
  • Always sum up everything you discussed about and agree with the client on the first version on the project
  • Don't suggest too much ideas about possible improvements, it may lead to unnecessary extra work and side effects. Offer to the client to talk himself/herself about what're the next steps of the project

Conclusion

Knowing about these words and learning how to use them, has been one of my biggest step to avoid frustration for my team, gaining more stable projects and sharing a better communication with my clients.
Don't forget it's very adaptive, you don't need to use the same questions than I, start by including these open questions little by little in your processes and feel the difference. You can only gain from it so give it a try!

If you have a problem and no one else can help. Maybe you can hire the Kalvad-Team.