Posts Tagged ‘information technology’

A PC game-development environment for kids

Wednesday, January 13th, 2010

koduMy wife pointed out this item from the Wall Street Journal today, announcing a project called Kodu from Microsoft Research. Kodu is a graphical programming framework that kids can use to create their own video games. I had spoken to her about Fred Wilson’s recent post bemoaning that school computer classes are teaching kids word processing and spreadsheeting rather than programming. We’ve also talked a lot about how limited the opportunities are for kids to use their creativity. Kodu seems to have the potential to help in both areas.

Our sons (8 and 6 years old) want to be video game designers when they grow up. We’ll download Kodu, and perhaps they can get a head start on that starting, like, tomorrow!

You can download the Kodu PC development platform from a link in this Kodu blog post.

Times article on open source eludes logic

Monday, November 30th, 2009

This article in the New York Times (”Open Source As A Model For Business Is Elusive“) suffers from the same blinkered viewpoint and desire to create a story out of thin air as the recent WSJ article on Wikipedia (”Volunteers Log Off as Wikipedia Ages“). Doc Searls today hammered at the WSJ article, and now I’ll take my shot at the Times piece.

Ashlee Vance writes in the Times:

…there is an open-source alternative, and usually a pretty good one, to just about every major commercial software product. In the last decade, these open-source wares have put tremendous pricing pressure on their proprietary rivals. Governments and corporations have welcomed this competition.

Whether open-source firms are practical as long-term businesses, however, is a much murkier question.

then this:

“There’s only one company making real money out of open source, and that’s Red Hat,” said Simon Crosby, the chief technology officer at Citrix Systems, which acquired the open-source software maker XenSource for $500 million in 2007. “Everyone else is in trouble.”

and this:

Many of the top open-source developers are anything but volunteers tinkering in their spare time. Companies like I.B.M., Google, Oracle and Intel pay these developers top salaries to work on open-source projects and further the companies’ strategic objectives.

finally this:

The larger technology companies have tended to buy these one-trick ponies for strategic purposes. With its core server business declining, Sun hoped it could piggy-back on MySQL’s momentum with Internet companies. In SpringSource, VMware acquired a company that had cultivated deep interest with software developers and helped VMware diversify beyond its virtualization roots.

The story’s lede says that open-source business success is elusive. Yet over and over again in the text Vance states that large companies viewed open-source providers as strategic – strategic enough to pay hundreds of millions of dollars to own them.

If I were lucky enough to build a business that a company would pay several hundred million to buy from me, I would consider that successful.

What Vance may be saying is that building a long-term standalone business atop one open source product is difficult – hence, companies like MySQL, SpringSource and XenSource selling out. I would counter that building a long-term standalone business with one product of any kind is also difficult. Open source has little or nothing to do with it.

Furthermore, the value of open source platforms (apart from, of course, the value to end-users) is the economic value to the platform’s ecosystem of developers, integrators, etc. Part of the benefit of open source is that it breaks down barriers of scale, by allowing small developers to build big products using open source as a basis.

If Vance would like to calculate the profitability of corporate ventures dependent on open source products (such as those from IBM, Accenture and countless other companies), that’s a story I’d like to read.

Video review of Andrew McAfee’s “Enterprise 2.0″

Monday, November 30th, 2009

enterprise2.0TRANSCRIPT:

We’re here today to talk about “Enterprise 2.0” by Andrew McAfee. He is with MIT, used to be at Harvard Business School. Just switched over a couple of months ago. He writes an excellent blog on IT and business, that I’d recommend you read if you haven’t come across it yet. And so, he’s just produced his first book. To explain the title, Enterprise 2.0 is a term he coined to refer to using web 2.0 tools like Flickr, Facebook, YouTube, Twitter and similar tools in a business context.

The book is a lot like a recent book, “Groundswell,” that explained to general business people how social tools affected customers and markets and how to use those to communicate and listen. Communicating from inside the business to outside. “Enterprise 2.0″ performs a similar task, focusing on using those tools inside the business, more for collaboration and tapping the collective intelligence of employees. And so it takes this marginal topic and moves it to a general management-type discussion. Which I think is really important, to get it out of the IT discussion into the management discussion.

So as part of that objective he does a really good job of explaining how these tools work and also what ties them together because if you think about tools like Flickr or YouTube or a blogging platform or a messaging platform or a wiki there are a lot of differences among those but he’s tied together the common threads, using an acronym called SLATES (search, links, authoring, tags, extensions and signals). Signals, for example, like RSS that allows people who follow these platforms without having to log on to them every single hour to see what’s changed.

Another important part of the book is in putting the different tools into a context in terms of how useful they’d be for different organizational problems. He uses a bullseye metaphor focused on the strength of ties between colleagues to explain that. At the center of the bullseye are strongly-tied colleagues meaning people who work together in the same department, in the same location, all the way out to the edge of the bullseye. meaning colleagues who have no relationship at all. Different tools apply at different levels of the bullseye. In the center, people with strong ties would use tools like wikis, or collaborative development tools, like Google Docs.

Midway out the bullseye are colleagues with weak ties. People who know each other but don’t get together often, who don’t talk often, but would like to keep apprised of each other’s activities for the purposes of sharing knowledge, best practices, identifying solutions to problems, and so forth. For that ring of the bullseye, Facebook-like tools are very useful.

At the outer edge of the bullseye, where colleagues have no relationship other than that they work for the same company, a prediction market is a useful tool, that gathers people’s guesses about the possibility of certain things happening like a certain sales volume being reached or likelihood an innovation will succeed in the marketplace and aggregating that information to get a better answer than any individual would come up with themselves.

He doesn’t go overboard in terms of enthusiasm for how great these things are and how it’ll change companies overnight, and he has a pretty clear-eyed view of how difficult it is going to be to bring these tools to wide use. It just takes a long time -and he dwells on that at some extent – how long it takes for revolutionary innovations to take hold, and he doesn’t think this is any different, though he is optimistic that it’ll happen eventually.

And finally in the book he talks about kind of different management models or practices that work well with these tools, and by contrast he talks about typical Model 1 behaviors which are more command-and-control type behaviors, self-protecting behaviors and less-collaborative behaviors, which don’t go well with these new tools. To really utilize these new tools, people have to adopt what he calls Model 2 behaviors, which are collaborative, not so much focused on self-protection but looking out for the best interests of the company. Quite a different model than what most people have seen where they work. And I think that heaps underline the challenges in getting these systems adopted and in wide use.

It’s an excellent book, very well-organized and well-written. It takes an important topic and brings it into the mainstream. I really enjoyed it and I think you will too.

Learning from failures (and successes) requires different IT systems

Tuesday, September 1st, 2009

I’ve been working recently with a colleague tasked with improving his company’s project management outcomes (I was going to say processes, but on thinking about it they’re asking him to improve the performance and results).

He’s focusing on lessons learned, as you might expect. The company has done lots of projects; surely there are many lessons within those projects that could help improve things going forward? And there are. But my colleague has found that the inability to effectively capture and share these lessons prevents the organization as a whole from getting much if any value out of their past experiences.

[This Harvard Business Review article emphasizes why project management, in particular, is prone to repeating the same mistakes over and over again.]

I was thinking about my colleague as I was reading this recent article in “Strategy + Business” entitled, “Are You Killing Enough Ideas?” by Zia Khan and Jon Katzenbach. The article discusses innovation, not project management, but this section in particular resonated with me and spurred my connection with project management lessons:

…When there is an ineffective balance between formal and informal structures, it often shows up as an inability to manage bad ideas effectively. After a formal decision has been made to advance some ideas but not to pursue others, the company expends considerable effort to plan the next steps for the winners. But no one thinks actively of planning next steps for the losing ideas, to put them to rest, free up their supporting resources, and (ideally) identify and share any lessons or insights gleaned from the experience.

One quibble with this otherwise excellent paper: why is identifying and sharing lessons and insights from experience an “ideal” situation?

Significant corporate initiatives, whether they are innovation ideas or IT projects, are expensive in capital, resources and opportunity cost. The experience, whether the project is ultimately a success or not, is hard won and valuable. It should be mandatory to capture and share these lessons and insights.

There are several barriers my colleague faces in trying to institutionalize the creation and use of lessons learned. “Let’s move on” is one of the most pernicious ones. After a difficult project, people are inclined to look ahead rather than backward, to forget difficult or painful experiences rather than mine them for lessons. (In many cases, as I’ve learned in nearly two years of working with The Mistake Bank, lessons sometimes emerge years after an experience.) Organizations, of course, in their eagerness to place blame, facilitate people’s instincts to hide or blur what happened in the case of a failed project.

My colleague’s company has a very open and positive culture; they are more equipped than most companies at overcoming the reluctance to share. Yet they still face a significant obstacle: their information systems are not up to the task of gathering, sharing, sorting and consuming lessons-learned material.

They capture lessons in Word forms and documents, and store them in file folders on a shared drive. And they are not surprised when no one can find anything. Dumping valuable lessons on a shared drive may have a slightly positive use for whoever writes the lessons down; at least that person learns a bit more from the retelling. But certainly it’s of no use to anyone else.

Lessons-learned need enterprise 2.0-type tools that capture narrative data, signifiers and tags; allow users to “like,” pass along, add to, and otherwise annotate original stories; and browse through, search and connect related stories. That’s what my colleague needs, and that’s what every organization that wants to “ideally” learn from both good and bad experiences needs as well.

Customers are talking: retailer Zara relies on ground-level “specific knowledge” to forecast sales

Tuesday, July 21st, 2009

Andrew McAfee’s blog is a great place to learn about how businesses can gain competitive advantage by their use of IT. But yesterday he took a left turn and discussed business situations where data crunching is not helpful to decisionmaking, and I loved it.

In “When Information is NOT the Answer,” McAfee takes issue with Don Sull’s assessment of fashion retailer Zara’s “fast fashion” approach, at least when it comes to data-driven decisionmaking. Writes McAfee:

Sull stresses that “Zara’s business model demands good information,” which is certainly true. But my work with the company (see this Sloan Management Review article and this case study) revealed something I found fascinating: Zara succeeds in large part because the company makes comparatively light use of market data and sales information, at least as these terms are commonly understood in the retailing industry.

McAfee further explains the difference he sees between Zara and other retailers’ use of information:

The decisions about which clothes should to go which stores at what time(s) are probably the most important decisions made by any large apparel retailer. Most chains make them by collecting large amounts of daily sales data from stores, combining it with other hopefully relevant information, then applying a variety of statistical techniques to generate a forecast – a quantitative prediction about what will sell. This forecast is used to push the ‘right’ items – the ones predicted to sell — over time to each store.

Each retailer forecasts differently, of course, but I find their techniques broadly similar: they all gather lots of data, analyze it centrally, then use the resulting predictions to determine shipments to stores. In this model, the stores themselves have fairly limited roles: they are expected to record data accurately and send it promptly, then do their best to sell whatever headquarters decides to send them.

This seems sensible enough, and it also seems logical that as the business world gets more and more turbulent more and more supporting data will be required. This data will need to be acquired, analyzed, shared, and interpreted with ever-greater velocity, requiring ever-bigger computers, ever-faster networks, and ever-more-quantitative decision makers.

But Zara, operating in an intensely turbulent environment, does something totally different. The company doesn’t really generate a store-level sales forecast at all. Instead, it relies on its store managers to tell headquarters what they think they could sell immediately at their locations. Headquarters then gets as many of these clothes as possible to the stores as quickly as possible.

What’s more, the store managers are given very few quantitative or analytical tools to help them make their short-term predictions. They rely largely on intuition and experience, on walking the floor and talking to customers and employees.

I think this distinction between high-level numbers (what McAfee calls “general knowledge”) and the ground-level view of the customer needs (”specific knowledge”) is very important. In order to gather and understand specific knowledge, it’s necessary to be very close to the customer, “walking the floor and talking to customers and employees.”

Small retailers have always worked this way. When I worked at the local hardware store during high school, each department had a buyer who looked at stock levels, assessed what was selling, took the season into account, and placed orders weekly.

For large retailers, the fashion has been, as McAfee writes, to gather scads of information “Numerati“-style and make central purchasing and stocking decisions. Overreliance on this had a negative effect on one large store: Home Depot.

So it’s good to learn that at least one mega-retailer is using high-level number crunching judiciously, and relying on the folks closest to the customer to set ordering levels at each store. However, I think even they can do better.

As McAfee describes it, Zara “relies on its store managers to tell headquarters what they think they could sell immediately at their locations. Headquarters then gets as many of these clothes as possible to the stores as quickly as possible.” In other words, headquarters’ visibility into the “specific knowledge” in the store is limited to the managers’ forecasts.

I wouldn’t propose changing the ordering process, but I do think Enterprise 2.0 has a role here in sharing specific knowledge more widely. Information in the form of customer or employee narratives (generated by a simple prompt–”what was the most interesting thing that happened today?” or “tell me about your experience today” for example) could be captured at the store level and uploaded to a story-bank accessible to all Zara employees–especially those at a remove from the direct customer experience.

Through tools like commenting, scoring, nudging, sharing, etc., those narratives can inform a much broader base of employees what customers are doing and how they’re reacting to the products on the shelves. [I have been trying out a very cool open-source story-banking tool currently in alpha test that would fit this need perfectly.] This would provide a great service to the company by “bringing the outside in” (John Kotter’s phrase) and enabling all employees to make decisions with much deeper customer insight than they now possess.

This narrative data can supplement the high-level numbers, essentially combining McAfee’s general and specific knowledge to provide better insight into customers–for product, marketing and customer service purposes.

Related posts:
John Kotter on corporate change and “bringing the outside in”
A competitive advantage: employees who talk to customers
Time to listen to front-line employees

Desperately needed: a killer front-end to integrate all online comms channels

Monday, July 13th, 2009

I got into a neat discussion with one of the users I interviewed for the Listrak customer research project a few months ago. Her company does a lot of email marketing, but in addition they have a Facebook fan page and a Twitter account. As a result, their communication channels have multiplied, and now they have to manage customer communications over several corporate (and customer) identities.

What’s true with companies is also true with us plain old people. I have messages coming from Facebook, LinkedIn, Twitter, Blip.fm, Friendfeed, Plaxo, Skype, Meetup, Ning (4 groups) and, oh yes, email (4 accounts). If I want to respond, I by and large need to use whichever app the message came in on. This means a dozen separate communications channels… and no way to integrate my dialogues with one friend over all these channels.

So, a user’s plea. Who can create a unified client that can integrate these channels into one stream, where the same person’s email, Facebook messages, Tweets, etc., are collected together, where I can respond and the app can translate the message into whichever protocol is needed? [Some candidates I can think of: EmailcenterPro, CoTweet, TweetDeck - each of these companies is solving a part of this problem.]

(Just imagine how valuable that would be to a company trying to converse with its customers, such as the Listrak user I talked to?)

IT is a key weakness of joint ventures… and any collaboration

Tuesday, March 31st, 2009

Strategy + Business, the Booz & Company journal, just published an article discussing the results of a survey on information technology in automobile joint ventures. Booz’ conclusion: JVs systematically underinvest in IT because of cost pressures, difficulties in standardization and security.

Please read the article and come to your own conclusions. For me, it brought up an issue I’ve faced a lot recently–the IT disconnect between a company’s direct employees and the consultants it uses. When I’ve been in collaborative projects with companies, the lack of easy access to scheduling programs, file stores, and document management systems has been ubiquitous. The IT groups don’t want some temp to take up a lot of their time with nonstandard hardware, unknown applications, and other difficulties. So, they leave it up to the outsider to get along without the proper tools. Ironically, free or cheap off-the-shelf tools like Ning, Google Docs, Basecamp, etc., are far superior collaboration tools to those provided by the corporate IT shops I’ve worked with.

Companies’ value chains are becoming more and more unbundled. There’ll be a great deal more difficulty collaborating with partners as that happens. Corporate IT groups will have to radically change their approach to remain relevant.

Related:
Corporate IT Maximum Security is Damaging Innovation

Customers are talking: The Eureka Button

Wednesday, January 21st, 2009


I was talking to Cynthia Kurtz once and she mentioned, “If I were developing a piece of software I would always want to put a Eureka Button on every page.”

A Eureka button is this: if while using the system a user just figured something out that others might benefit from, he/she would click the button and be presented with a page where she could enter:

What Happened?

Where does this apply?

When should people read this story?

This input and information about where they were in the system (page & data) would be uploaded to a database. The database can be searched for patterns or browsed periodically, looking for bugs or unexpected uses of the system.

It’s easiest for me to think about the Eureka Button in the context of enterprise software. Having worked a lot with CRM systems for telephony, I know that these systems have hundreds of user pages, with a virtually infinite number of paths through the system.

In these environments, product managers may know in theory how people should use the system. But their knowledge is quickly overtaken by experienced users, who learn how to apply the system to their jobs, often finding tricks or shortcuts to make the system work better for them. (”Eureka! I just figured out that if I dummy out some data items, I can capture information & save information from a prospect before they decide to make a product purchase. If they call back, I can look them up by their phone # and I don’t have to start all over again.”)

In this situation, a Eureka Button has great value for the product manager and the users. Product managers can learn about difficulties users have and how they overcome them. The tricks can be incorporated into the product, or deficiencies addressed. Users can learn from each other–perhaps Eureka Button entries can be blogged automatically and read by other users, dispersing tips and tricks and encouraging others to share their stories.

I can’t even begin to catalog how a Eureka Button could benefit consumer sites, where (especially recent) products follow an emergent, iterative development approach and patterns of usage can affect the entire purpose of the product (e.g., Twitter). There are people much better suited than I to discuss some of these implications. If you’re one of them, please let us know in the comments how the Eureka button could be used with these products.

(In searching for prior references to a “Eureka Button,” I discovered this NY Times article from 2004. The article mentions that “‘It’s amazing how many people there are who find pleasure in sharing the little discoveries they make.’” The article focuses on undocumented features in PC software and in consumer electronics. The article references a site that publishes user stories of hidden Windows features.)