Friday, October 12, 2012

The 90 Minute Design

In this blog, we spend a lot of time discussing what we believe are best practices in regards to promoting innovative technology solutions; occasionally though, we are going to highlight poor practice as well. The poor practice we're going to highlight today is probably familiar to anyone who has worked as a senior analyst, software engineer or architect - we'll just refer to it as the "90 minute design." This practice can occur under a number of different circumstances, but the characteristics of the practice boil down to these common elements:
  1. The person or persons asked to perform the design have little or no knowledge of the problem or organization before being handed the assignment.
  2. There is usually no agenda or ability to get key questions asked and clarified in the time allowed. 
  3. The folks who set up the session begin with unrealistic expectations as to what can or should be produced in that time-frame given the circumstances.
So to be clear, let's provide a little more context - usually when this happens the people requesting design support have been facing the challenge for months or years. Also, these folks who tend to judge a 90 minute exercise have had 100's or 1000's of hours working in that unique problem-space - sometimes it is a common problem across industry, other times it gets very specific to that one organization.

Bad decisions can be made remarkably fast, yet they tend to live on forever...
 So, given this background, how often do you think that such an effort might succeed in promoting a viable design solution? If you said almost never you'd be right. Beyond the obvious; here are the reasons that this represents poor practice:
  • Without context and background - something engineers, architects or designers gain through assessments or investigation - it is nearly impossible to validate what the real problem is. Often times, stakeholders will begin with an assumption about the problem that in fact turns out to be wrong. 
  • Process exists for a reason - IT is not a land of magicians and psychics - we can solve problems not by pulling rabbits out of hats but by being disciplined in how we investigate and work through problems. If we respect the process - the process will provide dividends. 
  • Too often, decisions made from hastily convened design sessions become set in stone - at that point often organizations become saddled with what can only be described as guesswork.
Some people might contend that this is how "Agile IT" is supposed to work, but that is a bit a of a cop out. The 90 minute design was around long before Agile methodologies became commonplace but more than that, Agile design does not advocate short-circuiting process but rather addressing it in smaller chunks.

The next time someone asks you to solve a complex problem for them - something they couldn't solve themselves - in 90 minutes, just say no. It'll only end up disappointing both parties...



Copyright 2012, Semantech Inc. All rights Reserved 

0 comments:

Post a Comment