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)

How to use Web 2.0 in the Enterprise

My friend Anant Jhingran caused some controversy at a VC event last week. Anant suggested that enterprises will demand levels of oversight and control before allowing Web 2.0 applications onto their networks.

Let’s use outside-in thinking to imagine what some of the varied stakeholders in an enterprise / Web 2.0 conflict might look like.

(A) There is a Compliance stakeholder. She worries about things like:

• Adhering to legislation, e.g., copyright law.
• Point in time legal requirements, e.g., when records are subpoenaed.
• Corporate business controls, e.g., internal audit requirements on information flow.

(B) There’s also a Protection stakeholder. She worries about things like leakage or theft of the enterprise’s intellectual property.

(C) In this discussion, folks tend to focus on the IT Systems stakeholder. She worries about things like:

• Load management for the backend servers and networks affected by the Web 2.0 apps.
• Quality management, e.g., what happens if a bug in a mashup application leads to bad business decisions by the users who composed that app.

(D) The Knowledge workers are also stakeholders, who want their Web 2.0 applications. They want things like:

• Flexibility, to do their jobs as they best know how.
• Speed, not having to wait for the centralized IT department to give them the tools to work.
• Fun, to have the power to make a difference in their jobs.
• “What, would you take away Excel next?”

In this debate, as Anant saw, it is easy to say, “you can’t fight the power of the masses jazzed up on mash-ups!” But you can see that there are some serious stakeholder needs that cause nervousness in Enterprises. We should respect these pressures.

So the issue really is how to balance these stakeholder needs.

Here’s one example of how an Enterprise might satisfy all these stakeholders:

1. Compliance in general: inform the users, educate, and trust them. Perhaps allow random, infrequent reviews for internal business controls.
2. Compliance in some specific cases: inform the users, educate and trust them. May have to be more restrictive in some well defined specific cases.
3. Protection: inform the users, educate and trust them. Perhaps provide tools, e.g., meta-data on levels of risk in the materials they compose. Maybe also allow for random, infrequent reviews for internal business controls.
4. IT Systems: expect IT to self-detect loading issues. For quality, inform and educate the users, perhaps provide tools to help them.

It is difficult to imagine this as a binary situation. The last thing businesses can afford to do is ignore or prevent the innovation of their own employees seeking to do the job better, faster, and in a more fun fashion.

There’s a lot of work – and risk – for enterprises in the balanced approach. What could we (the community of technology professionals) do to make it safer or easier for enterprises to get excited about Web 2.0?

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

The organizations we serve are changing… are you ready?

CIO Magazine recently published a Q&A with James P. Andrew, titled “The Secrets of IT Innovation.” In this, Mr. Andrew leads out saying, “The biggest problem in innovation today has to do with money. In other words, how do I generate return on my innovation spending?” Exactly!

In fact, surveys say that two out of three CEOs expect to drive fundamental change within their organizations in the next two years. Often times this includes organization change. Today’s organizational structure may even be misleading – if the business hopes to use new applications or products to change the way they do business in some significant way.

So what’s the approach to handle this? “Know what’s on the agenda of business leaders and what goals for the business they have.” Right again!

There’s just this major rub: how do you translate the advice into some practical actions?

The first step is to understand who you’re serving: the stakeholders. Your line of business executives are the first folks you might think of – they need to be satisfied with the app, as it is their business that is affected. But they’re not your only stakeholders.

You also have to consider the end users, the IT operations folks who run the app, or maybe even the architecture team that mandates a given approach. In addition, if you use vendors to build or run parts of your environment, then they too are a stakeholder group.

Focusing on stakeholders and developing a clear understanding of their goals is the very essence of outside-in thinking. It allows you to maintain focus throughout your product’s development, and it makes clear whom you must satisfy to achieve business success.

A good next step it to think about organizational context. Your work as a developer is affected by the structures, cultures, and initiatives of your line of business’ (or customers’) organizations. You need to understand these structures because your stakeholders will make decisions that reflect their organizational contexts, and they probably want to use your applications to effect further changes.

For example: is the application roll out to be highly distributed (each regional office runs it themselves), centralized (run from the top), or federated (run regionally but also managed from the top)?

The outside-in development advice is: know your stakeholders, know their needs. Easy to say, but the work beneath the words is significant. I’ve captured some solid practices in my book on this, and would welcome comments from folks who have other experiences to share.


(Image attribution: http://www.freefoto.com/imagelink/?ffid=04-28-36&s=s)

How to prepare for the next revolution in IT (Part 2)

In Part 1 of this topic I talked about the past. How the 1st revolution of IT occurred as empowered line of business workers took control of their data and analysis because their PCs and office software allowed them more flexibility, agility and speed than they’d seen from their centralized IT shops.

The path was set, which is why Chris Anderson uses the phrase "just one step above Building Maintenance" to describe CIOs today.

The 2nd revolution is headed our way, and it is all about access to information and the ability of knowledge workers to integrate and operate on that information on their own.

Think about mashups. Today they’re like a not very user friendly spreadsheet program. (Look at the first VisiCalc screen.) But they’ll become as easy and ubiquitous as Excel very quickly.

So here we go again. After all, 26 years after the PC, line of business managers are still impatient with the agility and speed of application development and deployment out of the IT shop. In this 2nd revolution, there’ll be more power for the knowledge worker to build the ad hoc mashup needed to improve the productivity, effectiveness, or enjoyment of her task.

With this, more pressure on IT to support the new paradigm even as they paint themselves into the box of less relevance and more commodity provider. Building maintenance indeed.

The prepared IT teams will get ahead of this curve. They’ll embrace Info 2.0, seeing it as a way to outsource some of their app development to their own internal clients. The knowledge worker knows her business process better than most anyone else – why not let her be the developer of choice?

Most importantly: prepared software teams will figure out who their stakeholders really are, and precisely what is needed to help those folks succeed in their roles.

How about the unprepared teams? They’ll confirm their (poor) position in the business hierarchy of under performing firms, and lose their heads in high performing firms. Don’t underestimate the impact that well designed software can have on transforming a business.

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

Free book excerpt: "Outside-in Software Development"

The September 20th 2007 edition of JavaWorld contains an excerpt of our book. Check it out!


(Image attribution: http://www.javaworld.com/index.html)