Tell Your Offshore Vendor a Story

• I need your feedback to a question at the end of this Runtime.
• Please respond by email or posting on the Accelerance Blog. Thanks.

Once you select a reliable offshore vendor the next challenge you face is describing what your software should do. Too often companies think if they pick a great offshore vendor then writing a specification becomes the vendor's problem.

Face it, even if you pick an offshore vendor with the brightest brainiacs, how are they going to know what your users need and expect? If your programmers are in Mumbai how will they know what your users want in Milwaukee?

You have to remain involved.

Involved!? Heck, you have to be COMMITTED to getting your offshore vendor the information they need to make you successful. And of all the things you can tell them about your software – from your target market down to the number of database tables you think you need – the most important element is use cases or user stories.

A few weeks ago I volunteered to be a judge for the annual CODiES awards given out by the Software and Information Industry Association (SIIA) to the "best-of-the-best" software products and services. See http://www.siia.net/codies/2007/ for details about this competition.

As a judge I am witnessing many online demonstrations of software. Generally they are a reasonable display of the features and functions of the software. But almost all these demos are missing something very important.

You need to tell a story!

It is rare to hear a good story in a demo. Usually it's, “You click here and you see this data and then this bar chart changes color...” And so on.

Yes, but what are you really trying to do? What is your goal in clicking on all these buttons and links? What's the story?

Stories are how we humans communicate best. If you want someone to remember something (like how wonderful your software is) then tell them a story.

In her book The Story Factor, author Annette Simmons says, “Most of the time you won't be present when the people you want to influence make the decision... A story is like mental software that you supply so your listener can run it again later... This is as close as you can get to programming someone else's brain.”

And that's what you want to do – program your programmers' brains properly so they can go off and create the software you need.

I said earlier that the most important element of your specifications is the use case or user story. These are the main tools of the business analyst, marketing professional, and software designer to describe how your software is used. Written use cases explain how users interact with your software in an attempt to achieve their goals.

For example, suppose you are a hiring manager using a new software application to control the recruiting process. You will have a use case for entering a new job requisition where you login, enter the job description, salary requirements, etc. Then you submit the requisition for approval by the Director of Human Resources.

And who are the users of your software, and what are their goals? Are there multiple user types, or is every user the same?

In the example above, you can see there are at least two user roles – the hiring manager and the HR Director. There could also be a Recruiter and a Job Applicant and maybe others.

To be most effective, use cases should be illustrated with a mock-up of your user interface that shows what the user is doing. These user interface screens should be tied together in a sequence to tell the stories of how your system is used.

So what's your story? Are you able to explain the benefits of your software with use cases and stories? Will you be able to do it yourself, or do you need help?

I am in the early stages of developing a series of teleseminars to show how you can describe your software with use cases and user stories for more effective outsourcing.

But I need your advice. The format could be:

• Teleseminar lectures covering the details of these techniques
• Interactive sessions where your own software descriptions are constructively criticized
• A combination of both

Which would you prefer? Send me an email with your answer or post your reply on the Accelerance blog. Thanks!

***

The Runtime Bottom Line:

  Eliminate the mystery of what your software should do with these 4 steps:

• Define your user roles
• Describe the steps the users take to use your software
• Illustrate the process with a mock-up of your user interface
• Tie them together to tell the stories of how your software is used.

Do this and you will dramatically increase the success of your offshore outsourcing.

Until next time,

Steve Mezak, CEO

Accelerance, Inc.

Risk-Free Outsourcing

http://www.Accelerance.com

Comments

[Luke Hohmann]

Steve -
I think you're absolutely correct that stories are powerful and compelling ways to communicate. I also recommend the work of Roger Schank, especially "Tell Me A Story", for more background on why this is so.

Stories also work well with personas to communicate requirements.

Innovation Games(R) for Customer Understanding are powerful ways to capture and communicate user/market needs to product teams, whether they be in the next cube or across the ocean. Many games provide wonderful, player-generated artwork, and the structure of the games provide the team with an opportunity to engage people in the stories about their requirements and needs. These stories can then be captured into use cases and can help develop personas.

Regards,

Luke Hohmann | CEO | Enthiosys, Inc. | 599 Dawn Drive | Sunnyvale, CA 94087
Innovation Through Understanding
cell: (408) 529-0319 | lhohmann@enthiosys.com
www.enthiosys.com | Join the Innovation Games Forum: www.enthiosys.com/forum
Author of "Beyond Software Architecture: Creating and Sustaining Winning Solutions" and
"Innovation Games: Creating Breakthrough Products Through Collaborative Play"

[Wayne Lo]

I am casting my vote on "Teleseminar lectures covering the details of these techniques."

-Wayne

[John Redford]

These comments have been invaluable to me as is this whole site. I thank you for your comment.