Plan ahead to avoid surprises

Feb 11, 2006

A couple of colleagues and I talked about how unpleasant surprises could be avoided if you use the time needed to research the task before actually starting to work on it. It turned out, we all did it in our own distinct way, but the end results were the same. I, for instance, use scenarios as my primary tool for scoping a task. Some uses a more theoretic approach and some googles for the answer first and asks the questions later. These are all valid approaches in my opinion.

The tricky part of all this is, that it is very hard to measure the effectiveness of each approach. After all, it is the finished task that is the goal and not the process it self. Some would disagree, but that is another argument. I think my approach is the best, of course, because it asks the questions before looking for answers. The questions help define the details surrounding the task, details that are both critical and non-critical to success. The answers can then be found in books or the web if you do not know them yourself.

By finding-the-answers-first approach, you would typically search the web for similar tasks and read about how other people have solved them. This is also very efficient, but it does not let you define the details of your own task before you get the answer. You could end up half way through the task, realizing you had taken a wrong turn because you didn’t see a small but important detail somewhere down the road. If however, you are convinced that the answer suit your needs, one could argue it would be a waste of time asking all the questions, and thereby making this your favorite approach.

It is of course not so black and white. Different approaches suits different tasks and it would be wisely to choose the right approach before starting the task. However, some tend to lean more on one specific approach more often than others do. In fact, this was exactly what we found when discussing this at work. We all had our favorite.

* $4.95/month BlogEngine.net Hosting – Click Here!

Comments (4) -

Pelle
Pelle
2/12/2006 1:54:34 PM #

I'm pleased to be the first person to comment one of your posts. And I do admit that I actually planned to wirte this comment for a day or so Smile

I agree with you 100% that the better we can plan ahead the better we do our job. This is, however, not a very a very controversial statement since this is pretty much what I do for a living.

The question at hand is off course that no matter how much we plan, there will always be some little detail, no one thought of. Sometimes the designers combine two technologies without thinking about the obvious issues this can cause, sometimes the design manual isn’t detailed enough, and sometimes the manual is over detailed.

So what is one to do? Research a little better and remember what you did the last time. Most of the time I use my “general toolbox” to try avoid problems I’ve had in the past and when my tools somehow don’t comply to the job, then I try to see what other people have written about it. This helps me most of my time. Does it make my work perfect – I doubt it ;)

 Mads Kristensen
Mads Kristensen
2/13/2006 6:55:21 PM #

Pelle wrote:
"The question at hand is off course that no matter how much we plan, there will always be some
little detail, no one thought of. Sometimes the designers combine two technologies without thinking about the obvious issues this can cause, sometimes the design manual isn’t detailed enough, and sometimes the manual is over detailed."

This is exactly what I'm talking about. If the designers thought about the bigger picture and large scale scenarios instead of just isolated functionality scenarios, surprises could be avoided to some extend. Of course there are always details no one ever could have foreseen, but they will be kept as few as possible and maybe non-critical. This is not to criticise designers in particular, it could be anybody in a project team, and it is not critique but purely observation.

When we force our selves to look at the task from above, as high as we can foresee, the surprises are fewer. This is obvious, but nevertheless, it has proven time and time again to be hard to remember. Ultimately, it will save time in the end, because you don’t have to go back and maybe start over, because of some crappy detail you missed.

Pelle
Pelle
2/14/2006 6:50:59 PM #

Actually when you write that the designers often don't see the bigger picture, I think that we should try to see it from their (my?) perspective: We/they do not focus on what can be done, but what we want. This is often - if not always - not the same as the possibilies at hand.

Most innovation (of the disruptive kind) do not come by thinking "...hmm I can totally do this the way I've always done it", but by saying "Wow, that means that I have to find new tools, new ways of programming, etc."

But I would indeed like to hear suggestions how to make me do my work better ;)

 Mads Kristensen
Mads Kristensen
2/14/2006 7:41:24 PM #

Pelle, as I wrote earlier, this is not about designers exclusively. This is about all members of a project team, from developers to designer to architects to project managers etc. It was you mentioning designers, which is why I picked it up.

Actually, this may be more of an issue amongst developers. We are so hungry for writing code that we sometimes "forget" to do some properly planning. This is why I feel so strongly about this issue and thinking I got the answer by using scenarios as the right approach for planning. I would like to think, that I rarely suffer for not planning enough, and that is why I wrote the blog entry in the first place - to give a heads up. Even though I write to developers, I believe it to be applicable to all members of a team as before mentioned.

You do a great job. My fingers do not point your way, amigo ;)

Comments are closed

About the author

Mads Kristensen

Mads Kristensen
Program Manager at the Microsoft Web Platform team and founder of BlogEngine.NET.

More...

Month List

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer’s view in any way.