The industrial age is behind us. It was surpassed by the knowledge economy, rapidly evolved into the attention economy. Successful companies realize that attention comes as a result of conversation. We’re now in the conversation economy.

Software as a Service and Conversation

Software as a Service (SaaS) products are products where instead of paying an up-front licensing fee, customers make recurring payments, for as long as they use the software. As soon as the software becomes obsolete, or you no longer need it, you stop using it – and stop paying for it. As long as the product continues to be relevant, and continues to provide the best solutions for your problems, you’ll keep using it.

Peter Cohen at SaaS Market Strategy Advisors, recently did some analysis on the lifetime value of a SaaS customer. What was particularly interesting was that he found that the return on investment (revenue versus cost of acquisition) grows dramatically over a one, three, and five year analysis. His analysis is particularly exciting because he’s quantified the benefits of focusing on your existing customers.  Anecdotally, he shows that Salesforce.com needs to keep customers around for a bit under three years to cover their marketing expenses.  Given how integral CRM becomes once deployed at a large company, that’s not a bad bet – Salesforce can become an entrenched player, who will only be displaced when their customers focus on the ongoing costs (versus the ongoing benefits).

In my previous article on the economics of SaaS (and the extended remix version published in The Pragmatic Marketer), I provided a qualitative analysis, and the logical conclusion that SaaS providers are incented to focus on their existing customers. Cohen’s analysis supports those conclusions and makes them more concrete.

Long Term Relationships and Conversation

A long term relationship with your customers requires you to have an ongoing conversation with them. To keep that relationship going for years, it also needs to be a fantastic conversation.

A fantastic conversation is one where not only you, but your customers are engaged. Ask yourself – if you’re talking to your customers over coffee, are they leaning back, or leaning forward? Engaged users are leaning forward, and disengaged users are leaning back.

If your users aren’t leaning forward, you need to figure out how to make the conversation more interesting to them and get them engaged.

Activity Versus Engagement and Conversation

In the bad old days, you either forgot to think about your customers, or you thought about them as active or inactive.   That was the way we framed analysis.  And SaaS models forced us to focus on helping inactive customers re-activate.

A conversational model is different, however.  Just because a customer is active does not mean they are engaged.  More on this later – just planting a seed for now.

The Freemium Business Model and Conversation

The freemium business model is one where some people get to use your product for free, where other people are paying customers who get to use a different version of the same product. The revenues from your paying customers cover the costs of providing your product to all of your customers. This is a common business model to use with SaaS products, but can also be applied to licensed products. The costs of development, support, and ongoing operations are all covered by the paying customers – even though you incur costs from the free-product users too.

In a recent interview with Damon Darlin on the New York Times site, Evernote’s CEO, Phil Libin talked quite candidly about the conversion of users of the free version of Evernote into paying customers. He noted that the longer a user sticks around, the more likely that user is to become a customer of Evernote’s for-a-fee version.

Mr. Libin studied the behavior of the earliest adopters and found that the longer customers used the service, the more likely they were to start paying for it. About 0.5 percent convert to paying customers in the first month. But after about a year, 4 percent have converted. (He says he thinks the figure will top out at about 22 percent.)

While I’m not convinced that 22% conversion is achievable, the trend is obvious, and 4% is a fantastic number.

You have to have a pretty engaging conversation to keep users around long enough to be profitable.

Combining The Activity Model and the Freemium Model

We can combine the active-inactive perspective with the for-a-fee and for-free approach, and we get the following magic square.

This diagram is interesting, but oh-so-2005.  The only moderately interesting insight you get is that the inactive, for-a-fee customers are at risk.  They’re just giving you money for no good reason.  You should probably figure out how to help them before they go away (and take their money with them).

Introducing a Conversation Model – QCP

As I mentioned earlier, being active does not necessarily mean being engaged and conversational.  The following three categories make sense for thinking about “how conversational” a customer is:

• Quiet - An active, satisfied, and possibly loyal, but not outspoken customer (or user).
• Conversing - A customer or user who is engaging with you and with the community about your products.
• Promoting- A customer or user who is actively encouraging other people to become customers or users.

Quiet customers are like the active users in the old model.  They use the software and pay the bills on time.  Quiet customers are passive.  But in a conversational economy, that’s not enough.  It may be enough to keep the lights on, but you can’t hope to defend against your competition when all of your customers are quiet.

Conversing customers are engaged in conversation – with you and with the community (yours and theirs).  Conversing customers are following you on Twitter, they are fans of your Facebook page, and they retweet, like, and favorite your messages.  They interact with you – asking questions, submitting bugs and feature requests.  The write blog posts, and are extroverted in sharing their relationship (with you) with their friends.  In the standard “engagement model” (satisfied, loyal, and engaged), these customers are engaged.  From the conversing customers you improve your understanding of your market, users, and competition.  These customers are the foundation of your business.

Promoting customers are your dream team.  They aren’t just interacting publicly with you, they are promoting your product.  When you begin to focus on word of mouth marketing, or viral product management, you’ll start sending presents to these folks and inviting them to the company kegger.

Your Thoughts and More Thoughts

I’d love for you to share your thoughts here with me and everyone else!

I feel like this is more of a starting point than a comprehensive article.  For example, I have some scribbles about how to move customers  from the “active free” box to the “active for-a-fee” box (and from inactive to active, etc), and how to move people up the QCP ladder.  Will cover that stuff in a future article.

So – chime in, and as my dad would say, please and thank you!

Pictures can convey messages much more powerfully than words.  In a recent discussion about writing whitepapers, I suggested combining the idea-creation advice from Made To Stick with the image-creation advice from Back of The Napkin.  Check out this article to see some concrete examples.

Made To Stick

Paul Young, product manager and author of Product Beautiful,  sent out a tweet the other day asking:

Anyone have any “best practices” for whitepaper development? E.g. most whitepapers I read are stilted, I want to make something compelling.

Tweet, on twitter

I suggested combining the ideas from Made to Stick and Back of the Napkin to create a compelling whitepaper.  Stephanie Tilton then replied with a link to a good article she wrote showing how to apply the ideas from Made to Stick to writing whitepapers.

The book, Made To Stick: Why Some Ideas Survive and Others Die, written by Chip Heath and Dan Heath, has some very powerful ideas for communicating ideas.  Stephanie sums them up nicely in her article:

• Simple
• Unexpected
• Concrete
• Credible
• Emotional
• Stories

Stephanie Tilton, How to Craft Whitepapers that Stick in People’s Minds

Check it out, she goes into more detail, with examples and insights about why they work.  What about the Back of the Napkin ideas?  That’s what this article covers.

Back of the Napkin

I remember feeling like I’d been hit in my frontal cortex with a frying pan at Product Camp Austin (Winter 2009), when I first saw a visualization created by Sunni Brown of Brightspot for one of the presentations.  I remembered hearing about Back of the Napkin: Solving Problems and Selling Ideas with Pictures, by Dan Roam, and immediately ordered it from Amazon.  This is actually the current book for the Smarter Product Managers book club.

Applying these visualization techniques is extremely compelling for sharing ideas.

There is a ton of science behind why (and how) visual presentation of ideas (pictures) works so well.  Dan Roam does a fantastic job of making this approachable and actionable – an excellent book.

Getting back to the conversation…

How to Put Pictures in your Whitepaper

The rest of this article is showing some example images, in Back of the Napkin style, that support the ideas from Made to Stick, as you would include them in a whitepaper.

Imagine you’re writing a whitepaper about requirements elicitation.  There are a lot of important topics you could cover, but to stay aligned with the simple message from Made to Stick, you will want to focus on one idea (for each whitepaper, as Stephanie explains in her article).

User representatives are often offered to business analysts as a “convenient” source of requirements – the actual users are too busy, too valuable, or too easily distracted/upset/encouraged by conversations about the future.  This idea is both bad and pervasive.  You want your whitepaper to convey emotionally why this is bad.  You need something concrete, and maybe you want to tell a story.  Consider this image:

This is poorly drawn (but that’s ok!), but it establishes the metaphor that inserting user representatives into the elicitation process is like playing the telephone game.  The message (user goals) gets lost between the users and the business analyst.  It also points out that the conversation between users and analysts is what makes good requirements elication, well, good (ref. the smiley faces in the drawing if you’re not sure).

Designing for “Everyone” is a Bad Idea

One challenge for product managers is determining which features to include in their product roadmap.  Industry analysts, and sometimes buyers, have been known to use checklists to pre-screen or select products.  That may be true, but using a checklist to prioritize your product development is a bad idea, because you end up creating a product that doesn’t thrill any particular users, and just makes analysts happy.

The quick mock-up of a Consumer Reports style checklist shows a comparison of your product against the competition’s product.  With six features (A through F), it appears that your product is better.  [Here's an article comparing elicitation techniques, with a real consumer-reports-style checklist and an explanation of how to read it.]  You have six “half-circles” which looks to be “better” than two “full circles.”  Therein lies the danger.

Any individual user cares about two or three of those features (capabilities), not all six of them.  Will that user prefer your product or the competition’s product?

That user is thrilled to use your competition’s product, because it does what that user cares about, really well.  Your product is half-baked. Happy analyst, missing user (for you).

Increasing Distribution Channels Decreases Sales

Another key idea from Made to Stick is the notion of presenting the unexpected.  The authors point out that you need to demonstrate an idea that is at odds with the reader’s concept of reality – breaking it – and then rebuild the reader’s sense of reality around your new idea.  That’s where the unexpected comes in.

Consider that you are selling a product into a crowded market, with many places that customers could buy your product.  You do your inital launch, selling through one sales channel.  Someone proposes adding other channels – hey, more is better, right?

How do you prevent this Benedict Arnold from killing your company with what looks to be a great idea?  How about getting people’s attention with this “violation of common sense”:

That will get people’s attention.  What the Heath brothers point out is that to establish credibility with this unexpected visual, you have to rebuild people’s perspective.  You could do that with the following:

Since each store (channel) has a best-sellers list, like the Billboard charts for music, you want to make sure you’re at the top of the list.  Most downloaded is a common metric for software available on shareware and freeware sites.  If people can get your product anywhere they happen to be, it will dillute your rankings at every store.  By targeting your marketing and making your product available at one store, you will get more traffic (at that store) than you otherwise would.  Then new potential customers will be more likely to discover your product because it is at the top of the list.

Climate Change

I touched on credibility in the last example.  As Stephanie points out in her article, the Made to Stick authors were talking more about data than visceral understanding.  The first thought that popped into my head was the effectiveness of Al Gore’s data in his An Inconvenient Truth book (and presentation and movie).  He demonstrates that there is a correlation (and implies that there is a causal effect) between the average temperatures on earth and carbon dioxide levels.

Pretty powerful message.

Conclusion

Pictures like the ones above, drawn as Dan Roam suggests in Back of the Napkin can make the ideas you present in your whitepaper really memorable.  Use the Heath brothers’ approach from Made to Stick in crafting your message, and fold it into your whitepaper as Stephanie suggests.

The result is a compelling and memorable white paper, just like Paul always wanted.

Blue Ocean Strategy provides an interesting reactive analysis of companies and markets.  Personas are used to understand your customer’s needs.  Combining the two provides powerful proactive insights when positioning your product for market success.

Blue Ocean Strategy

The book, Blue Ocean Strategy: How to Create Uncontested Market Space and Make Competition Irrelevant, by Kim and Mauborgne, was written in 2005.  The book presents a very compelling way to visualize competition in your market by contrasting the emphasis (or effectiveness) of each company at solving particular problems.  The authors argue that red oceans are competitive markets where companies compete to solve the same problems for the same customers.  Their main idea is that by identifying (and solving) unaddressed problems, you can define a new market – a blue ocean with no relevant competitors.  The “red” in their metaphor implies blood in the water, caused by cut-throat competition.  Their position – by defining a new market boundaries with no competition, you eliminate the blood in the water and give yourself a calm, blue ocean in which to navigate your company.

This is a compelling idea, and has a lot of merit.  The Smarter Product Managers book club (started by Cindy Alvarez) reviewed this book last month, and one conclusion we reached during the discussion is that the examples in the book felt “reverse-engineered.”  I feel that the lack of prescriptive advice from the authors created a sense of “that’s fine, but how do I apply these ideas proactively?”   Some of the examples in the book, like Cirque de Solei and Southwest Airlines, felt very compelling (and are often cited), while others felt a bit more contrived.  Almost as if the authors were searching for data to support their arguments – a big no-no for product managers.

Creating a Blue Ocean Strategy Map

The book presents examples of “mapping” markets based upon the strength of the offerings from companies, along different dimensions.  The following example was created by me (and is used throughout this article), but follows the pattern of analysis described in the book.  This is an unresearched, hypothetical example analysis of the market for vaccuum cleaners – or more generically, floor cleaning products.

 [larger image]

The diagram above identifies seven dimensions by which you could characterize the offerings from each company.

• Breathe Easier / Anti-Allergen – sometimes, people vaccuum their rugs in order to reduce allergens (by sucking up dust), making it easier for them to breathe in their homes.  Vaccuum cleaners work by sucking up air through the carpet, collecting the dirt (that is sucked up along with the air), and filtering the exhaust air (that is expelled into the room).  Different vaccuum cleaners pay different levels of attention to removing allergens during this cleaning process, by (1) getting the allergens out of the carpet and (2) filtering the allergens out of the exhaust air.
• Remove Stains – one motivation to clean your floor is to remove stains.  This is not generally a focus of vaccuum cleaners, but products like the Green Machine do focus on removing stains, while also “picking up dirt.”
• Physically Easy to Use – after back surgery, one of the key pieces of advice my mother received from her doctor was “no vaccuuming.”  When you are young and healthy, you don’t expect vaccuuming to be something that is forbidden by your doctor.  Shoveling snow, climbing a mountain, running a marathon, yes – but vaccuuming?
• Reducing Hassle – Why don’t we vaccuum every day?  Because it can be a hassle to get out the vaccuum, set up the equipment, and actually use it.  When you reduce the hassle involved in vaccuuming, you are likely to vaccuum more often, thereby realizing more benefits from vaccuuming.
• Saving Time – Hassle is not the only barrier to vaccuuming.  If you could vaccuum your house in 5 minutes instead of 105 minutes, you would do it more often.  As a teenager, I used to jog behind the lawn mower, just to get the yard done so I could move on to other things.
• Reliability – While reliability is not a major factor when vaccuuming your house (once), it is a key component of making purchasing decisions – because you don’t vaccuum just once.  The more you vaccuum, the more you care about reliability.  This is also an indirect cost factor – a vaccuum cleaner that has to be frequently repaired or replaced will cost more per year than one that has the same purchase price and is more reliable.  This is also an indirect hassle factor – you may delay vaccuuming your home until you can make time to get a broken vaccuum cleaner repaired.
• Avoiding Cost – A direct focus on cost is primarily driven by purchase price.  Other factors (like reliability, and the cost of replacement bags or filters), but people place greater emphasis on purchase price when thinking about cost.  Consumer Reports and other “product review” companies will often “do the math” for you, taking into account all of the post-purchase costs to calculate total-cost-of-ownership.

The above diagram, with fictitous values for “Strength of Competitive Offering”, shows the competitive landscape for the vaccuum cleaner market.  One of the very powerful features of this visualization is that the Roomba faces “no competition” from the other companies in three of the seven categories – Ease of Use, Hassle, and Time.  A Blue Ocean Strategy analysis would say that the Roomba has created their own market, with an absense of competition.

This gets back to our insight that the examples felt “reverse engineered.”  The Roomba does have a dramatically different value-proposition, and focused on dimensions that are not addressed by their competition.  So why isn’t the Roomba in the book?  Because they still compete in the red ocean.  Unlike Southwest Airlines, they did not differentiate their offering in a relevant way.  And that’s the problem we found in trying to apply the principles from the book.  

It is not enough to be innovative and differentiated, which the Roomba certainly is, you have to be valuably differentiated.

So how do you differentiate valuably and proactively?  Identify the problems that your customers value, but don’t yet have solutions for.  How do you do that?  With personas.

Personas

Personas represent customers in your target markets.  Markets are not homogenous – different people in your markets value different things for different reasons.  You develop personas as archetypes to represent subsets of the customers in a given market who share common problems.  More concretely, personas share common valuations of shared problems.

To combine persona development with the market-mapping concept from Blue Ocean Strategy, create the same map, but for personas.  Instead of identifying the strength of each company/product along each dimension, identify how much each persona cares about each particular dimension.

 [larger image]

In the chart above, I’ve created 6 hypothetical personas who populate our market:

• Single Parent – the classic superman / superwoman who does everything, including keeping the house clean.
• Housekeeper – someone employed to keep someone else’s house clean.
• Office Cleaner – the person who vaccuums your office at 2am every night and picks up all the empty Diet Coke cans and Twinkee wrappers.
• Kid (Doing Chores) – most kids won’t ask for a vaccuum cleaner for their birthday, but when you child is responsible for vaccuuming, do you want a battle every week because they hate it?
• Homeowner – like the single parent, but maybe without kids, and definitely with fewer responsibilities (and more time).
• Retiree – like the homeowner, but with a lot more time, and a less robust physical condition.

[Note - the above examples are really stereotypes and not personas (there is no research to back them up - they are entirely fictional) - don't fall into the trap of thinking persona development is this easy.]

OK, now we have an understanding of how much importance each persona places on each dimension.  It looks like a mess, for this example, when you try and absorb the big picture.  If you focus on a single persona, you get great clarity about what that type of customer cares about.  Look at each curve individually, then look at them all together.  If you’re thinking ahead, you’ll suspect that the Roomba is perfect for the kid doing chores.  But wait, we’ll come back to that.

One insight we can gain from this messy view of the market is that you can’t create a product that is “perfect” for all of these personas.  You have to target a specific persona, and tailor your product for that persona.

Mapping Personas to Products

Now we have two views of the market, along 7 dimensions.  We have assessments of the relative strength of each competitor’s offering, and we have estimates of the relative importance to each persona – for each dimension.  What we need to do is combine the two.

All of this analysis runs the risk of introducing a notion of false precision - we have a lot of data, therefore it must be accurate.  So our inclination may be to try and do some mathematically refined, scientific analysis.  I suspect that would be wasted effort, providing no additional insights, and risking leaps to the wrong conclusions.  I propose a simpler approach.

The analysis we really care about – which product offering is best aligned with the needs of each persona?  A simple mathematical equivalent of “which curves match the best” is an easy analysis.  By comparing the values from each competitor curve with those of each persona curve, we can create a series of “how good a fit is it?” values.

 [larger image]

Imagine a persona saying “how well does each company’s product align with my goals?”  This “simple math mashup” takes into account both “they succeed at what I care about” and “they haven’t invested in something I don’t care about (at the expense of something I do care about).”

You can see that the Roomba clearly wins with kids doing chores.  The rest of offerings stand out less, but do provide insight.  Now you can easily drive strategic decisions – “we want to be the vaccuum of choice for housekeepers” now drives some obvious emphasis on ease of use and a reduced emphasis on reducing costs.

Improving The Model

My two main problems with the blue ocean strategy were lack of relevance (who cares about dimension X) and magnitude (which dimension is most important?).  The model above addresses only relevance – a focus on target personas.  We can overlay some “relative importance of each persona” data, or just manually focus our efforts on each persona in series.  

The other magnitude challenge is in understanding not just which problems are important in absolute terms (kids care a lot about saving time, but not cost), but in relative terms (kids would trade an hour of time for a modicum of ease-of-use).  Essentially, defining the utility-curves for each persona.  For any but the largest, most saturated markets, I would hesitate to do the utility curve analysis in detail – it feels too heavyweight and un-agile.

Conclusion

The Blue Ocean Strategy book provides us with a visceral tool for visualizing relative offerings from competitors in a given market.  Combine it with the same visualization approach for personas that participate in that market, and you gain insights into which problems to solve next to achieve product success.

We spend a lot of time (rightly) on the capabilities of our products – identifying valuable problems and compelling solutions.  This focus is ideal for addressing the needs of our users.  But what if people abandon our products before trying them?  First impressions matter – both for buyers and users.

SXSW BizSpark Accelerator

Microsoft sponsored the BizSpark Accelerator at SXSW this year, where several startups competed by giving a 2 minute presentation of their products / companies.  The panel of judges emceed by Guy Kawasaki and Brad King.  The contestents were the top 20 from 200 submissions.

First Impressions

I was lucky to attend part of the event, focusing on the eight finalists in the Innovative Web Technologies area.  I recorded the presentations, but the camera shakes so badly in my hand that watching them is like trying to listen to a lecture while riding a rollercoaster.

Two minutes is barely enough time to make a first impression.  Each presenter had 15 minutes of Q&A with the panel, where they could get into more details and provide feedback to the entrepreneurs.  First impressions, however, are made by the very first thing you say.  Here’s the first sentance from each of the presenting finalists:

• klout.net – Hi everyone, I’m Joe.  At klout, we measure influence across the social web.
• OtherInbox - Thanks everybody, my name is Josh Baer, and I’m here to tell you about OtherInbox, which helps you save your real inbox for real people.
• Piryx - The idea is that you want to wake up, create an account, run for public office, and change the world. [Note - I lost the first sentance when recording, but this is the first substantive sentance]
• Ribbit.com – My name is David Lee, I am the director of strategy and business development for Ribbit Corporation. Ribbit is a cloud service for enabling communications innovation, bringing together the internet, voice, and data.
• Ringlight - I’m here to talk to you about my company, Ringlight.  My name is Brandon Wiley, I’ve been working in peer-to-peer for a decade, from the first peer-to-peer application, freenet, to the most popular peer-to-peer application in the world, bittorrent.
• Thrive - My name is Avi Karnani from Thrive.  I’m going to show you a new feature we’re about to launch called behavioral budgeting.
• YouData - Let’s talk about internet advertising.  [something garbled as the speaker had trouble speaking clearly into the microphone]
• Zoomorama - Hello, my name is Franklin, and I’m president of Zoomorama.  Zoomorama comes from panorama, the wide open space, and indeed zooming is not just about details, it is mostly about space. [Note that in parallel with the speaker, the display was showing some compelling image zooming technologies]

Every one of these presenters made a first impression.  klout, OtherInbox, and Zoomorama (and maybe Piryx) tell you what their products do in the opening sentance.  Ringlight and YouData both set the tone by identifying an existing space.  Thrive lets us know that whatever it is, we haven’t heard of it before, and Ribbit shared a lot of jargon words.

Elevator Pitch

When I was in presales, I learned how to craft an elevator pitch.  What I had not heard of before this year’s conference was the one-floor/two-floor pitch. 

An elevator pitch is a presentation of what your product (or company) does, that is short enough to be delivered while conveniently riding on an elevator with the really important person you want to hear your pitch.  It is a powerful image, used to remind us that people will usually give us a brief opportunity to get their attention.  To get more time, we have to earn additional attention.

The one-floor elevator pitch is a variation of the elevator pitch, but imagine your audience gets off the elevator after one floor.  You really only have time to get out a sentance or two – just like the above quotes.  

Which of the eight presenters, after giving the quotes above, would get invited to follow their listener down the hall, and which would have to stay on the elevator?

I saw the full presentations, and one of the presenters is a client, so I won’t share an opinion.  Would love to hear yours.

As a product manager, what would you have wanted the presenter to say for the one-floor elevator pitch?

There’s really only one way to travel down a waterfall – in a barrel.  A lot of people died this way, but some survived.  Software projects have been predominantly waterfall projects since the start of software projects.  And stakeholders rode down those projects, basically in a barrel.  The people riding Niagara Falls 100 years ago didn’t know if they would survive until they got to the end.  Stakeholders in waterfall projects don’t know if they will succeed until the end.

An agile project is dependent upon tight interaction (and feedback) with stakeholders.

If you’re running an agile project, and your stakeholders are old-school barrel-riders, how do you make it work?

Expectations, Documentation, and Communication

The success of any project is dependent on setting and managing stakeholder expectations.  In Managing Stakeholder Goals, we talked about assuring that those goals are addressed by our requirements.  And in a later article, we proposed a way to balance the goals of different stakeholder groups when those goals are in opposition.  Those are good tools for making sure we are initially aligned with what we are hearing from stakeholders.

We need to also apply active listening techniques to assure that what we thought we heard is what the stakeholders thought they said.  One way to do that is to write use cases (or user stories) so that we can communicate the intent of the product back to the stakeholders.  This still primarily helps with kicking off a project, in the desired direction, with the correct goals.

There are many ways to document this initial intent of the project and stakeholder goals.  It is analogous to a stakeholder selecting a sturdy barrel and picking a good spot on the river bank to push off.  We’re well positioned to eventually succeed, assuming nothing changes.  After a harrowing fall, we find out how well we did.

A well-run waterfall project will provide status updates to the stakeholders along the way.  Imagine your stakeholder wearing one of those in-helmet headsets that NFL quarter backs use.  We publish effective status reports to let the stakeholder know what’s going on.  Like the falling barrel, however, a waterfall project has inertia.  The project, barring significant outside influence, will keep going in the direction it started.  Projects have change control boards to manage that change, but emotionally, I find that a formal change-approval process tends to inhibit change, rather than encourage it.  That barrel will keep falling.

Some project teams will try and do very heavyweight documentation to maximize the likelihood that the project will end up where it should.  The problem is, this heavyweight documentation only improves the chances that the project will end up where we used to think it should go.  It does not help us change the trajectory of the project as new insights are gained.  Just as responding to those changes provides a competitive advantage, ignoring those changes exposes a competitive weakness.  Someone will come along and exploit your weakness if you don’t respond to change.

From these dynamics, we can conclude that “big up-front requirements”, while better than “no requirements,” are actually a waste of energy and time, relative to an ongoing adaptation to change.  That adaptation to change, however, should also be documented.  It needs to be documented for two reasons – to manage expectations of stakeholders, and to keep the implementation team focused on creating the most valuable capabilities in your product.  As you get smarter about what is valuable, you need to apply that knowledge and change the path of the project.

This is where communication becomes critical with stakeholders too.  Especially the old-school barrel-riders.  They are used to being in the barrel, maybe with an occasional “looking good – you’re still falling straight down” message along the way.  They are not used to hearing “we’ve decided that gliding over the rocks is more valuable than falling – please extend your wings now” messages.  The shocked “what wings?!” response is what they immediately think.

Agile Expectations

An agile project will avoid the big up-front requirements, and gather just enough requirements for right now.  What your stakeholder might hear is “agile is magic – we don’t need detailed requirements.”  The real message is “agile is better – we don’t need details about the requirements yet.  But we will need them later.”

A given team needs the same amount of specificity in requirements to achieve the same result, regardless of project approach.  One team I worked with would not set the tab-order in a form to go from top to bottom if you didn’t specify that.  It simply didn’t occur to them.  Another team was very effective with “gather the following data in a form…” – and they would layout the form, manage tab order, add reasonable field validation, assure proper markup and support for screen readers (for visually impaired users), and implement a candidate error-message/feedback design for users.  The first team would never succeed without details, the second team would view those details as wasted effort by me to write them, and by them to read them.

I think most of the initial creators, proponents, and early adopters of agile processes are members of the second camp.  They designed agile to not require detailed documents, but to allow it when needed – because they acknowledged that some people need the details.  They were reacting to heavyweight processes that were designed to work for “any team” at the cost of slowing down the best teams.  Kent Beck told me once that when people tell him about the importance of testing, his response is “so, lack of testing burned you before?”  When people stressed the importance of gathering requirements, his response was “you’ve been burned by a disconnect with stakeholders.”

Enough is the operative word here.  You have to document enough.  You have to communicate enough.  You have to set expectations with your stakeholders that things will change.  And as those things change, you have to stay joined at the hip with your stakeholders to validate those changes.

While your team is responding to changes (based on feedback from stakeholders and the market and competition and implementation discoveries) with new plans, you have to feed that information back to the stakeholders.  It is a two-way communication.  And it needs to be a continual communication.

I joined a six month project once in the last month of the project.  Here’s a sanitized sequence of events describing what happened.

1. Initial vision for the project was defined and requirements defined and tied to goals and value.
2. The estimates came back and said “no way it will happen before the business-imposed deadline.”
3. The team said “let’s be agile” and chose a component of the vision to do first.  That component could be completed by the deadline, and stakeholder expectations were set – (a) do this visible thing first, “meet” the deadline, and then (b) regroup, re-prioritize, and then do the next thing next.
4. The team started developing the solution, and worked for 5 months.  After 5 months, someone concluded “we won’t finish by the deadline.”  A couple weeks later, the estimate was that the team still had between 1/3 and 1/2 of the work remaining to complete the first component of the vision.
5. In presumably unrelated events, all but 2 of the internal stakeholders left the company.  Literally.
6. When the CIO and president of the company engaged the project team, they weren’t thinking “we have an over-run on the first component of our vision” – they were thinking “not only is it not done, but what you’re trying to do is not the right thing.”
7. Project was stopped one week after the original deadline for the first component (which was not completed).

It may be that this was unavoidable, but one thing was clear – the “build the first thing first” expectation was not communicated effectively.  It didn’t help that the team did not track velocity, so it wasn’t until the end of the project when the “you’re going to hit the rocks” message was first heard by the stakeholder in the barrel.  Way too late to affect change.  For this and other reasons, I contend that the project was not agile.  It was a Chevrolet with a Ferrari sticker on it.

We can ignore the labeling of the process and focus on the lack of ongoing expectation management as the ultimate doom of the project.

Evolving Expectations

Patrick Masi had a couple great comments on our Simple Agile Model article.  Patrick pointed out a problem with simple documentation artifacts like this.  The early “here’s all we need right now” artifacts were insufficient to capture the full extent of what the stakeholders needed.  I’m not sure exactly where things broke down, but Patrick implied that the ongoing clarification with stakeholders was not happening.

This is a completely different manifestation, I suspect, of the exact same problem described above.  Thinking about Patrick’s comments is what got me heading down the whole “barrel rider” path in the first place.

I don’t believe I’ve worked with any stakeholders who would say “yes, ignore what we learned this year – it is more important to build last year’s product.”  I’ve definitely worked with stakeholders who did not have time to commit to the support of an agile project.  The ironic thing about agile projects is that they may do more requirements work through the course of the project than non-agile projects.  An agile project will respond to change.  That means some work is re-done.  It also means that some valueless work is avoided.  You can’t categorically say which influence is larger.

One possible source of the pain Patrick’s team felt is mis-set expectations of what is being delivered when.  Imagine developing a checkout-process for an eCommerce website.  The complete checkout process is too large for a single sprint, so you break it down into valuable atomic deliverables for each sprint:

1. Registered customers can buy any products, using previously saved billing / shipping info.
2. Individual product and “per order” discounting works and customers can use gift cards to pay for all or part of the order.
3. Anonymous customers can place orders (without accounts) and registered customers can modify billing and shipping information.
4. Orders can be placed as gifts (with gift receipts and wrapping services), and online call-center reps can interact with customers real-time to help with the process.

This is a nuanced message – basic checkout in sprint 1, with increasing capabilities in each sprint, until “complete checkout” is done in sprint 4.  That is a reasonable plan, but requires a more detailed conversation with stakeholders so that they know what is coming and when.  You don’t want someone freaking out after the 3rd sprint when they can’t place gift orders.

Another possibility is that the elicitation process before the third sprint (re-visiting checkout again with the same stakeholder) did not tease out that anonymous users must provide an email address (for order confirmation email, and to secretly create a “shadow account” for that customer).  All of those details need to be gathered, and it can be harder to spread out the conversation over multiple sprints than it is to have it all up front.  This is just incomplete discovery, but with delayed (and recurring) impacts.

In User Stories Applied, Mike Cohn stresses that the brevity of user stories is intentionally designed to facilitate (and I would add “dependent upon”) conversation.  I find it to be both a strength and a weakness of user stories.  It is strong because you can cover a lot of ground quickly (breadth) and capture a number of stories, much like the list above.  It is weak because the requirements documentation does not stand on its own – it requires conversation to fill in the details.  I’ve had some success using the “Verify that…” user acceptance tests as the method of documenting those details (depth), in conjunction with the brief, easily consumable stories.

You can write the stories quickly to decompose and schedule across sprints (revisiting the schedule as things change), and then write the verify statements as UAT for each sprint as it occurs.

Another benefit of the UAT is that it is explicit and cuts through the walls of the barrel for a stakeholder who “doesn’t get agile” as Patrick puts it.  “Here’s our lightweight multi-sprint plan – now lets define the specific acceptance criteria you need” is a pretty effective conversation.

Conclusion

You have to stay closely connected to your stakeholders – not just for messaging, managing, and changing the big-picture direction of the project, but also to drill down into the details at the last practical moment.

A picture is worth a thousand words.  Agile values working software over comprehensive documentation, and it values customer collaboration over contract negotiation.  With that in mind, how much is a picture of a model worth?  Check out a simple example, how it helped, and what we didn’t do.

A Complex Conversation

I was working with a client on an eCommerce website, where one of the things that was important to the client was having and managing an affiliate network that refers visitors (and ultimately customers) to the website. The conversations around exactly what the stakeholders of the eCommerce site wanted were pretty convoluted, and different stakeholders described the “requirements” differently.

Affiliate Network Background

An affiliate network can work in the following way:

1. When someone visits a website, and does so by directly clicking on a link on an affiliate partner’s page, the website is able to identify the affiliate partner who “sent” the visitor to the website.
2. The website keeps track of who “sent” the visitor.
3. If the visitor becomes a customer, the affiliate partner who sent the visitor is compensated.  One way to compensate that affiliate partner is by giving them a percentage of the revenue that the customer generates for the website.

This can be a lucrative model for both the eCommerce site and the affiliate partner.  The partner gets paid for funneling traffic to the eCommerce site, but not necessarily doing any other work (beyond what it takes to encourage people to go to the eCommerce site).  The eCommerce site gets increased traffic, at a manageable cost – proportional to the revenue generated by the incremental visitors (who would probably not otherwise visit the site).

Each business gets to focus on its core competency (sending traffic, for the affiliate partner; converting that traffic into revenue, for the eCommerce site).  The eCommerce site invests the majority of the time and money (probably orders of magnitude more investment), and the affiliate partner shoulders all of the risk, but can do this for almost no cost (if they want), in exchange for an uncertain revenue stream.  This blog is currently trying out an affiliate relationship with Carbonite – because I love the product (and therefore think people who visit Tyner Blain will too), and because the revenue generated, if any, will help defray the costs of writing and maintaining the blog.

Specific Complexity of an Affiliate Model

The complexity of this “simple” model becomes apparent when you ask a few clarifying questions.

• Will there be multiple affiliate partners?  (Yes)
• If someone is referred by multiple affiliate partners (on separate occasions), who gets credit? (The last affiliate partner who sends the customer to the site)
• Does the visitor have to purchase during the visit that was made from the affiliate partner’s site? (No)
• Is there an expiration date, after which an affiliate will not get credit for customer purchases?  (Yes, “N” days).  [Note: I am obscuring the actual value for this article, but N is a real number.]
• If a customer who was referred by an affiliate makes multiple purchases, for how many of them is the affiliate partner credited?  (One)

Asking these questions in different ways generated some different, and potentially conflicting answers.  The list above is the “after we put it all together” answer.

A Simple Model

We solved this problem by grabbing the immediately available stakeholders and pulling them into an office with a whiteboard for about 3 minutes.  [Ed: Our first article about using object-oriented analysis as part of requirements gathering is from three[!] years ago, this is not a new idea, and wasn’t then, either.]  I drew the following state transition diagram on the whiteboard, using an active listening technique, to confirm that I had consolidated the inputs into the right set of business requirements.  Documenting business rules with a state transition diagram was very effective at highlighting them.

Most of the explanations from stakeholders were in more of a use-case format, but a state-transition diagram was more effective at validating the rules and requirements in this situation.

The diagram above uses the following approach to describing the problem:

• Some customers are considered to be “actively referred” by an affiliate partner – and when that is true, an affiliate receives compensation for the order placed by the customer.  Other customers are not considered to be “actively referred” and no compensation is due to the affiliate partner.
• Customers can be “temporarily actively referred” and events modify that state.

What the diagram shows, given that context is the following business rules:

• When a customer is referred to the site, the “to be compensated” affiliate partner is identified, and associated with the customer.
• When the same customer is referred to the site by a different affiliate partner, the new affiliate replaces the old one.
• If “N” days pass after a customer was referred by an affiliate partner, that affiliation expires, and the affiliate partner is not compensated for future purchases.
• An affiliate partner is only compensated for the first purchase made by the referred customer.

The stakeholders that were present confirmed that this perfectly represents their business requirements.  Even cooler – a couple days later, the business person most-directly-responsible for implementing the programs came by, looked at the whiteboard, and signed her name on it to record her approval.  We also have a camera-phone snapshot of that.

What We Didn’t Do

I could have titled this article Mini-Model and Requirements, but Agile seemed more appropriate, because we didn’t go over the top with it (and it is a rapid-development, incremental project).  The diagram above also represents the minimum deployable version of the affiliate program for a given release.

We stopped short of creating the following diagram:

This diagram is more of a “classic” artifact that you would see in a BUFR (big, up-front requirements) project.  Our team collaborates regularly, and the affiliate program details were now relevant/timely.  We had the conversations, drew the diagram, confirmed (in about 10 minutes), took a picture, and shared it with the rest of the team.  There would have been marginal incremental value in making a pretty version of the diagram, so we didn’t do it.  Our goal is working software, not comprehensive documentation.

Conclusion

Just do what you need to do, then move on.  For our team, clarifying the intent was important.  Creating a formal, pretty picture added no extra value.  So we didn’t do it.

It’s fitting that I’m writing this from the exit row of an MD-80 this evening on the way home from a customer visit.  I almost didn’t get the exit row, but I did.  I tried for an upgrade to first class, but I was 15th in line – it was a busy flight with a lot of high-status frequent fliers ahead of me.  But I’m thrilled to be in the exit row, with the lap-room available to type up these tips that will help you travel.

You can love to travel or hate to travel.  Either way, there are a lot of little things you can do that make travel easier.  At first, many of these seem like small inconveniences, but over time, you can adopt many of them as habits.  And the rewards add up – every little thing you do that makes it easier to be on the road makes travel better (or at least less onerous).  This is my first trip in almost a year – I’ve been doing all of my traveling for 2008 virtually – with GotoMeeting, WebEx and DimDim.  I’ll be back on the road again, so I’m dusting off what I remember from my road-warrior days, to make it easier now.

Frequent Flier Programs
When I first started traveling, I was on the road every week.  My travel agent suggested that I sign up for every frequent flier program, and every hotel rewards program.  So I did.  Over time, I found that focusing on a single airline provides the best payback – because you earn status that lets you

• Go through shorter security lines at the airport.
• Get on the plane first and grab the luggage space you need in the overhead compartment.
• Reserve the “premium” seats – like exit row.
• Get “bonus” mileage credit for the travel that you do – leading to free flights or upgrades later.

Status is a key component of the loyalty/stickiness programs that airlines run.  They need a way to differentiate their “fly from A to B” product from everyone else’s “fly from A to B” products.  As you fly more and more in a single calendar year, you increase in status from ‘regular passenger’ to ‘acknowledged passenger’ to ‘appreciated passenger’ to ‘of course we can, Mr. Sehlhorst.”  On American, that path goes from ‘Aadvantage member’ to gold, then platinum, then executive platinum.  Once you earn a particular status in a given year, you retain that status for that year and the following year.  Each year, your status, if not re-earned, drops one level.  So if you earn platinum status in 2008, you keep it for 2009, then drop to gold status for 2010, and back down to ‘regular passenger’ in 2011.

The right airline for you may be different than it is for me.  The airlines that fly into your “home” airport may be different than mine.  And the flight schedules from your home airport to wherever you tend to go may be more or less convenient on one airline or another.  Personally, I fly American Airlines whenever I can.  I know and like the planes, I like the “by price and schedule” implementation for booking flights online, and I especially like the service I’ve received as a platinum status flier over the years.  Apparently the customer service is even better for people who reach executive platinum status, but thankfully, I don’t have first hand knowledge.  Always a bridesmaid, never a bride.

American also has a program where once you reach a million miles (traveled or otherwise earned), you become “gold for life” – so even when you travel infrequently, you still have some status/perqs.  When you reach 2 million miles, you become platinum for life.  As someone who’s halfway between the two, who has enjoyed the benefits of platinum off and on (mostly on) for the last decade, I find that carrot to be pretty compelling.  Traveling with your family at the holidays is SO much easier when you have status, if something goes wrong one year (and it has).

I’ll add a connection, or wake up an hour early or pay a few (but not a lot of) extra dollars to fly American on any given trip.  Knowing I’m a little closer makes the trip better for me.  For you, picking the best schedule, or the cheapest flight, might be better.

My most valuable tip: When someone else makes a reservation for you, you usually get bad seats.  First – make sure your frequent flier number is associated with the reservation.  Second – fix your seats.  And if the flight is really full, check again 96 hours and 48 hours and 4 hours before your flight, a better seat may have opened up.  That’s how I made it to the exit row a few hours before my flight tonight.  I was in a middle seat on an oversold flight.

Frequent Sleeper Programs
The hotel chains have the same game going as the airlines.  “Stay at our hotels, and earn status and points.”  I probably have a dozen memberships, and they vary in quality.  Rather than go into details, I’ll say that I feel that the Starwood chain (Sheraton, Westin, W, St. Regis) has the best program.  As a Starwood member, I have never been prevented from reserving a room using “points” instead of cash (aka a free room).  When I was a platinum Starwood member, the complimentary room upgrades were always a very nice surprise, and happened frequently.  The only downside is that I can’t always find a Starwood property where I’m travelling.  If I can’t, I lean towards Marriott and Hilton as distant second place competitors.

Frequent Driver Programs
Is there anything other than Hertz?  I can always find a good rate on the cars I rent, usually get a one or two class upgrade on the car, and don’t have to wait in line – Hertz gold is free, and you get “status” from them for your tenth rental in a given year.  Your 40th rental in a year gets you “crazy status.”

Did I mention that I don’t wait in line to pick up (or drop off) the car?  Maybe every rental company has that service these days, but I’m blissfully unaware.

Frequent Traveler Intelligence

Bar none, the best place to learn everything about being a frequent traveler, and to get the best intelligence and insights about all of the programs is flyertalk.com.  Check out the “miles buzz” forums – there’s one for each major airline, hotel, and car rental chain.  Once you get good at maximizing the rewards you get from the travel you have to do, you get exposed to the extreme sports version of frequent travel – the mileage run.  People actually figure out the cheapest ways to fly 16 segments from Boston to Tokyo and back over the weekend, so they can earn that next level of status for the year.  It is an insane world.  The next time I’m on the edge of executive platinum, I might just try it.  I’ve let that brass ring slip through my fingers year after year.

You also learn really obscure stuff – like the sequence in which meals are passed out in first class (it varies by flight direction) – so if you are really craving the glazed chicken, and hate the idea of veggie pizza, pick the right seat.

Another very handy site is seatguru.com.  You’re trying to pick your seat for a flight on an MD-80?  Where do you want to sit?  Seatguru shows you a map of most planes, as they are configured by the different airlines.  On that map, you see if a seat has shortened or extended legroom (it varies within the planes), has a power outlet for your electronics, or if anything else is especially good or bad about a particular seat.  Desperately need power on that late night flight home so you can write your blog post?  Better make sure your seat has a power port.

Weather.com has proved to be really useful too.  Every time I travel to a new city, I bookmark the weather.com page for that city in my browser.  Over time, the list has become pretty long, but with all the banner ads and animation that clutter the site, I love that I only have to click once to find out how to pack.  There are probably some much better desktop widgets that you can use to find out the weather without ever going to the site – but what was around 10 years ago was never compelling.  Add a comment or shoot me an email if you have a favorite weather-checking solution.

You can also check flight status online or have your airline send you a text message (or voicemail) if there are changes to your flight schedule.  Those can be pretty handy things.  You can even request an upgrade to first class over the phone while you’re driving to the airport if you want to try for an “impulse upgrade” at the last minute.

Your Computer on the Road
Over the last couple of years, I’ve increased my use of software as a service for my computing needs.  It turns out that this provides some interesting benefits when you’re on the road.  Being able to backup (and more importantly, recover) your work on the road used to be almost impossible.  You had to carry two laptops (or one laptop and two hard drives).  But if your bag was stolen or lost, you were in trouble.

My “solution” is a work in progress, as I try out different services and different behaviors.  Here are some things I do, and how I get value from them.

Taking Notes

I use Evernote instead of OneNote.  I got hooked on OneNote a couple years ago – for me, the compelling feature was good search and an intuitive organizational metaphor.  Evernote does that too – with a slightly less polished UI.  But Evernote allows you to syncronize your notes across machines.  So I can access the tool on my client-provided laptop, my personal laptop, and my desktop.  And they stay synchronized.  If I’m on the road, and my laptop dies, I can access my notes from any machine through a web browser.  After a brainstorming session, I can take a picture of the whiteboard and stick it in a note (and Evernote will index and search the text within the photo too!), and I don’t risk losing the insights from that meeting.  Oh Evernote has an iPhone client app too.  That might be the killer app for some of you.

Disaster Recovery

My off-site backup is done with Carbonite.  I pay $50/year, for unlimited off-site disaster recovery – currently at 184GB.  Using Carbonite is dead simple – I installed it, and then any directory I wanted to back up (work documents, family photos, whatever), I just right clicked and added it to Carbonite’s list of things to back up.  Every file in that directory (and every directory underneath it gets backed up).  Add more files to that directory, and they automatically get added to Carbonite’s backup.  I’m in the middle of re-ripping our CD collection for the third time now (after hard drive failures over the years).  This will be both the third and the last time.  This takes care of my primary computer at home, and happens all the time, in the background.  For $50 per year, I have a ‘never think about it’ solution – most importantly protecting our family album, personal records, and work files.  It is also highly secure (the data is encrypted before being transmitted, and is stored in encrypted format).
On-the-road disaster recovery

I am currently using subversion (and TortoiseSVN) to make archival backups of all the files I create for work while I’m on the road.  This may be too geeky for most people, but it is free for me (since I already pay for the server to host tynerblain.com).  If I finish a presentation late at night, then someone accidentally drops a piano (or a fog lifter*) on my laptop the next morning, I can still wow the client.  I have to explicitly backup each file I want to save.  It looks like you can subscribe to a hosted subversion service for $50 (and up) per year, if you don’t want to install it (for free) on your own server (various prices).

*A fog lifter is a quadruple-espresso that friends of mine used to drink to start the day (or extend the night) when they worked on-site at a client in Cupertino years ago.

Back-From-The-Road Backups

I have used Scooter Software’s Beyond Compare tool for years.  It is a file-comparison tool that is great for what it does.  When I was programming a lot, I got addicted to it.  It is also extremely good at copying files and synchronizing directories between computers.  And it can be scripted, so you can automate processes.  I use Beyond Compare to push updates from my laptop to my desktop when I return from a trip.  If subversion is a scalpel for refined work, this is my backup chainsaw, where I just keep a current copy of an entire directory structure backed up (weekly-ish) to the desktop.  And that structure is then backed up off-site by Carbonite.  This helps a bunch when moving to a new laptop, replacing a failed hard drive, or just upgrading your hardware.  I have used SyncToy too, which is also good, but seems to take a lot longer when dealing with very large sets of files.

After files are synced to my desktop (backup  #1), Carbonite backs them up offsite automatically (backup #2).  And for those urgent files while on the road, subversion is there too (backup #3).  On-site, off-site, controlled-by-me and recovery-as-a-service.  Overkill?  Maybe.

Email

I do a lot of email.  I have personal email accounts (Google, Yahoo, and OtherInbox), I have client email accounts (MS Exchange, Google Apps, and Lotus Notes, so far), and of course Tyner Blain work email (Google Apps).  I’ve used both Thunderbird and Outlook as IMAP clients to (1) give me the ability to read and write email while offline, and (2) provide an “onsite backup” of my data that otherwise lives only in the cloud.  There’s no clear winner for me yet on the email front.  Probably Thunderbird, but frankly, I don’t spend a lot of energy worrying about “backing up in case GMail goes down.”  And when I am away from an internet connection, it makes for a nice break from email.  If I absolutely have to draft an email, it is probably for a client, so I’ll use their solution (usually Outlook).

Blogs

I know most people like Google Reader.  Fine.  Keep using it.  I’ve become impressed with Omea Reader as an offline feed reader.  I like having access to the blogs I follow, even when offline.  It allows me to “surf the web” when on a plane.  When I have access online, I start with the product management river of news.  Offline, I can manage those subscriptions as a sub-folder in Omea.

Entertainment

I keep a 2.5″ external hard drive in my laptop bag.  It is the drive I had left-over when I upgraded my laptop drive.  I stuck it in a $12 case (hooray Frye’s!), reformatted it, and put a bunch of mp3 files (ripped from my home CD collection, sync’ed with Beyond Compare) on it, and installed winamp.  Sometimes, you just need some Velvet Revolver, Vivaldi, Erin Ivey, or Diana Krall while you work.  For travel, I have some cheap Sony earbuds for regular use, and eShure noise-isolating headphones for the flight.  Both are easy to slip in a pocket or laptop bag.

Edutainment

I have become truly addicted to my iPod shuffle.  But I never use it for music – I never shuffle.  I use it for listening to podcasts and audio books.  On the way out on this trip, I listened to the Tipping Point by Malcolm Gladwell.  On the way home, a Rymasoft webinar with Luke Hohmann, president of Enthiosys.  I also would rather listen to This Week in Tech (or whatever) than listen to whatever happens to be on the work-out-room tv when I’m slogging it out on the treadmill.  Also – bring a book.  For this trip, User Stories Applied, by Mike Cohn.  Sometimes, you just need the feel of a book.  Also – if you fall asleep listening to a book, you’ll never find your place again.  Much easier with a book.

That’s way too much.  The first flight was too long, I guess.  Hope some of these ideas help you make travel a little less painful or a little more enjoyable.  Any tips you want to share with folks?  Add them below.

Business rules are often hidden in processes as hidden decisions.  Once you discover that hidden decision, how do you communicate the impact of exposing and managing the decision?

Hidden Decision

In our previous article on hidden business rules and enterprise decision management, we looked at a process that had a hidden decision.

First, take a look at the process with the decision still hidden:

Here’s the process (with the decision exposed) from that article:

The decision that was hidden was an implicit decision – “Pick One?” – for which the answer was always “No.”  After making this discovery, and communicating with your team, you then have to decide if you are going to make the decision explicit.  Making the decision explicit will involve defining the business rules for how to make the decision, and (if done in software) implementing the decision, or the ability for a person to make the decision.

Impact of a Decision

The diagrams above allude to the fact that there is money to be made in the process, in the “Continue Automated Process” step.  We need to provide a better understanding of how / when money is made.  A slight expansion of the process flow above (replacing the “Continue Automated Process” with a couple steps, looks like the following:

[click for larger version]

The last step introduces a real-world decision: “Sell products?” and only when the answer is yes does the process “Earn Revenue.”

If you’re analytically minded, you can apply percentages to each branch of each decision, and add everything up to figure out an answer.  That might be reasonable for a simple example like this one, but it can become too complex with a more complicated process.

There’s an easier way.  And since the goal is to communicate the impact to someone, you want an easier way.

Truth Tables and Decisions

A truth tables is a tried and true artifact for describing combined sets of decisions.  You can use it effectively to extract information from a decision-heavy process diagram.  Consider the following application of a truth table to the process above:

[larger version]

Each of the decisions in the process flow has a column.  Each row represents a unique path through the flow.  Each cell contains the result of the decision, for that path.  Note that when a path does not involve a decision, there is no value in the cell.

That provides a comprehensive view of the process, which you could build upon.  However, in this case, you are focusing on the impact of the hidden decision (“Pick One”).  The following paths, from the truth table, involve that decision:

[larger version]

Ignoring the other paths, and re-organizing, you find the following:

[larger version]

50% of the time, when “Many” results are found in the first decision in the process, if you pick one of the results, you will earn revenue.

[larger version]

When you do not pick one, 20% of the time, the customer (or user) abandons the process.  For the users that do not abandon the process, you earn revenue 50% of the time.  Taking both into account, you earn revenue only 40% of the time.

Adding Up the Impacts

When there are “Many” results from search, you can improve the performance of this part of your process by 20% – specifically, you increase revenue by 20%.  But only if you always “Pick One” of the many results. You can extend this analysis to determine the percentage of None/One/Many outputs from the search at the start of the process, and determine an overall impact on the process.  If search returned many results 10% of the time, you can increase revenue (overall) by 1% by always picking one of those results.  That gives you the business justification to calculate ROI on exposing the hidden decision.

The end result is that you have a simple way to communicate the impacts (truth table) in the language of stakeholders (ROI).

An effective status report is one that

• Instantly conveys the state of the project.
• Creates a minimum of overhead for the project team.
• Gets you help when you need it, and latitude when you don’t.
• Is fun / energizing to the author and the readers.

An effective status report is not a myth, it is actually easy to achieve.

Goals of a Status Report

You do not create a status report because someone told you to create them.  You create a status report only when it benefits the project.  There are three effective uses of a status report:

1. Get help (escalating) when you need help.
2. Keep stakeholders in the loop so there are no surprises.
3. Get visibility for the accomplishments of the people on your team.

Problems of a Status Report

There are also potential downsides of creating status reports.  This doesn’t mean you should avoid creating a status report.  It means you should avoid status report mistakes.

1. A bad status report takes a lot of energy (and time) to write, making it expensive.
2. A bad status report is difficult to read, causing it to fail to communicate.
3. A bad status report covers up problems or cries “Wolf!” when things are under control.

Elements of an Effective Status Report

The following is one example of an effective status report format.  Other formats can work.  This one does.  We’ve been using it for months on multiple projects, with great success.  On one of our projects, the first status report in this format was forwarded around by the project sponsor for people to “check this out!”  Ever hear of that happening to one of your status reports before?  In a good way?

There are five components in this status report format.

1. The scannable forecast.
2. Last week’s accomplishments.
3. This week’s planned accomplishments.
4. Issues and resolutions.
5. The legend.

The Legend

Normally, we run through a list in order.  In this case, we will show the last section first.  The legend explains how to read the first section, the scannable forecast.

You can define any number of different statuses for a project.  “Red, Yellow, Green” is the most common.  A couple years ago, we proposed this metaphor for status reporting:

A great way to do this is with a stoplight metaphor (at least in the US, where green = go, yellow = caution, red = stop). We can provide a little color in our reports to make the status details and rollup easy to scan. When someone is the audience of a status report, its because the reader needs to know what is going on, but isn’t involved – and likely is reading status reports from other teams. We need to present a document that gives a quick visual that guides the reader to pay attention to the most critical elements.

• Red. Immediate action (by the reader) is required to fix this.
• Yellow. We’re at risk of failing to meet expectations. There’s a plan in place, but we thought you should know. Want to know more?
• Green. Meeting or exceeding the plan. No need to spend cycles on this one.

[Update 28 Apr 2007: We have a much improved metaphor for tracking project status - weather forecasting.]

It works, but it isn’t great.  You’ve all seen it, because it is adequate.  However, using red, yellow, and green to provide a scannable status can be confusing – even if your readers aren’t colorblind.  Does red mean the project is delayed?  Yellow usually means a project is at risk.  But is it “at risk, help is needed” or “at risk, FYI, help is not needed.”  That’s part of why we recommended the weather forecasting metaphor.  Thanks again to Johanna Rothman for originally sharing the idea.

The Scannable Forecast

When you look at the above, even without knowing any details  you know:

1. The project is in worse shape this week than it was last week.
2. The project will get worse before it gets better.
3. The team has it under control, today, but might need help next week.

Last Week’s Accomplishments

The bulleted list is extremely effective for scannable details.  The secret – use three to five bullets.  More bullets means you’re sharing too much, and fewer than three is not enough.  You’re reporting to a project sponsor who has placed trust in you to manage the details.  Your sponsor, when things are sunny may not even read the details, just relying on you to say “everything is great.”  The only time that you need to share more details is when things are stormy.  And those details (1) will come up in the issues section, and (2) will come up in conversation.

When someone on your team does something noteworthy, dedicate one of your bullets to that accomplishment.  If you have a dozen of these, then refine your definition of noteworthy.  You should already be providing feedback to your team about their work.  Noteworthy accomplishments should be broadcast up the chain.  Its a reward for their hard work.  Don’t under-report, and don’t over-report.  The people who consistently do great things will begin to get a positive reputation where it counts.  As a bonus, you will get acknowledgment for being a good manager.

This Week’s Planned Accomplishments

This is what you intend to do in the next week.  When your project sponsor does want to get a little more insight, perhaps to make sure that she believes that you will resolve things, she will read these details.  Again – a three to five item bulleted list is appropriate.

Issues And Resolutions

You report issues when you are (or anticipate being) cloudy or stormy.  You don’t waste your sponsor’s time on trivial issues that you can resolve on your own.  These are issues that either definitely require escalation, or may require escalation.  Again, you’re working a three to five item list.  On your project, you will potentially manage ten times as many risks, and you could track them in a spreadsheet, etc.  Those are the issues you are working.  These are the issues you need help to resolve.  And only the issues you need help to resolve.

Note that this isn’t just an issues section – it is issues and resolutions.  When you inform a stakeholder that you need help with a problem, the first thing you need to do is propose a solution.  Imagine the following exchange:

“I need help” – “What do you need?” – “I need you to ….”

Much better than

“I need help” – “What do you need?” – “I don’t know.  I need help determining what I need.” – “I know what you need, you need help updating your resume.”

For every issue, propose a solution.

The issue section is also not meant to be a standalone document.  Here’s another bad exchange:

“I need help” – a couple days go by – “I solved your problem for you.  And I’m replacing you with someone I can rely on.”

Your project sponsor shouldn’t have to ask what you need her to do.  She should, however, want to know why you think the proposed solution is best – and you should talk to her about it, not present a rationale within your status report.

Practical Experience

I’ve created many status reports using this format.  They take anywhere from 15 minutes to 45 minutes, almost always under 30 minutes.  When they did take any significant time, almost all of that time was spent in thinking about the content to report in the “Planned Accomplishments” section.  And that is not time that I spent writing a status report – it is time I spent planning, on those occasions where I procrastinated in my planning, and the writing of the status report triggered a brief planning exercise.

Brevity in a report goes a long way.  As does regular face-to-face (or at least phone-to-phone) conversation.  A status report alone better not be the only way you communicate.  It should be a light-weight artifact that (1) starts the important conversations, (2) preempts the time-wasting conversations, and (3) provides an archive that you can review later, to see the full arc of the project, gain insights, and run your next project even more effectively.

Having trouble working through complex concepts?  Struggling to get a “simple” message across?  As human beings, we are all pre-wired to absorb visual communication.  You should take advantage of that to give yourself an edge when it comes to communicating.

Thinking in Pictures

Guy Kawasaki did an interview last week with Dan Roam, author of The Back of the Napkin: Solving Problems and Selling Ideas with Pictures.  There are eleven good questions with detailed answers, so it is definitely worth a read.

Whenever we hear a pitch or evaluate an idea, we go back to first principles and try and understand why something might work.  If we believe the explanation of why something might work, we’re much more open to the possibility that it will work.  Here’s part of Dan’s answer to Guy’s question about how and why using visuals to communicate can be effective.

Recent breakthroughs in vision science have indicated that there are multiple “vision pathways” along which the signals from our eyes travel into and through our brains. Each pathway keys off different visual cues in the environment–one pathway looking to identify the objects around us, another understanding where they are, another determining how many there are, another watching for changes over time, etc. This process takes place in parallel, breaking the entire visual world down into discrete elements that we initially process independently, and then only later “see” in our mind’s eye as a whole.

Dan Roam, interviewed by Guy Kawasaki

The basic idea is that we can perceive solutions to abstract and complex problems visually.  Visualization becomes a compelling vehicle for communication too.

Visceral Examples

Instead of writing a long string of words to describe the power of communicating visually, we’ll give you a couple examples.

One of Guy’s ventures is a company called Alltop, the goal of which is to find the valuable search results and present them to you.  Alltop is acknowledging a weakness in the search results created by algorithms – whatever the ranking mechanism, it is imperfect.  Alltop’s goal is to eliminate the pain of wading through useless search results to find the “nuggets” of useful results.  Does that explain the idea sufficiently?  What if you looked at this picture, from Guy’s recent blog article, showing a drawing by Dan of the concept described in this paragraph.

There’s a company called Slydial that allows you to make calls directly to someone’s voicemail.  A few minutes of poking around their website will give you an idea of what they do.  If you also read the FAQ and watch the videos, you can infer how it works too.  Or you can just look at the following drawing:

[click for larger version] * Note – depending on your age, the weird boxes are either obviously reel-to-reel recorders, or they are apparently happy robots that are excited to record your message for you.

Instead of calling someone in hopes of leaving them a message (because you don’t want to talk to them), you call Slydial, tell them the number you want to reach, and record a message.  Slydial then calls the voicemail of the person and replays your message directly into their voicemail.  In some cases, the person’s cell phone will even show a “missed call” from your number.

Whiteboards Rock

I’ve been heard to utter the phrase “I can’t think without a whiteboard.”  Whiteboards make for great visualization tools.  In my presentation at ProductCamp Austin, after a quick sojurn through my meager slide deck, we switched to the whiteboard.  With me at the whiteboard, the entire room was able to create an example Ishikawa diagram, first exploring an example problem with a concept map, and then building the associated ishikawa diagram.  The combination of collaborative teaching and visual expression and learning was very effective.

There’s an entire industry, now, built around electronic whiteboards.  Ten years ago, I was at a client using a copyboard – a whiteboard that would rotate the screen (like those old cloth-reel towels in restrooms) and a scanner built into the side of the whiteboard would copy what you had drawn, printing out a black and white copy of your diagram on thermal paper (the kind that used to be in fax machines, and that curls up after printing).  Five years ago, I was able to use an electronic whiteboard that detected the location of (and color of) the markers you were using.  It would detect when you were pressing down to write, triangulate the position of the pen, and create a digital copy on your connected computer.  Now those devices can be used interactively too – you can use a projector, pointed at the whiteboard, share the drawing real-time with remote viewers, and probably any number of other uses.

This matters, because you want a way to capture and share the drawings you create.  If you manage your information and communication well, it’s like slingbox + tivo for whiteboards.  View them any time, anywhere.  If you’re a product manager or business analyst, this gives you an easy way to embed drawings and diagrams within the traditional requirements artifacts.  Electronic copies of the drawings can be incorporated where they are needed most – leveraging context and providing clarity for your readers.  They dramatically help you when writing for an audience that does not have the context you have when creating the document.

Data Visualization

This is yet another incredibly valuable area of study – visual presentation of data.  Networks, connections, values, trends, everything can be visualized.  Check out this article from Smashing Magazine if you want to open pandora’s box into the current cutting edge(s) of data visualization.  If you’re a data-geek or a visualization-geek, my apologies.  This article will suck you into a black hole of great visualization ideas from which you may never recover.

Requirements Visualization

The only reason for documenting requirements is to communicate those requirements.  You can do it with text, or you can do it with analytically-saturated text, combined with gripping and clarifying visuals.  Make sure you have the following visualization techniques in your communication toolbox.

• Structured Requirements (or including interaction design) – this simple approach (and diagram) puts everything into perspective, from business goals to detailed specifications and to test plans and implementation.
• 
• Ishikawa Diagrams – demonstrate the cause-and-effect relationships that articulate why something is important to your stakeholders.
• 
• Class Diagrams – an explicit and expressive way to describe the business domain, providing context for your requirements.
• 
• Process Flows – there are many ways to do describe processes, from simple flow charts and sequence diagrams to BPMN process models (24-article tutorial & free visio template).
• and and
• Use Case Diagrams – no, not the UML use case diagrams, they are next to useless.  These are simple sketches that make a complex use case crystal clear.
• 
• State Transition Charts – show how objects can change their state over time (an order is placed, then paid, then filled or cancelled)
• 

What are your favorites (and why)?

The Cause and Effect diagram is also known as a fish bone diagram, because it resembles the skeleton of a fish. Using a cause and effect diagram can be the most effective way to define the problems that you intend to solve with your product. Get your stakeholders engaged in your program with this compelling visual!

Getting To The Root Of The Problem

In our recent article about writing good problem statements, we pointed out a common mistake people make with problem statements – they confuse the manifestation of a problem with a problem.

Problem manifestation [noun] – an example of a way in which a problem is exhibited, without appreciating the true nature of the problem. Ex: The problem manifestation is that the tires on my car are under-inflated. The problem is that my car is too expensive to maintain.

This distinction is relevant. The cost of operating the car is too high. That is the problem. It happens to be that one reason that the cost is too high is under-inflated tires. If you focus your energy on getting properly inflated tires, it will help (by improving fuel economy a little, and by reducing the frequency of tire replacement) with costs anecdotally. But you will not have solved the problem that costs are too high. Unless you get lucky. Costs can be high because the engine is inefficient or damaged, the aerodynamics of the car are bad, or any of a number of reasons. If you solve the problem by addressing a single manifestation of the problem, without understanding the whole problem, it is only because of luck.

Your Problem Statement is The Problem

In the comments on that article, The Demon points out that it is not always easy to identify the right level of abstraction for your problem. The cause and effect diagram makes it brilliantly simple not only to get to the root of the problem, but to communicate this cause-and-effect hierarchy of problem decomposition.

Cause And Effect Diagram Example

The cause and effect diagram is so visceral that the easiest way to communicate how it works is to show an example. Here’s what the cause and effect diagram would look like for the example problem above, where the cost of operating the car is too high.

[larger image]

The main problem is that the cost of operation is too high. This is the far-right, or fish-head part of the diagram (it is sometimes called a fish bone diagram).

The problem can be decomposed into three separate problems: spending too much on fuel, maintenance, and payments. Each of those problems can be further decomposed. Note that “under-inflated tires” appears twice – once as a cause of low miles per gallon (MPG) and once as an excess maintenance cost.

Alternately, you could recognize that spending too much on fuel could be due to lower fuel economy or excessively high prices. You could then choose to decompose the problem slightly differently:

[larger image]

Either approach results in crystal clarity that under-inflated tires is one root cause of low fuel economy, which is one cause of excessive spending on fuel, which is one cause of excessive operating costs. This visual approach helps significantly when trying to identify the right level of abstraction for expressing the problems in your problem statement.

Problem Abstraction Is A Side Benefit

The really cool part is that the help you get in finding the right level of abstraction for your problem is just icing on the cake. [Ed: No jokes about fish-bone cake. Ick!]

The real benefit comes in communicating and validating the problem decomposition with your stakeholders.

Someone questioned me once on the value of writing passionate requirements. Show one of these to your team, and you’ll get enthusiastic, passionate responses. You’ll get kudos from the business for demonstrating that you understand their needs. You’ll get praise from the implementation team for providing them with context.

Using Visio To Create A Cause And Effect Diagram

Creating a cause and effect diagram in Microsoft Visio is really easy, there’s a built in template, and it’s a good one. Create a new drawing and select the “Cause and Effect Diagram Shapes” template (under “Business Process”):

Visio will create a new drawing with a blank cause and effect diagram set up for you:

Fill in the boxes with the large problems. To get to the next level of detail (such as “Fuel Economy is Too low” in the last example), select the “Primary Cause” shape and drag it onto the diagram. Attach the arrowhead to one of the branches (the fish “ribs”) and start typing. For once, Visio’s default layout is where you want it.

To get a secondary cause shape (such as “Bad Aerodynamics” in the last example), select the “Secondary Cause” shape and drag it onto the diagram. Attach the arrowhead to the “primary cause” arrow you just created.

Conclusion

You already have a good justification for defining problems at the right level of abstraction. Now you know how to easily create a cause and effect diagram to find the right problem definition. As a bonus, communicating with stakeholders just got a lot easier – include this in your BRD.

When companies first start off-shoring, they usually send the “low level” implementation work overseas first, to work out the process kinks and manage risk. Over time, your valued, domain-aware developers will perceive a lack of career opportunities with this limited role. Naturally, you will want to consider sending design work offshore too. You can make it work. If you do it wrong, you’re toast.

Different Models for Offshore Development

There are many ways to organize software-creation teams (where creation includes product management, design, development and testing). When developing an organizational design that incorporates elements of off-shoring, there are four primary models for outsourced software creation.

1. No offshore development at all. Occasionally referred to as insourcing, this is the traditional “everyone in one place” model – or at least “everyone in similar time zones.”
2. Low-level outsourcing. The implementation teams (both coding and testing) are located offshore, with design and product management staying local.
3. High-level outsourcing. The focus of this article. Keeping product management “local” but moving design and development responsibilities offshore.
4. Complete technical outsourcing. Everyone except the product manager is offshore.

The models can be most easily compared when the same process is compared in each – just with different locations. Co-location of team members has an impact when comparing face-to-face communication with online / phone / remote communication. But this factor is not a primary one in influencing team-decisions – it is no different than having someone who works from home. The key element in team dynamics is a dramatic shift in timezones.

This timezone shift causes a latency in the communication process, illustrated by the following example:

Imagine the following expensive question and answer session:

• Person A asks person B a question.
• 12 hours later, person B responds with a request for a clarification.
• 12 hours later, Person A clarifies the question.
• 12 hours later, Person B responds with an answer.
• 12 hours later, Person A acknowledges the answer.

When this communication channel happens between an onshore person and an offshore person, it takes 48 hours instead of 48 minutes. The more this happens, the more expensive it is to outsource. The key to making low-level outsourcing work cost effectively is to minimize the impact of this communication latency, while realizing the benefits of lower salaries in the offshore location.

Making Offshore Development Work

This is why proper communication design is the make-or-break element of making collaborative teams work when using an outsourcing model that involves anyone being offshore.

High-Level Outsourcing

Consider the following software development process diagram (from Four Application Development Outsourcing Models):

In this off-shoring process flow diagram, the shaded areas represent the activities that happen offshore. Note that this is the exact same process flow that is used to describe the other outsourcing models. The difference from other models is primarily where resources are located, but also the relevant scope of responsibility. In comparison with low-level outsourcing, the only difference in the process flow is that responsibility for test design and solution design is transitioned to the offshore development team.

Artificial Boundary

This model creates a bit of an artificial boundary between the “interpret requirement” step and the “design solution” and “design tests” steps. This artificial boundary creates a potentially odd dynamic within the team.

To make reading easier, we’ll talk about the development side of the process flow only, but the same ideas apply on the testing side.

This model has one developer interpreting requirements, and a different developer doing the design work. In an insourcing model, those two developers are usually the same person. In large development teams, a common breakout here is architect versus senior designer. The architect (the figure on top) would be responsible for those design considerations that span the enterprise and the senior designer would be responsible for those design considerations that affect a single application. Here’s a good background article by Scott Ambler on approaching enterprise architecture.

Why have an artificial boundary? Because this model is an emergent design.

1. A company starts with low-level outsourcing.
2. The offshore developers complain about a lack of growth opportunities (both career and skill).
3. Executives are not prepared to completely outsource all technical work (risk aversion), or the team is not ready to succeed with that approach.

Splitting the “interpret requirements” task from the “design a solution” task is a compromise. It minimizes the risk associated with providing growth opportunities to offshore team members. That risk is minimized by avoiding the high-latency communication channel (from onshore to offshore) when communicating requirements. Instead, the interpretation of the requirements is done onshore, and that interpretation is communicated.

You can argue that this model is the offspring of a trust issue within the organization. A company can absolutely say “We want growth opportunities for our offshore team members” and at the same time say “We are not ready to relinquish complete technical control.” This is definitely a trust issue, and therefore a perceived risk mitigation strategy. The risk may be very real, or non-existent. In either case, it is emotionally present.

Vague Scope and Role Conflict

If, while reading this, the notion of splitting interpretation from design feels uncomfortable, that’s because it is. For many teams that are evolving their outsourcing model, it feels uncomfortable, but it feels less uncomfortable than releasing complete technical control.

One problem, which I completely grok as a former developer, is that it is almost impossible to interpret requirements without imagining designs. But this model has different people performing the different tasks. So should the interpreter just discard those designs? Presumably the interpreter is more experienced, certainly more knowledgeable about the domain. It would be a shame to discard those design insights.

Robbing Peter to Pay Paul

This approach has clear benefits for the offshore developers who are now presented with growth opportunities. Unfortunately, you run the risk of sucking the fun out of the role of the interpreter – a senior, experienced developer with domain knowledge. While proper requirements interpretation can be fun, it usually is not fun for a developer. Only requirements people will enjoy those nuances, generally.

You risk eliminating a career path and growth opportunities for your onshore resources with this model.

Division of Labor

One approach that keeps the growth opportunities open for your senior onshore technical resources is to have them play multi-product, or architectural roles. This presents an opportunity for these individuals to apply organizational insights across products, finding synergies between applications and driving consistency and consolidation among applications. You essentially split the responsibilities “broad and deep” where the onshore designer is looking across the portfolio and the offshore designer has ownership responsibilities for a single application or scope. This is similar to the division of responsibilities that works well for tackling enterprise product management.

Instead of preventing communication of requirements across the high-latency channel, it minimizes it. The onshore designer acts as the liaison between multiple offshore designers, fielding interpretation questions, and more effectively, preventing them. Developers have a language all their own. Through a shared perspective on common experiences, they can communicate very efficiently – by analogy, symbolically, and via design patterns. These communication opportunities (between like-minded individuals) can have very high information density. For example, one developer can say “MVC pattern” to another, and that serves more effectively to communicate an approach to designing a solution (and a context / interpretation of requirements) far more efficiently than a product manager describing requirements that multiple tools and platforms should expose the same set of capabilities or behaviors [and that is overly short, because I don't feel like typing a comprehensive explanation of the MVC pattern].

Another approach is to silo the developers vertically – having some applications (or modules) following a low-level outsourcing model, and others practicing complete technical outsourcing. Any given team is operating discretely with a clearly defined set of responsibilities. The teams may just be operating differently. Essentially, you’re saying that your “average” is high level outsourcing, even though it is really a mix of two models. This doesn’t really count, since none of your teams are addressing the communication challenges of this model – your company is leapfrogging over it, but choosing to mitigate risk by doing it a little bit at a time.

You can also take the approach of having the onshore designer be responsible for over-arching and high-complexity design issues, with offshore designers owning more straightforward and lower risk design activities.

The best approach for maximizing your team’s effectiveness (and your HR goals) will be overwhelmingly determined by the individuals involved. If you’re in a large company, you probably don’t get to maximize team effectiveness – you are likely to be forced into a particular model. If you’re doing the forcing, recognize that one size does not fit all.

High Latency Communication And Designing

When circling back to the main challenge of offshoring – communication – you need to look at the nature of the communication that is subject to the high-latency of temporal displacement within the team. The key to making this model work is to leverage the efficiency of cross-talk between developers. That means having experienced people on both the offshore and onshore teams who share common design backgrounds (patterns, analogies, examples) and deep domain understanding (reducing the provision and clarification of context across the communication channel).

Design reviews are also very effective at eliminating the impact of this latency on communication. Design reviews typically happen as follows:

1. Designer A spends time creating design based on an interpretation of requirements.
2. Designers A & B get together and review the design in a relatively short meeting (or Designer B reviews a design document). Feedback is delivered in a burst.
3. Designer A spends time updating the design based on feedback from step 2.
4. Return to step 2 as many times as is needed.

There is a big chunk of work involved in incorporating feedback from a design review. This can be folded into the “white space” between communications. In other words, while designer B is sleeping for the night, designer A is making updates. This looks like, but is not the follow-the-sun pattern.

The follow-the-sun pattern is one where someone is always working. I’ve made this work on a project where there were two teams working 12 hour shifts with a 4 hour overlap (and a 4 hour “blackout”). Note – that isn’t sustainable, just anecdotal. I think the linked article is right, commonly, follow-the-sun implementation does not work, for the reasons cited in that article.

What makes this very different is that we are synchronizing the naturally-occurring time lag between design reviews with the geographically-induced time lag in communication.

Conclusion

The strategy for successfully utilizing offshore resources for both implementation and design starts and ends with communication. It also requires attention to your specific people and their career aspirations.

• Utilize design reviews to take advantage of serendipitous time-lags in the communication cycle.
• Assure that your role definitions are clear, and aligned with the aspirations of the people on your team.
• Follow the tips for effective offshore development – this strategy builds on that one, it does not replace it.

Economic pressures are driving most companies in high-developer-salary markets to explore using offshore development teams as part of their approach to developing software. Developing software with a global team presents new challenges as well as new benefits. If you do it right, you can have a more cost-effective team. If you do it wrong, you can have a disaster.

Different Models for Offshore Development

There are essentially four different models for managing a software development team, with respect to onshore and offshore roles.

1. No offshore development, also known as insourcing.
2. Low-level outsourcing, having the implementation (but not design) team members offshore.
3. High-level outsourcing, having the implementation and design team members offshore.
4. Complete technical outsourcing, having all technical implementation team members offshore.

Each different model has the same set of people involved in the process, with the same channels of communication. The differences are in which communications happen across geographic and temporal boundaries, and which communications happen in the same time zone.

For this article, we are focusing specifically on low-level outsourcing, where the communication channel most affected by different timezones is the one between design and implementation.

Low-Level Outsourcing

Consider the following software development process diagram (from Four Application Development Outsourcing Models):

Each area surrounded by a dashed line represents a different type of work, or a different required dominant skill set. Every stage in the development process requires a different set of dominant skills, and all areas share a set of common skills. When exploring different offshoring models, teams are most effective when they identify the distinctions in dominant skill set requirements, and divide responsibilities along those boundaries. When you create an artificial (or arbitrary) boundary within one of the regions in the diagram, you create opportunities for misunderstanding. With those misunderstandings, you can have people redundantly working on the same thing, or even worse, you can have tasks that don’t get accomplished. You also introduce the possibility of discord within your team as people either proclaim “that’s my job” or “that’s not my job.” You can split a team within the areas shown above (and we’ll talk about that in a future article), but it is harder to do successfully.

Low level outsourcing is an approach where the implementation team members who write the code and tests are offshore. The requirements work is done onshore (where salaries are expensive). Interpretation of the requirements is also done onshore. The design of the testing plan is done onshore, and the design of the solution is also done onshore. The creation of tests and the implementation of the code is done offshore.

In the diagram above, testing of requirements happens on the left, and testing of the implementation happens implicitly on the right. If you haven’t been reading Tyner Blain for a couple years, that may not make much sense. Testing of requirements and implementation are different, and you need to do both.

Testing: Isolation of Variables Reduces Costs

Testing is something that can be approached from a few different perspectives, and the word “testing” means different things to different people. In this process flow, we are focusing on two main areas of testing – testing the requirements and testing the implementation. When you test the requirements, you are asking the question “does this solution do what the product manager intended?” When you test the implementation, you are asking the question “does my solution behave as designer intended?” This is a nuanced difference, and non-technical people may say “what is the difference?” The designer intends exactly the same thing that the product manager intends.

If you think back to your high school science class, you’ll remember the concept of “control of experiments.” This is the field of practical application of logic to scientific experimentation. By taking a logically rigorous approach to designing a science experiment, you can isolate variables, and test each of them independently. This prevents you from drawing false conclusions from your data. The same process leads you to test both the requirements and the implementation. If you’ve ever submitted a bug and had the implementation team close it out with the statement “working as designed”, you already know the benefit of testing both. Just because something is designed to do X does not mean it is not supposed to do Y. By introducing a designer between the product manager and the testing, you introduce the possibility that the designer is the source of the bug – by misinterpreting the requirements.

It is possible to “test” the design and then test the implementation – this will isolate the design from the implementation. Unfortunately, the only way to “test” a design (without also testing the implementation) is conceptually, with a thought experiment. And that’s exactly what the designer does as part of designing. No one else is really going to understand the design well enough to do that. And if the designer is doing the thought-testing, there is no way to isolate if the designer misinterpreted the requirements in the first place. That same misinterpretation will influence his testing in the same way that it influenced his design (See error source E3 in Where Bugs Come From for more details). This is critical to designing, but it does not work for testing a design.

It is possible to test just the requirements. You create tests based solely on the documented requirements. You run those tests against the implemented solution. When the test passes, every step in the process worked. These are known as black-box tests, because you can run the tests without any insight into how the software is written (it is a “black box”). The problem comes when a test fails – you know something is wrong, but you have to do (expensive) research to figure out the source of the problem. It could be that the implementation failed to do what was designed. Or it could be that the software design failed to meet the objectives of the requirements. There is a way to reduce the cost of this analysis – by testing both the requirements and the implementation.

You can easily test the implementation. An implementation test, commonly known as a white-box test, and usually implemented as a unit-test, inspects the effectiveness of a particular implementation at doing what the designer intended. When you combine implementation testing with requirements testing, you isolate the designer variable. If a requirements test fails but the implementation tests pass, the problem is with the design (or with the design of the test). When both requirements and implementation tests fail, you know that at least the implementation is wrong.

In the diagram above, the testing on the left side represents testing of requirements. The right side of the diagram implicitly includes testing of the implementation as part of implementing. You need to ingrain your implementation testing into your development philosophy. Would you deliver code without compiling it? Why, as a developer, would you consider delivering it without testing it? Compilation is not just a build step, it is also an implicit test of compilability. You should also include the implicit test of “does what I intended it to do.”

Combining the discipline of continuous integration with test driven development is the most effective way to accomplish this. Note: remember this part, as it is a critical component to making low-level offshore development work. Without this, you may as well give up – you certainly aren’t going to be more cost-effective.

Communication Across Time And Space

The key to making offshoring effective, as with any development process, is to make the communication work. For communication that happens between people in the same location (or at least roughly the same time zone), the problems and solutions are no different than when you have an insourcing model. What’s different is the communication that happens between members of the onshore team and the offshore team. This communication is not just remote (technology helps us solve these problems with instant messaging, phone calls, and other real-time (or near-real-time) techniques), but also phase-shifted in time. When you have team members working while other team members are sleeping, you slow down the collaborative process. You introduce a near-crippling latency into the communication channel.

Imagine the following expensive question and answer session:

• Person A asks person B a question.
• 12 hours later, person B responds with a request for a clarification.
• 12 hours later, Person A clarifies the question.
• 12 hours later, Person B responds with an answer.
• 12 hours later, Person A acknowledges the answer.

When this communication channel happens between an onshore person and an offshore person, it takes 48 hours instead of 48 minutes. The more this happens, the more expensive it is to outsource. The key to making low-level outsourcing work cost effectively is to minimize the impact of this communication latency, while realizing the benefits of lower salaries in the offshore location.

Communications On Which To Focus

The “happy path” communication channels (shown with blue arrows in the diagram) are the transfer from “test design” to test, and from “implementation design” to implementation. You have to communicate the designs in such a way as to minimize misinterpretation of the design. Never prevent needed communication. Your goal is NOT to stop communication, but to preempt it by eliminating the need. The only thing worse than taking too long because you have a lot of communication is failing to communicate enough. Your goal is NOT to prevent communication, but to minimize the need for it.

The “trust but verify” communication involves making sure that the implementation meets the design. In (requirements) testing, it means reviewing that the tests exhaustively cover everything identified in the test design. It also means reviewing that each test (implementation) actually (effectively) tests what it is designed to test. As team members demonstrate their capabilities, they require less oversight – which is true of any mentoring relationship. In implementation, it means verifying that the code does what the design requires. You could read the code and make a determination, but that is a manual inspection of the code, and manual inspections have been shown to be at best 80% effective as a testing method. What you need to do is create a unit test suite, run it continuously, and only allow developers to check-in their code (to the trunk) when the entire suite passes. Then all you have to do is review the test suite to assure that it will test the design effectively. It wouldn’t hurt to also run the test suite locally (onshore) as a verification, but fundamentally, you are trusting that your developers will follow this continuous integration process.

You are using testing and test design as a mechanism to validate effective communication. You can think of it as a form of active listening. When you (or more appropriately, your design document) says “X”, you can review the test design to confirm that your listener designed tests that assure “X” will happen. Do not just rely on informal communication and acknowledgement. Cross-cultural communication introduces a lot of complexity and misinterpretation. People who do not share a common language or culture also tend to interpret symbols very differently, and will rarely have the same connotations for given interpretable words.

Definition of tests and validation of testing is important beyond the immediate communication of design. There are also the feedback loops that come from the “unhappy path” when something goes wrong (and a bug is introduced). Each of these “where was the bug introduced, and how do we fix it?” cycles is also affected by the latency of cross-shore communication. Good testing reduces the number of these otherwise unwarranted communication cycles.

Developing good design docs is also critical to the success of this communication. The definition of “good” for a design doc is so dependent on the exact circumstances that it is impractical to try and define what that is (at least within this article). A design doc needs to be written with the reader in mind, not the author. Beyond that, we won’t try and make any statements of truth.

Conclusion

The strategy to successful utilization of offshore resources for development and test implementation work starts with communication. The strategy also ends with communication.

• Create artifacts (good design docs) that minimize the clarification cycle across the onshore-offshore time boundary.
• Review implementation tests as an active-listening mechanism to confirm that communication of design intent was effective.
• Practice continuous integration (both as an offshore developer and as an onshore designer or development manager) to assure that your solution stays true to the design and the requirements.

And, as always, have great people – because people trump process.

A rose by any other name…

When we’re learning how to write in high school and college, we’re taught that synonyms make our writing more exciting. In fact, not using synonyms can make our prose clumsy and awkward.

When it comes to requirements, the last thing you want to do is use synonyms. Except sometimes.

Writing Stylish Requirements

One of the lesser appreciated rules of writing good requirements is to write requirements with good style.

Your writing style needs to take into account the fact that not all of the readers of your requirements will have English (or whatever language you write in) as their primary language. The readers may have as a primary language one that does not have the same idioms, constructs, and “common” terms as the language of the requirements. Those readers are already at a disadvantage, having to reverse-engineer colloquialisms, decode complex sentence structures, and look up the definitions of terms that they don’t know.

Even readers who share a common language [Great joke from Eddie Izzard: "Britain and America are two countries separated by a common language"] probably will not share the same idioms and colloquialisms.

Writing clearly and unambiguously requires that you use more formal language when writing requirements. Synonyms may make for better style when writing prose, however, they can confound your readers and increase the risk of misunderstanding when used in requirements documents

Avoid Synonyms

Synonyms introduce ambiguity into your requirements. Consider the following examples:

• The user will have added items to her shopping cart while browsing the website. When she is ready to purchase the items in her cart, she will click on the “cart” icon. All of the items in the basket must be priced with the most recent pricing rules.

Are you pricing the items in the basket, the cart, or the shopping cart? That may seem obvious to you, since most of us are familiar with the shopping cart metaphor in e-commerce transactions. What about the following?

• A round bit must not rotate within the head when the vice is adequately tightened.
• The vice will be tightened with a key measuring no more less than two inches in diameter.
• A moment of 10 inch-lbs applied to the chuck will be considered adequate for tightening.

If you don’t know that chuck and key are synonyms, you’re in trouble. If you don’t realize that the vice and the head can also be considered synonyms in this context, you are in more trouble. You should use the same terms throughout your requirements document, when referring to the same object or concept.

Except when you should use different terms for the same objects.

Embrace Synonyms

There are times, however, when synonyms can bring clarity to an otherwise confusing document. This effect is less powerful than introducing confusion, so when in doubt, don’t use synonyms.

Synonyms provide clarity when used in a particular context. If you sell cars, then you have a customer. Imagine you also provide financing (products) for your customers. In the context of negotiating a price for the car, the customer is a customer. In the context of negotiating an interest rate, the customer is also a borrower.

Validating the requirements for the lending process may be much easier when using the word “borrower” instead of “customer.” What you are striving for is clarity of language, and when interacting with stakeholders who have always used the term borrower, you can use that term in your documentation.

The key is to identify the synonym in the glossary of terms. You have to identify the synonym as being associated with both the equivalent term, and the context in which the synonym applies.

The customer at the car dealership can be the purchaser, the borrower, and the driver. It all depends on context. When you manage the synonyms within your glossary you can use the different terms. But you should only use them when they reduce ambiguity – not when they introduce it. Even with our example, the customer and the borrower might be different people – so make sure that the synonymous terms represent the same object, and not potentially different ones.

Bill Miller, who writes You Want it When?, a blog focused on improving the way you manage software development and I had a debate over email about outsourcing. We looked at pro’s and con’s, and our discussion centered around the best outsourcing model, and what the ramifications of outsourcing really are. Read on to see the back-and-forth.

The Context

Bill and I started this debate based on the following:

• We really enjoyed some back and forth discussions that grew around other topics we had written about previously and wanted to do it again. We both really respected the other person’s well-reasoned positions, and both felt that we learned a lot from the other person.
• We thought it would be even better if we were able to open the conversation up to others – so we decided to have a debate that we would then post to our blogs so that other people could join in, or at least see reasoned arguments on both sides of the issue.
• There are a lot of thorny issues where reasonable people can disagree. We looked forward to discussing one of them, and look forward to discussing more of them.

Bill had a great suggestion – we are each posting a copy of the back-and-forth (we couldn’t figure out a usable way to make you go back and forth between our blogs). If you want to make a point or ask a question of Bill, post it to the copy of the debate on his blog. If you have a question for me – post it here.

The Outsourcing Debate

Scott

What do you think the best model for offshore outsourcing is? To narrow the field (initially, I’m sure it will expand as we go), let’s use this article to frame our discussion:

Outsourcing Models for Software Development (at ThinkingStreet.com)
I think the best model, when trying to write innovative software is to start with low-level outsourcing, until you work out the kinks in operations and develop mutual trust. Then I think you should move to high-level outsourcing and leverage the increasing skills of the team you’ve partnered with. I don’t think you should go to the next step of complete technical outsourcing. As much as some people want to believe that it is effective, and it may be, in the short run, it is a recipe for long term failure. If you lose the capability to innovate technically – both in products and process (QA, etc), you die a slow death. Further, I believe the collaboration of “to solve this problem, I think we should do this – what do you think?” is easier than an open ended charter across cultural, language, and temporal boundaries to “solve this problem.”

Bill

I’ve read your article and your email that started this off. You’re email actually raises a number of issues that we can discuss. I’ll start on this one: “I don’t think you should go to the next step of complete technical outsourcing. As much as some people want to believe that it is effective, and it may be, in the short run, it is a recipe for long term failure.“ We have to get some better definitions of what complete technical outsourcing means. What if the technical center is owned by the company is that complete technical outsourcing? For example, at one multi-national company I worked at, we opened up wholly owned offices in India and moved entire products to be developed in India. Would you consider that complete technical outsourcing? The motivations for opening the technical centers in India were entirely based on saving operating expenses. When I was at another multi-national company, they had development offices on every continent on the planet except for Antarctica. Is that complete technical outsourcing? When you have another company do the work in a remote office, is that the only form of outsourcing? The challenges are similar whether you own the offices or you contract for the people. If you hire a company in the same city to do all the work, is that complete technical outsourcing. I’m trying to understand what about outsourcing is unique that makes it a slow death if it’s complete. Is it distance, the fact that another company is doing it, both or something else?

Scott

You die a slow death when you outsource everything, because you are outsourcing your innovative capabilities along with the contract to create short-term innovations. Neither of the multi-national company examples you gave have that problem. In both examples, you’re keeping your intellectual property “in house.” I would say, generally, that the location that does the work is the one best equipped to invent the future. As long as your company owns it – and is ok with the innovation coming from that location, then great. But if you don’t have control / ownership of the group doing the work, you’re doomed to a slow death.

I agree with you that all geographically distributed teams face the same execution challenges more or less. That element is just one of efficiency. If the extra impedance and (presumably temporary) inefficiencies of transitioning work to a different (again, presumably) lower cost provider are smaller than the savings of distributing the work, it makes sense.

But not when you give away the responsibility outside of your company.

Bill

The employees at both multi-national companies that I worked at felt there was no difference between a consulting outfit taking the work and an offshore development center being created to take on the work. Most felt the fact that the work was moving away from the originators the project was doomed to failure. They thought it was doomed to fail because the team and the knowledge base was destroyed in the process – true for either model. Do you really lose the IP when you give the work to a consulting company? I don’t believe so because the requirements, designs, and code are all owned by the company doing the outsourcing. Isn’t the IP the artifacts? Programming, managerial, and QA skills are not so unique that they cannot be reassembled elsewhere. The fact that they are reassembled from the US to let’s say India in the form of an outsourcing model is proof of that these skills are readily available. There are inefficiencies in reassembling teams that slow progress down, but once the team is up to speed, they should be just as effective as any capable team of doing the work.

Scott

Maybe “slow death” is too harsh. How about a door rusting shut? You can open it again, by reinvesting in getting the IP back into the company, but you are introducing an effort and challenge that must be overcome to do it. When you “outsource” within your company, you are only moving the expertise and “off cycle inventiveness” that comes from having a working familiarity with the space. When you outsource outside your company, you no longer have anyone who can do that work (without a ramp-up or investment period).

Imagine that you are a publisher of horror novels. You have in-house authors that write for you. You sack them, and get freelance authors to write books for you. Initially, they are writing on spec – creating books based on ideas your authors already had. Eventually, they are writing books based on their own ideas. Being immersed in the horror genre for a while, they’ve gotten pretty good at it. And they ship you all of the books and outlines.

Then one day, the authors decide to cut out the middle-man (you) and self-publish.

Just because you have a stack of books and outlines that they created for you does not mean you are in a position to write and publish horror novels any more. You have to start over.

Bill

Some people use off shoring and outsourcing interchangeably, and I was looking to understand if you were too. As I understand you, you see them as two separate models: off shoring works and outsourcing is a death sentence. I’d like to explore that more, but I need to understand your position on IP better before I can.

You seem to be using a nonstandard definition of IP. IP is a product of people’s minds: art, technology, design processes, solutions to a problem, trademarks, patents, etc. These are all protected by international law. Companies own IP; they don’t own people. The IP isn’t lost when you outsource or offshore. I tried finding a definition that supported your use, and I was unable to find it. Here’s one reference to IP definition on a Cornell University web site. http://www.library.cornell.edu/newhelp/glossary.html#I I don’t accept that IP is lost when companies outsource or offshore unless they give it away in the contract. I’d like to understand better what it is that you feel a company is losing when they outsource to respond more effectively.

Scott

Great points, Bill. I believe that the phrase “invest in your people” is more than a platitude – that years of immersion in, exposure to, and thinking about a domain creates an unrealized asset in the minds of the people. You’re absolutely right that “yesterday’s ideas” are your property in an outsourcing arrangement. I see those as two different classes of asset. But they are both intellectual assets, and in some respects, they are both property. Hence my liberal use of intellectual property as a short-hand description of the stuff in people’s heads.

When you’re investing (implicitly) in the heads of the outsourcing employees, you are doing it at the expense of investing in your own people.

And this effect will only be felt in the long run – “yesterday’s ideas” have the same value regardless of who invented them. And as you point out, in an outsourcing arrangement, you own those inventions. Since few management decisions are made with the long run in mind, it is easy to see the allure of outsourcing as a short term cost reduction with no tangible or immediate down-side. My contention is that there is a long term down-side.

Bill

I can’t say I like the changes taking place in the IT industry with regard to outsourcing and off shoring, but that’s only because of my own personal reasons. The corporate world is changing. I don’t believe it makes sense to fight inevitable change. Globalization is here to stay, and so are it’s consequences to how we work. It’s similar to the changes that occurred in the 18th century at the dawn of the industrial revolution with similar effects on how people live and work and how business is conducted. But I don’t believe all the outsourcing is motivated out of cheap labor because of globalization. It’s because the software industry has matured and global commerce is changing business practices.

As the corporate world evolves, many activities that were once done in house are now outsourced: whether it’s through a consulting arrangement or the purchase of services from a 3rd party provider. This makes obvious sense when the services or products are not strategic for the company. For example, ADP and Paychecks do payroll processing for many companies. It should be cheaper for a company to purchase this service from ADP and Paychecks than to hire staff and support this in house. Few companies have IT departments for payroll services any longer. For many companies IT is just a tool like a typewriter or copy machine. It never made sense for a company to build its own typewriters and copy machines, and they didn’t, and so for many companies, it doesn’t make sense for them to write their own software and manage their own computers either. They will never be any good at it because it’s not their business.

How did we get here with companies getting into the software development business when that was never the purpose of their business in the first place? Why should Hospitals or Insurance companies have IT departments? These are support services. We got here because the software industry was new, and there weren’t businesses that companies could go to, to purchase the software they needed, so they created it in house because it made financial sense. The return was greater than the investment. Now that the software business has matured, there are companies providing products and services that 20 or 30 years ago were unavailable. The industry has now matured where companies can purchase what they need rather than build it in house. So now they have started the process of unwinding the departments that they would have never created in the first place if software wasn’t such a nascent industry.

This is mostly a win-win situation. It is always a better career choice for an IT professional to work at ADP developing payroll processing systems than to work at Aetna, for example, developing payroll processing systems. At ADP payroll processing is a profit center and a core competency for Aetna payroll processing is a cost center and a necessary chore. At Aetna if the payroll processing system is working well, there is less motivation to improve it. At ADP there are competitive reasons to improve the payroll processing system. This usually means that the IT person working at ADP will be keeping up with the changes in the field faster than the IT person working at Aetna. (note, the company names are only used as an example to illustrate a hypothetical point.)

As for the concern that investing in the heads of outsourcing companies is a competitive disadvantage, I don’t see it for a few reasons. If Aetna outsources to ADP its payroll processing system and ADP develops talent that gets really good at this, I don’t believe Aetna lost anything strategic in the process. Now if a company hires an outsourcing company to develop a unique application that gives it an advantage in the marketplace, I still don’t believe a company loses anything here either. Let’s take Wipro; it would be bad business for them to offer contracting services and then start competing with the companies they offer contracting services to. I don’t believe any company has anything to fear from Wipro entering into their market space. Wipro is a multi-billion dollar software contract house; they are going to look to make their next billion growing that business – not entering the businesses of their customers. Second, all of these contracts have agreements for who owns the software created etc… It would be a breach of contract if they were to break that agreement, and there are legal remedies for it. Let’s assume the employee quits Wipro and enters the market themselves; that’s no different than any employee today quitting and doing the same thing, and it’s done all the time today.

I still struggle to see the loss of inventiveness that you speak of. I actually see an enhancement of inventiveness for many of the kinds of companies that I’ve described in this response. These companies are freeing up capital to invest in the reasons they went into business in the first place. With that extra capital, they have the opportunity to invent even more because less is being spent on non strategic purposes. Outsourcing for many industries has been with us for decades. The IT profession has been experiencing it marginally as well for decades, but we’ve hit an inflection point where the change has been dramatic. This is permanent. The companies that learn how to manage this successfully will win in the marketplace.

I believe, instead of the software professionals fighting this inevitable trend, we should be looking to accept it and recommend how to adopt these changes successfully. There’s no turning the clock back, and the dire predictions are specious. Oh some will fail at this, but many that do are probably already struggling with IT in the first place. If we do accept it, the possibilities for IT professionals in this new model are boundless unless, of course, the only measure of good is to see that you are doing things today the way you did those things 20 years ago. The world leaves those behind who don’t move on. We may be the early 20th century equivalent of a blacksmith. It would have been a mistake for the blacksmith to not accept the change that was upon him. Likewise, the 21st century software engineer needs to accept the changes that are upon us. Only then can the software community begin to build the future that is possible. Fortunately, the need for software engineers will not vanish like the blacksmith, but what will change is the niche we fill in the value chain. Only when we embrace change can we conquer change. When we fight change, change conquers us.

The end?

Separation of business rules from requirements is a good thing. Not because of semantic distinctions, but because it allows you to write better software, write it faster, and change it more easily. This article is a response to an excellent comment on our recent article about hidden business rules. Thanks for challenging the idea – it either eliminates it from discourse or makes it stronger, and we all benefit. Here’s an attempt to make it stronger.

Goals of Separating Rules from Requirements

Writing software ultimately involves coding up an implementation that both satisfies the goals of the customers and enforces the rules by which that customer chooses to achieve the goals. This is the traditional way to write software – define the goals, and all of the enhancing, constraining, and clarifying details, then implement it. There are some inefficiencies to this approach, but they are in the “getting great at writing software” bucket, not the “avoiding failure at writing software” bucket. Consider this the medium priority goal of separating rules from requirements. In a Kano analysis, this is a more-is-better benefit.

When we set out to write software, it is with intent. That intent encompasses processes, rules, and requirements. The combination of all of these could be described as a summation of intent.

Maintaining software is expensive. When you design an implementation, you (should) think about what is likely to change when making your design decisions. The greater the probability or frequency of change, the easier it should be to make those changes.

Intent changes. Agile processes start with a premise that even if the true intent were fixed, our understanding of intent would change, as soon as we get what we asked for. In practice, both our understanding of intent, and the actual intent change over time. To make the language less cumbersome, for the rest of this article, when I refer to intent it is our understanding of intent – and changes to intent represent both changes in the true intent, and changes in our understanding of it.

When developers think about software maintenance, they often think about it in terms of bugs and features. What needs to be fixed, and what needs to be added (or removed)? To make a significant impact on the cost of maintenance, we have to take that perspective to the next level. Set aside fixing bugs (where bugs are “does not work per the requirements”), and think about the new features. The new features truly represent new intent. Or in an agile process, it may be the recently revalidated, previously identified, next most valuable intent.

In both cases, intent is a moving target, and changes in intent drive changes to the existing software. To minimize the cost of making those changes, our implementation should be structured such that the most common changes are trivial to implement – ideally, they won’t even require changes to the code. When you can change the behavior of an application without recompiling the application, you significantly reduce the effort required to define,develop,test and deploy an update to the application. And you can also dramatically reduce the time required to make the change.

This is the high priority goal of separating rules from requirements: increase the speed, and decrease the cost of changing software to match changes in intent. I’ll say it again in bold.

The primary goal of separating rules from requirements is to increase the speed and decrease the cost of updating software to match changes in intent.

While the cost reduction part of it is nice, it is the speed element that can be the most compelling. James Taylor and Neil Raden wrote about this in their book, Smart Enough Systems. We accept the premise that abstracting the implementation of volatile rules from the rest of the software provides benefits in speed of delivery on an ongoing basis. And that is the primary driver for the separation of rules from requirements. If you don’t accept that premise, then the only benefit comes from improved documentation style, structure, and standardization – all somewhat subjective benefits.

Visualizing The Benefits

Here’s a timeline showing the benefit of agility – being able to deploy and update faster.

The maroon curve represents “traditional” deployment – where the implementation of volatile rules is no different than the implementation required to support requirements. It will take longer to deploy initially (but not necessarily much longer), and it will take longer to make changes (when the rules have been changed). The upward sloping line starts displaying accumulated value as soon as the software is released. When the next iteration is released, the rate of value accumulation will go up. There is one iteration displayed in the timeline.

The green curve represents deployment with volatile rules abstracted in the implementation. This could be as low-tech as implementing field-level validations in a properties file (that is interpreted by the application), or as high-tech as integration with a rules-processing engine or service. This implementation begins accumulating value a little bit earlier, but at the same rate (keeping prioritization and other factors equivalent). The first iteration happens more quickly, so the slope of the curve increases earlier. The length of iteration has been shortened enough that a second iteration can also happen. This further increases the relative rate of accumulation of value. The longer this pattern goes on, the greater the disparity.

Encouraging This Behavior

Abstracting the rules from the requirements will make it easier for developers to absorb and design for those rules. Further, once the rules have been separated from the requirements, it is easier to identify which rules are the volatile rules. And that enables developers to make smart decisions about when to abstract the implementation, and when to embed it.

You could abstract only the volatile rules from the requirements, and leave other rules embedded within the requirements. There are three good reasons for separating all of the rules from the requirements.

The first reason is one of consistency of documentation, and arguably style. Your communication will be more effective when consumers of the documents know that all rules are treated in the same way. If developers have to look in the requirements for some rules, and a table of rules for others, they are more likely to miss something. Subject matter experts who are validating the rules will also be able to do that job more effectively when they are documented similarly.

The second reason is that by separating all of the rules, you will better be able to identify the ones that are volatile. You can more easily evaluate the rules as a whole, and formally or informally characterize their frequency and likelihood of change. The rules for management of available products and the calculation of risk in a portfolio are likely to change frequently. The rules that represent FAA regulations are likely to change infrequently. You can better assess this data when dealing with a cohesive set of rules.

The third reason is that separation of the rules will imply to developers that they should at least consider separation of the implementation. Especially if, in your documentation approach, you identify which rules are volatile.

Conclusion

There are differences in rules and requirements. While the content of how they are used when developing software may be only semantic, there are practical benefits to separating them. Separation of rules and requirements in a documentation approach will make it easier for your development team to implement solutions that separate volatile rules from the rest of the code.

And this separation will make the software more valuable, more quickly.

Measuring the return on investments in design may be the hardest ROI calculation you can do. It certainly is one of the rarest. To measure ROI, you have to be able to determine what would happen without the investment, and what happens with the investment. The difference between them is what happened because of the investment.

Fast Company Interview

Bill Breen posted an interview with Rob Wallace on the Fast Company blog about proving the value of design. The start of Bill’s article lets us know that measuring the ROI of design (ROD) is so rare that it may be impossible or impractical to do. He points to a Whirlpool survey of 15 design-focused companies – most of whom were “clueless” about the return on their design investments.

Rob explains that the reason for measuring the ROI of design investments is that ROI is the language of executives. “If you can’t measure it you can’t manage it. Businesspeople operate in a world of numbers.” Simply put, if you want to make someone invest in design, you have to show them why they should invest in design. One way to get a company to invest in design is to convince the benevolent dictator in charge of the product (or company) of the subjective merits of having good design. Apple is a great example of a company with a leader who is passionate about design. And you can argue that the Zune (from Microsoft) has had meager success against Apple’s iPod due to shortcomings in design. But can you objectively argue the point?

Argument by Extension

After Rob mentions that there is a dearth of measurement of design ROI, Bill challenges Rob’s premise – why should we expect that there is an ROI for design? Rob cites a series of studies done on Fortune 500 companies:

On average, based on two dozen case studies with Fortune 500 companies, for every dollar invested in advertising, packaging and promotion, and visual communication at the point of sale, companies realized a $7.21 ROI. But when the advertising didn’t change (or there was no advertising)—and packaging design was the only thing that did change—there was a $15.17 average ROI on every dollar invested.

Based on this data, Rob argues, it is easy to extend that if packaging (design) changes can yield ROI, then so to will product design changes.

Insights from Adaptive Path

Peter Merholz, President and founding partner of Adaptive Path wrote on communicating the value of design in Aug. 2002. In his article, based on a breakout session, the AIGA’s 5th Advance for Design Summit, he shares a series of internal benefits that they found to be more significant (or at least more measurable) than external benefits.

As we continued listing the value of our user experience design work, a more intriguing realization emerged — the bulk of our value comes from the efficiency that we can create in a company’s operations.

Some of the areas they identified are:

• Smarter Product Development Processes
• Lowered Maintenance Costs
• Less Internal Documentation
• Maximized IT Investments
• Scalability

Our Concerns

One challenge for each of these sources of ROI is that you can’t truly isolate the benefits – you would never have two teams design products for the same market, with differing levels of design investment, with a resultant analysis of project costs. Even if you did, you wouldn’t be able to isolate the impact that the team members had. You have to look at historical data, which introduces enough variables to question the validity of any quantitative conclusion.

Further, we will show that each of these is either a weak proposition, or potentially very false one.

Smarter Product Development Processes. No one has concretely identified a design-centric, purely agile, or structured requirements approach as being the best one. At least where best is defined as most profitable. Even the debate between Alan Cooper and Kent Beck highlighted more “stylistic differences” than quantified differences. There are elements of genius in each approach. Incorporating the needs of users is key to an effective design. Incremental delivery and incorporation of feedback is incredibly efficient. Tracing decisions, designs and requirements to the ultimate goals for the software is key to building the right software. If there is a “perfect process”, it is one that incorporates elements from all three disciplines. And as such – there is value to incorporating design into the process. We can’t quantify it, but we are convinced that it is there. And based on the economics of when software problems are fixed, we believe that investments in design early in the cycle will yield positive returns.

Lowered Maintenance Costs. There are a couple ways this benefit might be inferred. First, better design yields easier to maintain code. This is primarily a premise of agile development (where the design decisions are what Cooper calls program design), but perhaps the benefits also apply to interface design. Often, good interfaces simplify the complexity of, or at least obscure the means of implementation. Those interfaces are not necessarily easier to maintain. One reason complexity leaks through to users in a lot of software is that it is easier to code it that way. This value-prop probably doesn’t hold water.

Less Internal Documentation. The better the design of the interface, the less you need to teach someone how to use it. There is definitely potential for reduced external documentation, or producing the same amount of documentation may cost less, as it is easier to understand the product. It isn’t clear how internal documentation needs can be reduced by good design. Except perhaps that a picture is worth a thousand words. But a great picture may take as long to draw as it does to write a thousand words.

Maximized IT Investments. This is simply self-referential. Maximizing investments yields higher ROI. But in what way?

Scalability. Better design, from a user perspective does not imply that software will be more scalable. And often in an implementation, when user-tasks are simplified (by automating steps in the process), those decisions don’t disappear. By removing the burden from the users, you often add it to the software. However, Peter may have been talking about scalability of the team – the ability to leverage design investments across products (sharing branding, metaphors and workflow paradigms). In other words, design re-use. In that case, there is definitely a benefit, but re-usable design, while cheaper than green field design, is more expensive than no design.

Support Costs. One external benefit that Peter does identify is the reduced burden for training and support. Many software companies actually have profitable businesses built on support and training. Unfortunately, reducing the demand for those would reduce the profitability along that dimension.

Where We See Value

Fundamentally, we don’t perceive design investments as being significant cost reductions – we see them as significant revenue enhancers. Better design yields increased usage, more efficient usage, increased satisfaction, and increased word of mouth marketing.

Increased Usage. ROI forecasts are often built upon estimations (or suppositions) of levels of user adoption. As an example, consider the “Buy it now” button on eBay auctions. When people click on the “Buy it now” button, the auction is closed, and the transaction occurs at a fixed price. People are more likely to sell an auctioned item (generating a commission) by encouraging an impulse shopper. The seller risks getting less than they otherwise would, in exchange for the buyer knowing that they can get the item they want. Fewer auctions will expire unexecuted. More commissions are generated for eBay. Comparisons of final selling prices (and commissions to eBay) of equivalent items with and without the button can be done to measure the return.

More Efficient Usage. Better designs make it easier for users to do what they want to do. Easier often equates to faster. A call-center application that simplifies data access for the operator will allow them to process calls more quickly. The employer ends up with higher throughput from the call center. This throughput can be used to reduce costs, or increase customer satisfaction (with reduced “time per call” stats, or better experiences for the callers), or some of each. Comparing the results of operators using the new system versus the old system will yield measurable data.

Peter mentioned reduced training costs – and we see that as an external benefit that comes from accelerating a user’s growth from new user to proficient or even expert user. Bridging the canyon of pain to get to higher usage rates and more efficient usage faster. This also leads to increased satisfaction by creating more satisfied users more quickly.

Increased Satisfaction. Customer or user satisfaction surveys may be the only way to approximate (not really measuring) this benefit. And it isn’t clear that X% increase in satisfaction leads to Y% increase in sales. But it is likely to lead to increased sales, and may also lead to increases in sales of other products by the same company. Apple leverages this affect across its family of synergistic products. Perhaps a Bayesian analysis of survey results and sales stats could identify the strength of a correlation between satisfaction and sales. That would be expensive to do, but would lead to quantified estimates of the return.

Ultimately, you raise the utility of the software for the user. By increasing the value to the user, you increase their satisfaction, and thereby increase the likelihood that they will encourage other people to buy and use your products.

Increased Word of Mouth Marketing. When your customers become your sales people, you get more sales than you would have without those recommendations. Perhaps comparisons of growth curves for products with varying degrees of customer satisfaction (or varying degrees of “free publicity” – like reviews, blog articles, etc) would yield some predictive insight. Web 2.0 successes have been predominantly built on word-of-mouth. And their growth curves are exponential (as would be the propogation of good words from satisfied mouths). Does anyone know of analyses that validate this?

Conclusion

Design investments yield benefits. The way to measure those benefits is still up for debate. Some folks believe the benefits are primarily internal – we believe that the benefits are external

But sometimes, it happens anyway.

The Cranky PM started a great thread of conversation asking how product managers deal with the job of telling customers (and sales folks) that a feature is not going to be available in the promised release.

CPMs Question

1) What’s your favorite PM breakdancing move for telling (or avoiding telling) an important customer that his favorite feature is not planned for any of the next 3 releases?

2) What about for telling the same thing to a sales droid who claims a multi-gazillion dollar deal is going down the toilet because you don’t have Feature X?

Cranky PM, in Share Your Secret Moves

Several Answers

The readers of that article really stepped up with nine responses. Check out CPM’s article for the details – but here is a summary of the answers. Some of these are bad ideas, and some are good. Usually, the bad ones were written as “I used to…” Our thoughts about each are also included in the list.

• [Bad] Wait until the last minute, then deliver the bad news. We agree – about the only way to lose credibility faster would be to not admit the feature was missing until after the release, when the customer calls to ask.
• [Good] Tell the customer that the scope and priorities have been updated, as soon as the decision has been made. This builds on, or at least sustains a cooperative trust-based relationship.
• [Other] When a customer has multiple features slated for a release, ask them to prioritize them, and try and include them in priority order. This should be happening anyway, before finalizing the schedule – but if it hasn’t already happened, it definitely should happen when the realization occurs.
• [Other] Think outside the box – outsource to get the to-be-missed features included anyway. Deal with the integration hassles internally. This can be good or bad, depending on both your team and the partner.
• [Bad] Re-characterize the release as a “get the basics in place” release, explaining that the to-be-missed features need to come after the basics. There is some validity to the logic behind this (that you can’t really know what you need in detail until you start using the application). But to suddenly discover this after having already committed to a schedule is not good.
• [Good] Restructure the release schedule and add a “next” release to include the to-be-missed features. This is one of the tactics we identify when over-filling a time box.
• [Good] Don’t make promises you aren’t sure you can keep. This is a preventative solution – set expectations appropriately, don’t make promises of content until you near the release. If you’re using iterative development, for example, you might be creating a build every month. You may only be releasing once a quarter to your customer. If you are using continuous integration, and testing effectively, you know you can avoid regression bugs – so you know you can release all of the features from the previous interim builds. Let the customer know that those features have been completed. You’re reducing (perceived) risk for the customer – only the last (and ideally, lowest value) features are still undecided.
• [Funny] If the feature is for sales bigwigs, you’re fired. If the sales person has less clout, make them follow procedure (justify the business value and document it, etc…).
• [Good] Challenge the premise that a sale is dependent upon feature X. Push back on or work with the sales folks to identify the true requirements – not the proposed solution. From what I’ve seen of enterprise software, sales are made based on relationships, not features – and not even price.
• [Other] Distract the customer by emphasizing all of the stuff that is important to them that will be in the release. Softens the blow. Done well, this can really work. If you are implementing the most important stuff (to the market) first, the odds are that it is also the most important to this customer. And by the reverse, the better aligned this customer is to your market, the less effort you are spending on “one-off” customizations. So this redirection technique, when you’re doing everything else right, could also be classified as “put it in perspective for the customer.” When you do that – this is definitely good. If, on the other hand, your priorities are messed up, this can be a bad thing.
• [Bad] Make the excuse that the feature slipped because of “security enhancements” (or other ’sounds more important’) taking priority at the last minute. If this is true, then this is just an example of ‘more important stuff is slipping’ – if it is false, it is lying. Again – the ‘rabbit out of a hat’ thing should not happen in a positive relationship. Maybe this is an ethical gray area for some folks, but we choose not to take this approach.
• [Good] Share the product road map regularly with customers. Use the road map as an artifact to set delivery expectations. That practice is a good one, and is effective in working with sales droids. It doesn’t help with to-be-missed features, however.
• [Good] De-value the feature request and focus on the benefit request. Another good one for the feature-X request. Work with sales to identify the reason why behind the feature. Then incorporate a solution into the product plan.

Really some great answers. How do we mix these into a recipe for success?

Success Recipe

Unfortunately, fire-fighting seems to get more attention than fire-prevention. We tend to get rewarded more for fixing problems than preventing them. This of course leads us to get better at extinguishing fires than avoiding them. But a good software product success strategy is built on fire-prevention, with some contingency plans.

Do the following to prevent problems:

• Prioritize goals (aka needs or problems) based on market value. This is the strategic, multi-customer view of your product.
• Communicate release schedules based on the use cases that enable your customers to achieve those goals. Note that you may be scheduling improving versions of the same use case.
• Share that schedule with your customers. Since you should be continuously refining this plan, you should also be continuously sharing it. Use this road map in discussions with sales folks.
• Make sure that the release dates are not arbitrary. If you’re releasing regularly (monthly, for example) – this is less of an issue.
• Establish expectations that your sales-support activities are market-focused, multi-customer activities.
• When a sales person approaches you with feature X, work to uncover problem X and then assess and prioritize it for the market relative to everything else. There are limits to how quickly you can include it in the development schedule without being disruptive. If you need to be disruptive, make sure it is justified.

And when you do have to slip something from the current release:

• Let the customer(s) who are really dependent upon it know as soon as you suspect.
• Keep them appraised as you make progress (or lose ground). Think of the status report you might give to your manager about a project’s status. Well, you really work for the customers, right? Let them know.
• Put things in context. When you slip something, it better be the lowest priority item. And if your customer’s individual needs are aligned with the overall market needs, this is easier to deal with. When the customer does not represent the market, you have to determine what expenses you are willing to absorb to service the customer. Not every sale is a good one – especially if one customer detracts from your ability to sell to multiple customers, or pulls you away from your strategy.

Another form of slippage is when you re-prioritize future features. Now you’re saying “here are the changes to the roadmap.” The same tell people right away, focus on strategic value, and put things in context ideas still work the best here.

Jonathan Babcock has written a couple interesting articles on preparing for a review meeting. He touches on a couple generic “good ideas” and explores one critical idea in more detail. We focus on that detail – helping participants be prepared to participate – in this article. His articles, and this topic in general are useful to anyone who runs meetings that require participation from attendees – business analysts, product managers, and project managers, for example.

Meeting Planning Articles

We’ve created a bundle of articles at nexus about how to plan and run effective meetings. The bundle includes both of Jonathan’s articles, as well as one of our own on making meetings more effective and a Business Week article on how Google runs meetings.

The bundle is open for collaboration, so other nexus users may add other articles on the topic. You don’t have to be a registered user at nexus to read the articles, so click on over and check them out. Then take a couple minutes to register and rate or review the articles – because the seconds you spend vetting these articles will save others minutes when they are researching in the future.

Summarizing the Main Prep-Points

Jonathan’s main prep points include

• Distributing the material early enough for participants to review and provide feedback
• Circulating an agenda in advance
• Reserve the meeting room & equipment
• Request confirmation of attendance or delegation where appropriate

The other articles include the following prep points

• Defining the goals and deliverables of the meeting up front to set expectations
• Assigning a note-taker or scribe for the meeting

Unprepared Participants

Jonathan raises an interesting issue – when, in spite of your prep work, people fail to prepare for the meeting, what should you do? This is a tough one. If you start with the assumption that only people who need to be in the meeting are actually invited to the meeting, this issue becomes critically important. In many organizations, too many people attend meetings. They are certainly wasting their own time, and often end up wasting everyone’s time. If you are culturally obligated to invite superfluous people to the meetings, that’s unfortunate, but don’t worry about making sure they are prepared. Focus on the people who need to be there and be prepared.

Jonathan writes his advice specifically for requirements specification review meetings – where people’s input is critically important. The issues and advice apply to any of a number of collaborative or approval meetings. They can be generally described as meetings where multiple people need the information, should provide input, and ultimately must agree on the outcome of the meeting.

Don’t Do This

Sometimes you, and everyone else in the meeting needs to take the efficiency hit of dragging along the folks who didn’t do their homework. If you have to, you have to. After the meeting, talk privately with the person who let everyone down, and work together to prevent it from happening in the future.

Don’t attack the person publicly in the meeting. Don’t slam your notebook closed and declare the meeting to be over because someone had something more important to do. That would be just as unprofessional as it was to discover that people were unprepared for the meeting. Maybe that person did have something more important to do. The problem truly isn’t that they were unprepared, the problem is that you didn’t know about it in advance, and couldn’t respond appropriately.

That’s the crux of the issue, and the reason that Jonathan’s advice is good.

Do This Instead

Touch base with the attendees before the meeting. Make sure that everyone who needs to be prepared is prepared. If someone needs to bring materials, make sure they have them ready to go. Work with them to get them completed if you need to. Reschedule the meeting if you need to. Carry on with the meeting, and deal with the missing contributions if that is what is appropriate. You can’t do everyone’s job for them – but you can do your job for everyone. The meeting attendees are implicitly relying upon you to not waste their time. And since it is your meeting, if someone you are relying upon is failing to deliver, it is your responsibility to adapt.

Jonathan offers a couple suggestions to get attendees to prepare for the meeting. His first suggestion is to get their inputs so that you can incorporate them into the agenda. This is a good approach, because it helps attendees develop a sense of ownership in the agenda. Even if they don’t modify the agenda, they are taking some ownership in what you have put together by acknowledging and accepting it.

Jonathan also suggests letting attendees know that you will cancel or reschedule the meeting if you don’t have their inputs a day or two in advance of the meeting. We would approach this with a slightly lighter touch, but we like the base idea. When there are inputs that would crater the meeting if they were absent, work with the contributors to assure that they will have those inputs ready. If they can’t get them done in time, work with them to reschedule the meeting (before the meeting begins) so that you can carry out the meeting with their inputs.

Often, meetings get derailed when people who are “too busy” are simply not conversant with the material to be covered. They don’t have the background they need, or a deep enough understanding to be effective in the meeting. The classic example is a decision maker who needs to know the context for making decisions. When everyone else in the meeting has the context, you’re wasting their time getting the decision maker up to speed during the meeting. Work with that attendee to find a time to help them review before the meeting, or reschedule the meeting, or ask them not to attend it at all. If you have a one hour meeting with seven people, you’re wasting six hours (across the team) by going over the material again to get the laggard up to speed. Wouldn’t it be better to spend two hours in a one-on-one with that person before the group gets together?

To quote Jonathan:

Worst of all, whether it’s completely fair or not, the productivity of a Business Analyst’s meetings are seen as a direct reflection on the his/her organizational and interpersonal skills.

Other Approaches

Craig Brown offers a couple tips in the comments on Jonathan’s second article. He suggests meeting with the leaders in advance of the meeting, and also providing them with printed versions of the materials before the meeting. Craig suggests letting the leaders know that you will collect their “marked up” versions of the documents [before] the meeting. I’ve seen this be very effective with upper managers and decision makers. There’s something about marking up a print-out that engages these folks.

Maybe they are less comfortable with electronic documents (although that is becoming less true every day, and varies from company to company). I suspect that marking up a paper copy allows someone to “scan” more effectively, cross-reference with other documents, and put things in context better. Often the “decision makers” are in a unique position of having fewer details and more context. Giving them an alternative medium for reviewing the docs may help them to put things in perspective more effectively.

What approaches would you suggest?

The material in the presentation is off-topic, but the presentation is so good that you just have to watch it. I found this when researching about openID (mine is http://tynerblain.com/scott.sehlhorst/ – check out myOpenID to set up yours). Consider the open ID thing to be a tangent you might be interested in pursuing today, and will be interested in pursuing soon.

Regardless, you should watch this presentation. The delivery will knock your socks off. The topic is interesting, or perhaps not interesting at all – but delivered so well that you’ll be interested.

This is your third link to it. Last chance.