Eight to Late

Sensemaking and Analytics for Organizations

Appstronauts

with 2 comments

Eliciting and documenting application requirements is hard work. It’s made even harder if one is dealing with an appstronaut. “So who or what’s an appstronaut?” – I hear you ask.  Here’s a definition, along with some  explanatory notes:

Appstronaut (noun): a person who can hold forth for hours on the big picture, but cannot (will not!) get down to details.  
Distribution: Generally found in upper echelons of management,  but sightings have been reported at other levels too. 
Field notes: Appstronauts are characterised by verbosity coupled with a short attention span. They exhibit extreme fondness for strategy,  vision and all that “big picture” stuff, but have little patience for details. They are known to have good ideas, but generally lack the focus to see them through to fruition.

Appstronauts infuriate analysts, who need nitty-gritty details in order to understand and document application requirements. The big picture stuff, as fascinating as it is to the appstronaut, is simply of no use to the analyst.  But, if left unchecked, appstronauts will be content to float around at rarefied heights where ideas are thick, but details thin. Analysts charged with compiling application requirements must bring them down to earth. But, how?  This post aims to answer the question by highlighting some simple techniques to tether appstronauts to reality.

Without further ado, here they are:

  • Start by zooming in on a small part of the big picture: The main problem is that the canvas painted by appstronauts is way too big. A practical way to start filling in  detail is by focusing on a part of the picture and drilling down to specifics. Which part? The answer should be clear from the appstronaut’s spiel. In brief: the part should be important yet easy enough to action or implement. It may be something that ties into existing systems, for instance. What the analyst should look for is a quick win. Something that can be  built quickly, but also provides value to the appstronaut.
  • Contribute to the picture by painting a part of it: The best analysts understand the business thoroughly. Given this, they should be able to contribute to the appstronaut’s vision. In fact, I have sat through meetings where smart analysts have steered the discussion (with tact!) in productive directions. At this point the analyst is contributing to the vision too.
  • Help appstronauts drill down to specifics: Appstronauts abhor details; analysts thrive on them. The analyst’s job is to get appstronauts to talk about specifics.  To do this, it can be helpful to send out a list of questions before the meeting so that appstronauts come in prepared. Very often, they’ll throw up their hands and say, “It’s your job to fill in the details.” At this point the analyst has to gently, but firmly, insist that details of business requirements have to come from (no surprise!) the business.
  • Verify mutual understanding: It is important to verify that both parties – the appstronaut and the analyst – have a common understanding of what transpires in a requirements analysis session. This should be done  both during and after the meeting. During the session the analyst should, by asking appropriate questions, check that their understanding of the requirements is correct . After the session,  a compilation of notes should be sent out, asking users to send their corrections and comments within the next day or two. This gives them a chance to make any revisions before  work on documenting the requirements is started. This is standard practice in requirements elicitation, but is absolutely critical when one is dealing with an appstronaut (remember the “short attention span” bit in the field notes above)
  • Use visual aids (screen mock-ups, process diagrams etc.) liberally: This applies both to the analysis sessions and the documents. Often, in requirements sessions I use the whiteboard to sketch process flows, relationships and even app screen layouts.  Any documents or presentations should have lots of visuals as appstronauts  have even less patience than others to go through large swathes of text.

After bagging appstronauts through most of this piece, I should acknowledge that they can play a key role in driving important business initiatives. As mentioned in the field notes above, they  often have good ideas but need some help implementing them. This is where the analyst comes in: he or she is very familiar with the business and/or associated systems, and is thus well placed to help appstronauts add substance to their grand, but ethereal, visions. If approached constructively, working with appstronauts can be an opportunity instead of a trial.

Written by K

May 25, 2008 at 9:33 pm

2 Responses

Subscribe to comments with RSS.

  1. Great term, Appstronauts. It takes a very skilled analyst to be able to pull them down a notch or two. Otherwise, get names of those that can provide the details.

    I’ve seen analysts also stuck in big picture mode. I normally referred to those analysts stuck in analysis paralysis. I’ve also seen analysts that are so detailed oriented that they can not connect to the big picture. The result is many mini applications that do not connect or do in a faulty bridge type connection.

    It’s not the big picture business folks job to know what IT needs. It is the analyst’s job to ask the right questions. You provide excellent ideas (that I’ve seen work) to help get all the information needed for application developers. I wish analysts would concentrate more on the type of requirements/information that is needed to build applications than on notation wars.

    Like

    sbditipsblog

    May 26, 2008 at 3:06 am

  2. Thanks for your comments.

    I absolutely agree that analysts can overdo the analysis thing, and get so stuck on details that they forget the big picture. In such situations appstronauts can provide much needed balance.

    You also make an excellent point about notation wars. Business analysis should focus on figuring out what’s needed to build an application, and documenting requirements in simple language. Despite trends to the contrary, tools and notation are not the be all and end all of analysis.

    Regards,

    Kailash.

    Like

    k

    May 26, 2008 at 10:09 am


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: