Moved! Please update your links...

I've moved from blogger.com to a WordPress -based web site. Please update your bookmarks and syndication feeds:

Bookmark: http://outside-in-thinking.com/

Syndication: http://outside-in-thinking.com/?feed=rss2


(Image attribution: http://www.flickr.com/photo_zoom.gne?id=1451038457&size=l; RBerteig)

Can outside-in fix the bottleneck of stakeholder misalignment?

Jim Johnson argues that stakeholder alignment is a major bottleneck on innovation. As Jim puts it, this problem leads to “100’s of billions of dollars a year of waste” – yikes!

Can outside-in development help fix this stakeholder misalignment nightmare? You bet. But first, we have to be very clear on the different aspects of alignment.

As Jim points out, balancing ad hoc views of executive goals against desired outcomes is painful and costly. This is a good example of why John Sweitzer and I started our book with a focus on stakeholders – identifying them and understanding their goals. Within a company, stakeholder alignment can be used to help teams work toward a common goal.

Another important aspect of stakeholder alignment is to emphasize the need for developers to stay in sync with where their stakeholders want to go. What does the business hope to achieve when it deploys your software? The better the alignment, the more relevant the software.

We introduced the need to understand the organizational context in which your software will be used. For example, capabilities that are valuable to a centralized firm are different from those needed in a decentralized environment. (See Chapter three.)

Jim’s told us how important it is to elevate “general business awareness of the overall consequences of the bottleneck of stakeholder alignment.” He’s quite right, and outside-in thinking can go a long way to help. Looks like we need CIOs and CFOs getting into outside-in thinking as well as their developer, product manager and marketing colleagues.

(Image attribution: http://www.flickr.com/photo_zoom.gne?id=803997580&size=m; by paparutzl)

When can we throw the release party?

En route to a client visit today, I stopped by the IBM Research Labs at Hawthorne, NY to learn about some cool new projects and to give a brief talk at the 2007 SWEFT conference - an internal, IBM Academy of Technology -sponsored conference - "Software Engineering for Tomorrow."

As you'd expect, my talk was about outside-in development. One of the topics covered today was when to celebrate success on a development project. Hint: not when you release the code!

Everything we do on a software project up until product ship is internally focused. (Let's for the moment ignore all the iterative client involvement and such.) So to get all excited about shipping the code kind of misses the point of being an outside-in thinker. Instead, the meaningful stakeholder-centered activity occurs after the software ships.

That's when our early adopter clients get to really throw the code around, and presumably put it into production. Their success is the true measure of our success.

That's why I advocate picking some simple, outside-in success metrics early on in a project. For example: let's have four clients successfully in production in the first 60 days post release.

Once we hit that success milestone, it really is time to celebrate!

(Image attribution: www.flickr.com/photo_zoom.gne?id=495408726&size=m; diametrik)

Jason's right: the buyers aren't the users

By Jason, I mean Jason Fried. His blog entry, "Why Enterprise Software Sucks" was a (deserved) wack in the face for those of us in the vendor space.

His answer to the question?

"The people who buy enterprise software aren’t the people who use enterprise software. That’s where the disconnect begins. And it pulls and pulls and pulls until the user experience is split from the buying experience so severely that the software vendors are building for the buyers, not the users. The experience takes a back seat to the feature list, future promises, and buzz words."

Well, exactly!

Jason’s point that, “The people who buy ... aren’t the people who use...” is the crux of the issue. As outside-in development practitioners know, there are four groups of stakeholders who dramatically affect most SW products. They are:

- the principals or business sponsors; these are the executive purchasers.

- the end users (who too often get stuck with hard to use UIs).

- the partners; these can be the enterprise IT shop operations folks, or VARs or ISVs who have to deal with the product too.

- the insiders; the folks inside the vendor software shop who have their own goals. Such as financials, architecture guidelines, process models, and the like.

(You can read more about outside-in development in the article in JavaWorld, or take a look at some of the work that Scott Sehlhorst has done to expand on outside-in development notions at TynerBlain.)

Back to Jason's post. Lots of people commented - he clearly hit a hot button. A couple of folks also pointed to the checklist mentality so prevalent in development. All about checklists, not about helping stakeholders meet their goals (especially end-users). Yes, all too often, development prioritization is all about feature lists.

One approach to deal with this is called “consumability.” The idea is to give teams credit for full fledged line items that serve to make a product more consumable to clients. This could mean easier install, better screens, easier debug or fix application. Ultimately all of these items and more.

We’ve put in place a metrics model (because SW development shops tend to be metrics driven) to keep the focus and to indicate release-to-release improvements. This is also a fundamental part of outside-in development.



(Image attribution: http://www.flickr.com/photo_zoom.gne?id=422215562&size=m; by Helico)

WSJ's "Inside Out" article hits the enterprise control issue

Today's Wall Street Journal (this link requires a subscription; see page R5 in the hard copy version) offers an article titled, "Inside Out: employees often use unauthorized technologies at work. Does that compromise security? Or enhance productivity? Two experts debate the issue."

The position of hard limits on employee capability was taken by Tom Tabor, CIO for Highmark, a Pittsburgh -based health insurance firm. The opposing view was taken by Douglas Merrill, CIO at Google.

I'd engaged in some friendly banter with Stephen O'Grady at RedMonk on this general topic. I'd also jumped to be something of a voice of reason for Anant Jhingran in his debates with the VC community on this topic.

Looks like I hadn't fully appreciated the degree of commitment by IT executives to keep the invading legions out of their shops!

As Mr. Tabor wrote, "We do not allow access to any Web-based email, instant messaging or Wi-Fi access. We do not see material impact to our employees by restricting access to these."

Of course, as Google's Mr. Merrill points out, "Choice is key - for good and for ill. ... changes makes our jobs in IT harder. We can't put that genie back in the bottle..."

Is it even possible to build a mid-ground for folks like Mr. Tabor? One that would enable them to attain all the privacy and compliance requirements they simply must address -- and yet begin to make some collaboration and community technologies available to their teams? How might we do this?


(Image attribution: http://www.flickr.com/photo_zoom.gne?id=184140074&size=m; by Luiza)

Panel retrospective: “Outside-In Technology and Innovation”

At the Information On Demand Conference on Thursday, I joined moderator Chris Anderson, with colleagues Jeff Jonas, Anant Jhingran, Carol Jones, and Hamid Pirahesh, to discuss “Outside-In Technology and Innovation.” The following, although not a transcript of what I actually said, is what I had hoped to say.

Imagine a graph with a line representing the gap between IT and line of business users over the past 40 years. That gap has always been there. But the IT Revolution 26 years ago caused a spike so significant you have to put our imaginary graph on log paper.

That 1^st IT Revolution came from the introduction of PCs, along with VisiCalc, Lotus 123, and eventually Excel. Knowledge workers could take control of their business analysis to get the agility they needed to do their jobs. Soon there were departmental LANs of PCs, and content and data began to live in a formal way outside the scope of the IT shop. This fundamentally changed the roles of CIOs and IT shops.

Today, we’re already experiencing the 2^nd IT Revolution.

But in this one, IT teams are – for the most part – like lobsters in a pot of cold water – slowly coming to a boil and not realizing that we’re in hot water. Because we aren’t addressing Web 2.0 and social networking as what they are: the instruments of the new Revolution.

This 2^nd IT Revolution will take that gap line up again on the log paper graph in ways we can’t even imagine today.

What’s happening instead is a continued tug of war between IT and LOBs. Already, end users can use mashups to dynamically compose new ad hoc applications. And some teams find it more effective to use FaceBook to collaborate with their colleagues and business partners than the structures their IT teams put in place.

What’s the IT response? Do we just say, “Let’s shut that stuff down?”

Tug of war won’t help.

We need tool kits.

Tool kits in several categories:

Information On Demand so we can get information and knowledge out to our business knowledge workers to enable them to use and reuse that information to be nimble and effective.

Enterprise Content Management so we can deal with the requirements of compliance and business process efficiency and still empower departmental exploitation of that content.

SOA so we can build more agile core services and expose services to empower new Web 2.0 applications.

And a different way of building IT, ISV and Vendor applications. One that recognizes the full suite of stakeholders, their often competing needs, and resolves them effectively – that’s what I call “Outside-in Development.” Outside-in thinking helps us find the middle ground between tight IT control and anarchy.

If we stay in tug of war mode, we’re going to be at odds with the knowledge workers of the 2^ndIT Revolution, and my money is on them.

But IT teams can co-opt the 2^nd IT Revolution and make it our own. We can dramatically improve business agility, client satisfaction, and business success. And, by the way, have more fun too.

(Image attribution: “The Death of Marat,” by Jacques_Louis David.)

Don’t abandon the invisible stakeholder

This blog post was published on TechRepublic on October 10th.

There are many stakeholders in a new software product, be it commercial off the shelf or an in-house application. By stakeholders I refer to the people who will ultimately engage with and benefit from the product.

Outside-in thinking tells us to be explicit about whom the stakeholders for our projects, and knowing that, to gain a clear understanding of their goals. There are, for example, at least the business line managers, the end users, and your own architecture and standards teams. But some stakeholders seem invisible to all but the most cautious development teams.

Who are these discarded souls?

Read more at blogs.TechRepublic.com...


(Image attribution: http://flickr.com/photo_zoom.gne?id=355981408&size=s, by pedrosimoes7)