ardonio.com

The most burning question a business generally has for engineers is “when will it be finished”.  They are looking for a specific date and often a specific plan for how you’ll get there. They would most likely be overjoyed if you could tell them exactly at which point in time you will write which line of code. As engineers we have a love/hate relationship with that question. Somehow there is an understanding of the importance, but we are dealing with so much unknowns that we find it hard to commit. It’s in our nature to look at all possibilities and account for a large number complications, even though they may never occur. And then there’s off course always the “give us a clear requirement” catch-phrase we throw back at the business. (truth to be told, we often don’t do a good job in helping the business find that clear requirement, but that’s a different discussion altogether)

To many engineers the request for a date seems unreasonable and shows a clear lack of understanding and appreciation for engineering from the business side. However, if you look at where those people come from it’s not so hard to understand.
When you have to plan a production-type operation you are dealing with a known process. You know every step of the way, probably in great detail. So it’s rather easy to plan. If you know that turning a screw takes 2 seconds, it’s a no-brainer to see that in one minute you can turn 30 screws. It’s very predictable and controlled. And the more detail you get in your planning, generally the more control you’ll have.

Unfortunately, all that is not so much true for engineering. Crafting software is a creative process. It’s about figuring stuff out. Stuff ranging from a vague requirement to the logic that goes into an algorithm. It’s dealing with unclarity and vagueness. Software is often more of a trial and error thing. And the unknown is feared by many as it means letting go of that tight control they had for decades.
The key to engineering is not fearing but embracing failure, and often to try and fail as soon as possible. Many innovations have come after numerous iterations of failure and software is no exception to that rule. Engineers need room to experiment, and you can’t plan for that. You can’t plan (in the typical production way): “let’s fail five times and get it right the sixth”.

All that doesn’t mean that engineers shouldn’t do planning but there’s a different angle to it. Engineers might not readily admit it, but generally if you give them a problem they can make a reasonable estimate. It won’t be accurate per se, but they will have a gut feeling for what it will take. They understand their job and even though they can’t predict every possible failure they encounter they generally can outline an approach in their head and take a shot at telling where the painpoints will be. The key here is that in the end they are still only estimates. They are not the exact science to what traditional managers are used to, only an indication of magnitude of work.
Sometimes though, that simply isn’t possible. The problem might be to vague, the problem space not enough understood, … . In that case I am a huge fan of timeboxing. Reserve a specific set of time to do some preliminary analysis, come up with questions, possibilities, … and present that back to the original requester.

As I said many times before, the job of a good project manager is twofold. First there is the making of a plan, which accounts for both the operational tasks and the more freeform creativity needed for engineers. Second, and more important, is dealing with changes in that plan.