Let us start with a simple problem. Suppose you planned to wake up and gym tomorrow morning. You have been psyching yourself for this day, and now you are ready. On the planned day, you wake up bright and early only to find its raining! What do you do next?
What is the definition of a problem?
My friend Mercy recently posted a brilliant article Minding your P’s and Queues: Flow Management by Queueing Theory (https://medium.com/swlh/minding-your-ps-and-queues-flow-management-by-queueing-theory-1b45dcd27e33).
In it, she writes this scenario:
Consider a bus with 50 university students attending a music festival arrives at the supermarket. The students all pick their items and head to the tills at 9:00 AM. Assuming the queue already had ten customers, immediately, the queue length increases by 50 arrivals to 6 times its original size. If each customer took an average of 3 minutes, the first customers to experience a doubling of this cycle time to 6 minutes will be, according to Little’s Law, those served at 9:36 AM.
Do you see a problem here?
I say there is no problem. I think nature never offers problems. So what if the customer experienced a delay of 3 minutes? Maybe they enjoy the music at the supermarket!
What we have here is a problematic situation. To get to a problem, we must employ some creativity.
For starters, a problem must have:
- A concerned party
- An ideal state
- The actual state
- A way of knowing the difference
So let’s start on why it makes sense to plan for problems.
Empower the team to recognize problems
I hope the trivialized examples above made the point.
Problems can not just be identified; they need to be defined!
When planning a project, it’s easy to get caught up on the positive vibe of the moment, envisioning how you and your team will be successful.
Reality being what it is, all your grand plans will likely go awry once you hit the real world. You probably already know this, but do your colleagues know?
For all of you to be on the same page, you must agree on what needs to happen in the real world before you call out a problem.
For example:
Problem: Experience resistance from the business
How we will know:
- Julius from HR will remind us of his vendor
- Initiative Z already launched will be canceled
- We will experience an uptick in noncompliance on product Y
By running the exercise, you ensure everyone in the team has the tools necessary to point out problems.
Gain an understanding of the real scope
Let me remind the reader of one of the most famous law in software estimation:
Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
Douglas Hofstadter
Even thou this is not truly a scientific law, as practitioners, we can attest to its integrity. I think the law gets its power from unplanned work.
Let’s get back to our gym example if you run through an exercise defining situation that your team could identify as a problem. You would have probably come up with rain as a problem; this means you would need an umbrella if your original scope were packing your gym clothes and maybe a bottle of water. Now you know you have to pass by the supermarket and buy an umbrella as well.
Solve the solvable
The truth is, you can never anticipate or even accurately define all problems. The real world has too many dimensions for that. But each issue we can expect and plan for, gives us incredible mileage.
I have talked in more detail why you don’t want unplanned work anywhere near you: (How you pay for technical debt) https://blog.chenchatech.com/2016/03/how-you-pay-for-technical-deby/.
How do you plan for problems in your organization? Talk to me in the comment section below, my Linked in chenchajacob or my twitter @jchex
