Do Not Work on the Project that Solves More Than one Problem

by Viacheslav Kovalevskyi

One close friend of mine recenly made a comment that stuck in my head for quite some time: "there are too many problems in the proposal". I was not comfortble about this myself(having too many problems) but:

  • I was not sure exactly why. Why is it bad to take initiative and solve 15 problems?
  • How many problems is not too many?

Spending some time reflecting on this, it finally hit me. If you start with the problem in mind you can only start with one, very specific problem that customer is having. You can not say: "There are 15 problems and I'm going to find exactly one solution that solves exactly these problems (not more and not less)." Technically you can say this but it sounds ridiculous, isn't it?

At this point I started wondering, what are the main reasons to put multiple problems in the same document. I found several documents where I was outlining multiple problems, instead of one. And I found two root causes of such behaviour:

  1. Attempting to convince that the project is justified (working backward from the project and convincing that it's need to be done)
  2. Solution started backwards from the problem, however after solutions is outlined author added all other problems that proposed solution is solving (outlining nice side benefits of the solution)

#1 is dangerous and a symptom that the author is NOT working backwards from the problem but rather trying to build a solution and finding the reason why the solution has to be built. Biggest danger of this is that, while the solution might indeed be solving a very critical problem(s) it is hard to find out if this is the simplest solution or not (since evaluation is done backward from the solution and not the problem).

#2, on the other hand, is an absolutely valid use-case. If you work backwards from the problem, and find a solution it makes sense to outline other problems that this solution is solving (as a nice side effect benefit).

So how to distinguish #1 from #2? Sinc in many documents #1 might not be distinguishable from the #2. In order to do so from now on I decided to explicitly outline what is the problem,  that we are solving with each project and what are the side problems that this solution is solving (as a nice side benefit). While the main problem should be solved no matter what the solution is, the list of the rest of the problems can be dynamic (in scope of the document).