In the last few weeks I attended high school and college graduations for two of my children and then my own 30-year college reunion. For the graduates, it is a scary and invigorating time for looking ahead and setting new goals (right kids!?). At my reunion it was a time of looking back over the past. For me looking back included some regrets, some things I would rather not remember and poor recollections of people and events, alas, that I have forgotten (you’re getting old Dad!).

Most goal setting exercises also recommend you look back, but from the perspective of several years in the future. For example, imagine you are three years in the future and looking back at your life with a great deal of satisfaction and a feeling of accomplishment. Then ask yourself, “What are the things that happened to make you feel that way?” These are then the goals you should aim to accomplish – new home, new relationship, new business, whatever.

How about you? Have you set good goals for yourself and your software business? In 2011, will you look back and say you accomplished all you set out to do?

Bookmark to:
          

Just saw a press release for a new book Debugging Your Information Technology™ Career published by Elegant Fix Press and written by career consultant Janice Weinberg. I haven’t read the book yet but the press release has some detail that makes the book look interesting.

Whether you believe there is an IT job shortage or not, it is clear employees are being displaced by offshoring. More and more companies are offshoring these days and this book promises to be a valuable resource for those directly impacted by the changes and job loss.

The job loss issue comes up with Accelerance clients when they have an existing software development team that they need to expand with resources offshore. The question is what to do with the programmers you already have in-house? Instead of coding, these U.S.-based employees often become project or product managers if they stay at the company.

This book promises to offer additional choice of career change and growth.

Bookmark to:
          

I just finished reading Wikinomics – How Mass Collaboration Changes Everything by Don Tapscott and Anthony D. Williams. I read Tapscott’s earlier book Digital Capital: Harnessing the Power of Business Webs back in 2000 when it was first published. Wikinomics updates many of the same ideas contained in the earlier book but with a spin on the new Web 2.0 collaborative capabilities that have recently become more popular on the web.

This book is worth a read if you are developing a new Web 2.0 application that seeks to create value from the interaction of your users. Several business models are explored and examples of several well-know companies are given.

The central concept for me is the “business web” or b-web concept which Tapscott & Williams define as “clusters of companies that come together over the Internet.” The b-web concept was introduced in Digital Capital and is also related to the more linear Value Chain concept first described by Michael Porter in 1985.

The examples given focus either on consumer websites like MySpace, Wikipedia and Second Life, or collaborative R&D business webs used by large companies like BMW and Boeing.

On a smaller scale, Accelerance has formed a business web of global partners that develop custom software for small and medium sized clients. You gain access this web through our Outsourcing Jumpstart programs and the global partners are judged on how responsive they are to your needs.

Look for announcements in the near future on changes to our global b-web including an expansion to include many more service providers that serve our clients that develop software.

Bookmark to:
          

In his SD West talk, Jeff Lopez-Stuit mentioned the book Mental Models by Indi Young. It is available both in soft cover and PDF. The book gives you another tool to help figure out what your users are really thinking as they use (or attempt to use) your software.

The book defines a mental model this way.

“To create a mental model, you talk to people about what they’re doing, look for patterns, and organize those patterns from the bottom up into a model.”

As an example, here is a diagram showing a mental model of how most people start their workday:

Mental model with features aligned beneath it.
(Features borrowed from the product category list from Procter & Gamble’s site www.pg.com.) Young, Indi. 2008. Mental Models: Aligning Design Strategy with Human Behavior. New York: Rosenfeld Media. www.rosenfeldmedia.com/books/mental-models/

The diagram shows the steps people take to get ready for work in the morning, or at least how they think about them. The product designer (Proctor & Gamble in this example) can then design products that are consistent with the world-view indicated by the diagram.

“You use the model to understand how your current offerings do and do not support people and devise your strategy going forward. You do this through multiple workshops with team members and stakeholders in your organization, which develops understanding and innovation.”

And in more detail:

“First, reach out to actual users and have a conversation with them, collecting their perspective and vocabulary. Analyze all of those conversations and composite them into a diagram called “the mental model diagram.” Then compare all of the things your solution is supposed to do with the different parts of that mental model diagram. Align them with the concepts that they support. You can do this with functionality just as it exists, or functionality being planned, or you can play around with brainstorming new ideas. When you step back and look at the whole picture with teammates and stakeholders in the organization, you can develop a design strategy—a vision—to follow”

You may not have time for “multiple workshops with team members and stakeholders” and the book offers several short cuts to using mental models:

“If you are designing for software, you can use the complete diagram to derive the toplevel organization of the application, such as navigation or toolbars. Additionally, you can use the mental model as a starting point for interaction design and as a guide for feature definition.”

See Five Disciplines of User Experience Design for a description of Interaction Design.

Indeed, creating a mental model is just one of several techniques you can use to define your user interface and software application in general. This diagram from the book does an excellent job of showing how mental models relate to the other techniques.

Constellation of some user-centered design steps.
(No wonder it seems so hard to figure out where to start!)
Young, Indi. 2008. Mental Models: Aligning Design Strategy with Human Behavior. New York: Rosenfeld Media. www.rosenfeldmedia.com/books/mental-models/

Will you have time for any of these? The author admits that she often lacks the times for scenarios and storyboards:

“I don’t write scenarios because I ordinarily work in quick-paced environments. I explore scenarios verbally with my team. To communicate these scenarios to other team members, we could use comics, storyboards, or videos, but typically we don’t have time. We go straight to prototypes, working directly and verbally with engineers.”

I think going straight to prototypes works if you have direct access to the engineers and you can communicate effectively. That is often lacking with a global engineers operating in a different culture. Therefore documenting a mental model of your user’s thought process can help communicate the goals of your software to your development team.

The bottom line is Mental Models is another tool you can consider using in your situation to discover and capture what your users are thinking. It can help you design a more user interface that has a better chance of delighting those users. However, it is not a replacement for minimal use cases and user interface specifications you need to provide a global software development team.

Bookmark to:
          

A new book on globalization by a Harvard Business School professor concludes that the world really is round. Redefining Global Strategy: Crossing Borders in a World Where Differences Still Matter by Pankaj Ghemawat says you must take the differences between people and cultures into serious consideration if your business is global or using global resources.

Indeed, most clients and companies outsourcing their software development I speak to these days are grappling with cultural differences. Some discussions degenerate into a blame game of dissatisfaction with their offshore programmers. However, there are usually two sides to the story. A poor definition of software requirements on one side runs headlong into a cultural inhibition to ask direct questions on the other.

The book is saying that reports of the “death of distance” caused by the Internet have been greatly exaggerated. It doesn’t mean that global trade in general, or global software development in particular, is doomed. You just need to be aware of the cultural differences and work with them or around them to benefit both sides.

You can read an excerpt from the book on the CIO Insight website.

Bookmark to:
          

Do you ever feel like your offshore programming team just gave up? Have they stopped asking questions or don’t have answers to yours? The problem may not be laziness but cultural.

Over the weekend I finished reading the hugely popular novel The Kite Runner by Khaled Hosseini. It is a story about several boys growing up in Afghanistan before the Russian invasion, how one named Amir comes to the U.S. during the war and then returns during the rule of the Taliban.

At one point near the end of the story Amir consults an attorney named Omar Faisal in Pakistan about adopting an Afghani child and returning him to the U.S. Omar had spent a considerable amount of time in both Kabul and the U.S. and was raised in Berkeley. He explained several times that it was extremely difficult to adopt a child and bring him to the U.S. without any paperwork when dealing with the INS.

Here is a very small part of the story:

“You’re telling me to give it up?” Amir asked, pressing his palm to his forehead.

“I grew up in the U.S., Amir. If America taught me anything, it’s that quitting is right up there with pissing in the Girl Scouts’ lemonade jar.”

That really struck me. Americans just don’t quit! It’s interesting to hear how Americans are perceived in other cultures.

It also reminded me of a personal incident while working with an Indian engineer at one of my startups about 15 years ago. It was late at night and we had to configure a couple of computers for a big demo the next day. I asked the Indian engineer to move a disk drive from one computer to another.

There was some problem like a missing driver or a wrong cable – something that was challenging but certainly could be fixed. But an hour later I found the Indian engineer working on some other small task. “What about the disk drive?” I asked.

“Oh, I couldn’t get it to work.” He said it with no shame or concern. I was shocked!

“So what did you do – just give up?” I was mystified by his lack of urgency.

After all, we couldn’t tell the prospective customer, “Sorry. We had this really cool demo lined up for you, but we couldn’t find a cable.”

Since then that engineer has become a U.S. citizen and settled in San Francisco with his wife and two daughters. His career has advanced quickly and he now works for a major strategy consulting firm in the U.S. We are still great friends and were recently reminiscing about the old days. “Do you remember the time you asked me if I ‘just gave up’ when were hooking up those computers? That really made an impression on me.”

I don’t think my friend would have ever peed in a lemonade jar, but he certainly learned how Americans feel about giving up on a major task that night before the demo so long ago. You may need to gently teach your offshore team the same lesson to get the results you expect.

Bookmark to:
          

I picked up the book Made to Stick by Dan and Chip Heath as a guide to create easy-to-remember messages to use as a resource for the new design of my company website.  They say the most memorable or sticky messages have six characteristics – Simplicity, Unexpectedness, Concreteness, Credibility, Emotional and Stories. You can remember these by using the memorable acronym SUCCESs.

For years I have been intrigued by the concept of a meme – an idea that self-replicates by spreading through a human population because of some set of compelling properties. Urban legends, advertising jingles and other cultural particles somehow spread and then never leave us completely. What if you could create a message for your own product or service that is a memorable as “I wish I were and Oscar Meyer wiener” or spreads as quickly as a story about McDonald’s using earthworm meat in their hamburgers? The book analyzes these phenomenal examples to uncover the six common traits of stickiness. This is the first book I have read that presents a formula to construct sticky messages for your self. It still may not be easy, but at least you can judge the quality of your message in each of these six areas.                                                                                                                    

One reason you may have trouble crafting a memorable message is because we suffer from what the book calls the “Curse of Knowledge”. This curse is an inability to understand why others don’t get what we are talking about. That is, we have so much knowledge about some particular area that we cannot imagine how someone else doesn’t understand what we know. 

A brilliant example of this is from a study as Stanford called the Tapper and Listener game. It is described in Made to Stick this way: 

Tappers receive a list of twenty-five songs, such as “Happy Birthday to You” and “The Star-Spangled Banner.” Each tapper was asked to pick a song and tap out the rhythm to the listener (by knocking on the table). The listener’s job was to guess the song based on the rhythm being tapped… 

The tappers got their message across 1 time in 40, but they thought they were getting their message across 1 time in 2. Why? 

When a tapper taps, she is hearing the song in her head… Meanwhile the listeners can’t hear that tune – all they can hear is a bunch of disconnected taps, like a kind of bizarre Morse Code. 

In the experiment, tappers are flabbergasted at how hard the listeners seem to be working to pick up the tune.  Isn’t the song obvious? The tapper’s expressions when the listeners guess “Happy Birthday to You” for the “The Star-Spangled Banner” are priceless: How could you be so stupid? 

Indeed, the stupidity conclusion is often applied to customers that don’t understand the power of our products.   It is also applied to an outsourced software development team that has limited insight into what you need in your software. Add in the cultural differences and physical distances of offshore outsourcing and the rush to judgment is inevitable.  I started reading this book to help improve my website but then got insight into the software specification process. It’s not that you want to write software specifications that your offshore team will never forget. It’s that you want them to really understand what is needs. The key to this is telling stories.  

The book presents evidence that “mental simulations” improves performance. If you practice something in your mind then you have a better chance of carrying out the activity successfully. When your message is a story, it is a type of mental simulation.  

When you specification includes stories on how your software will be used then the developers have a better chance of developing it correctly.     

Bookmark to: