outside-in-thinking

My colleague John Sweitzer has started to use a new explanation of the concept “user stakeholder” - that is:

User stakeholders are those that will be able to deliver more to their business once they are using the deployed software.

This is a more business oriented way to say that the software we build should make the users heros in their organizations.

(Image attribution:  http://www.flickr.com/photos/ niosh/2492840578/sizes/s/ by NIOSH - Nat Inst for Occupational Safety & Health)

Share This

IT business analysts can learn from the recent US presidential election:  what message type appeals to stakeholders, and what turns them off.

From an outside-in thinking view, voters are a key stakeholder for candidates (along with campaign staff, volunteers, donors, press, etc.).

This outside-in analysis of the election transcends personal preference - of which messages one would prefer to have succeeded - and instead looks at how the messages were perceived (based on my view of the election results).

In a nutshell, we can surmise that stakeholders prefer enabling messages to restrictive ones. Talk with the line of business about opening up new capabilities, and not about preventing actions.

This is reflective of Obama’s “yes we can” core message, followed up with “but it will not be easy and we’ll all have to do our part to succeed.”

Compare this to the core messages of McCain’s campaign:  prevent  women from addressing the complex moral issues of abortion on their own, prevent gays from holding legal partnership rights equivalent to straight couples, etc.

Independent of your personal view on these issues, it should be clear from both the election results and other polling that restrictive messaging (just like negative campaigning) isn’t a winning play.

We can also learn something about fundamental policy changes.   Here McCain’s messaging on Iraq was to continue the occupation in order to save face for the US (reminiscent of the Vietnam stance that pulling out wasn’t manly).

Obama’s messaging was that the occupation was a result of inaccurate information (if not inappropriate statesmanship) and that it is thus perfectly acceptable to remove troops without impacting the nation’s machismo.

I’ve seen several situations where IT shops continue to invest in failed applications because a directional change is perceived as too dangerous.  And it may well be:  once you’ve convinced the business to support a particular direction, going back to say “oops” is definitely career limiting, if not job ending at that firm.   On the other hand, it may be possible to explain the failed information that got you there, or the new information that motivates a change.

This is a delicate balance:  as delicate as Obama’s messaging that he is patriotic, that he does respect and admire the US military at the same time he wants to admit that the administration’s decision making and policy that got them into Iraq is flawed.  As seen in the election, done well, this can work.   Especially when the stakeholders can perceive on their own that the current direction is sub-optimal.

IT’s relationship with lines of business is complex.  Think of the line of business, at least occasionally, as an election stakeholder:  you want to win their vote, or even recruit them as volunteer campaign staff for you.  Give them a message of hope - of how to succeed in the business - and avoid emphasizing restrictive capabilities which are less likely to enthuse them.

(Image attribution: http://www.flickr.com/photos/ dannysullivan/292150487/sizes/s/ by dannysullivan)

Share This

One of the announcements at IBM’s Information OnDemand conference this week is particularly relevant to outside-in thinkers.  That is, Agile ECM.

ECM means enterprise content management.  What’s that?  AIIM (the association that thinks most about this topic) defines it as “the technologies used to capture, manage, store, preserve and deliver content and documents related to organizational processes.   ECM tools and strategies allow the management of an organization’s unstructured information, wherever that information exists.”

In other words, if you want to manage content (e.g., images, documents, emails, instant messages) to save money, to automate business processes, to automate compliance activities, or do electronic e-discovery for legal cases, you would use an ECM solution.

So what’s that have to do with outside-in thinking?

The Agile ECM announcement includes an important new capability for building content-centric business process models.   When a client re-engineers their processes to automate them with ECM technology, they face a very typical outside-in thinking problem:  line of business leaders understand their business processes, and have to work closely with business analysts and IT staff to achieve that automation in production.

So let’s say you’re designing the user interface that your clerks will use to process purchase orders.  You can describe the use case to your business analyst, and in some amount of time, you’ll get back a visualization of it, a prototype, or deployable code.  You’ll validate it (and typically tune it up to get closer to how you’d like it to look and feel), and then perhaps go through another cycle of line of business to IT collaboration.

This can take a long time.  And the collaboration part often doesn’t work as well as one would hope.

IBM’s Agile ECM uses mashup technology to allow business analysts to drag widgets from a palette and wire them to each other.  With about 15 minutes of training, a business analyst can sit next to a line of business user (or end user), and get instant feedback on the functionality, look and feel of the proposed end user environment, and make changes to it in real time.

Our folks estimate a three to five times improvement in the time it takes for this collaboration to occur, leading to faster deployment, more involved and engaged line of business members, and thus better business outcomes.

This is an example of putting outside-in thinking into practice - in this case, into a market leading product line.

Share This

Our TAC event ended today with tons of client feedback.   Fabulous!

As I’ve previously written, the annual Information OnDemand conference begins Monday, October 27th.  We schedule our business’ technical advisory council (TAC) meeting the weekend prior.  More than 20 clients, from a broad range of industries and locations, give up their weekend to give us unfiltered feedback on our products and directions.

We started Saturday morning with a report card:  how have we done on acting on the comments we heard at last year’s TAC?  The pre-requisite for an open discussion is that we (the vendor) be brutally honest.  We scored ourselves green, yellow and red - and although we were mostly green, there were a fair share of yellow and even one red item.   There’s no shame in this distribution - in fact, we’re quite proud of our accomplishments.

Then we did an overview of our business and technical strategy, and the roadmap outlook for the next three years.  With that introductory material under our belts, we could begin the real work - and real fun - of the event:  work sessions.   We split the group into two sections, by primary interest, and our folks facilitated a targeted discussion around our clients’ needs, the needs of the line of business groups they serve, and how we can help them succeed.

After a break for dinner (and a show), we resumed Sunday morning.  Our mealtimes are important because they provide the opportunity for clients to discuss the issues they face in their businesses, best practices, and the like.  This is one of the benefits for our clients, along with having a means to help align one of their key vendors to their business needs, gaining a competitive leg up on planning, and developing relationships with many folks on our strategy and development teams.  It turns out that this sharing turned into a major work item for us - keep reading.

A couple of brief updates.  One of our clients did a brief presentation relating his experiences in the financial industry meltdown vis-a-vis how to think about using solutions like ours.  Then back to work sessions; different topics today but the same format.

We finished up with an open discussion around the top three most important items for us to work on.  I mentioned the sharing between clients that occurs during breaks and meals at our TAC meeting.  This was a big discussion topic, as in, how can we help build an online community for clients, business partners, and our development team to communicate, build expertise, and share experiences (good and bad).   We’re energized about this, and I expect we’ll have the first steps of such a community running soon.

What’s this have to do with outside-in thinking?   Every opportunity to understand our clients’ needs, priorities, problems, and successes is a win for us.   The TAC isn’t the only tool we use for this - far from it - but it continues to be a reliable source of challenging, difficult, innovative brainstorming with our customers.   I’m grateful to these particular clients beyond words.

(Image attribution:  http://flickr.com/photos/ heather0714/210999832/sizes/s/ by heather0714)

Share This

Please forgive the irony of the title.  It does illustrate that I’m not opposed to gerunds in all cases.   More explanation follows, but first some context.

I’ve been looking at quite a few presentations lately as I prepare to attend IBM’s Information OnDemand Conference which begins next week.  This is a terrific event for business and IT professionals who want to be able to see everything that IBM and its partners offer in the information management space in one fell swoop.

Back to the gerunds.  These are verbs that end in -ing and are placed in a sentence in the noun position.  Like many things, and example explains it best:  “Opening the door.”

People who would never (I hope) use gerunds this way in prose writing feel empowered to forget all guidelines of effective writing when they build slides.   You’ll find gerunds everywhere in presentation slide bullets:  “Unlocking the value of nuclear fission with my cool product.”

Why is this a peeve?  The active phrasing is so much more powerful!   “Unlock the value of nuclear fission with my cool product.”

Here’s a game for you:  count the gerunds in the next presentation you see.

Next pet peeve:  Mixed Case in Presentation Bullets.   Makes me nuts.

(Some colleagues suggest that perhaps I’ve been doing a bit too much conference prep this year…)

(Image attribution:  http://www.flickr.com/photos/superchango /394485329/sizes/s/ by Maarten (Superchango) )

Share This

The folks at IBM Rational Software just announced their new Rational Requirements Composer.   This is a great example of a tool to help you implement outside-in software development techniques, specifically capturing, validating and refining stakeholder requirements.

Rational Requirements Composer includes lots of visualization options, which are particularly useful for communicating effectively and bi-directionally between IT and line of business teams.

I recently joined Rational’s Bruce Baron in a question and answer discussion about how this new product relates to outside-in thinking.  You can listen to it at www.ibm.com/software/rational/podcasts

You can also see a demo of the new product.

Share This

I had dinner last night with some folks from a major upscale retailer.  We were talking about the perennial problem of closing the gaps between line of business and IT teams, when they shared a very cool story.

It seems that there was an extremely busy holiday season with a heavy volume of phone orders.  So much so that anyone with spare cycles - IT folks, business people, executives - were asked to handle phone orders for a couple of hours.  That’s when the IT team really felt their end users’ pain - and more importantly, used that pain as a catalyst for innovation.

These amateur call takers saw an opportunity for improvement.  The way to implement it was clear to them.  And thus informed and motivated, they quickly added the capability, to the benefit of their end-users, the firm’s efficiency, and ultimately their customers.

This sort of insight might have come out of a design session, would be unlikely to come out of a traditional requirements process, but was just obvious after a short time walking in the shoes of the end-user.

We hear about “management by walking around,” but not so much “requirements by walking around.”  Maybe worth a shot though.

(Image attribution: http://www.flickr.com/photos/90202500@N00/ 24257869/sizes/s/ by jamiefreaky)

Share This

Yesterday the US Congress declined to support Treasury Secretary Hank Paulson’s proposal to repair the current Wall Street financial crisis.

Why?

My scan of news coverage leads to three core reasons.

First, partisan politics.  I have nothing constructive to say there.

Second, Secretary Paulson came across to Congress as condescending; he didn’t adequately explain himself, he was ambiguous in details, and he seemed to expect a rubber stamp.

Finally, he didn’t make clear what this “bailout” would really do.

An outside-in thinker wouldn’t have gotten into this mess with Congress, and would have gotten a yes vote on their proposal.

So let’s look at this situation through an outside-in perspective.   Who are the stakeholders?   The US citizenry (aka main street), the Congress, and the affected Wall Street and global financial markets.   What does the proposal mean to those stakeholders?

Let’s ignore the financial players in this, because the other stakeholders had the dominant impact on the voting.

The press call the proposal a “bail out.”   For main street, that sounds like a sweet deal for those folks who eat caviar at their annual holiday parties, ride around in limos, and have nannies to change the diapers.   The absence of clarity of what this proposal would do and who would be affected was a predictable death factor.

For Congress, the problem was amplified.  If they vote in favor, they ultimately need to explain why to their main street constituencies.   How can they explain it, when the Secretary doesn’t bother to make it clear?  When he doesn’t even give Congress the air-cover for their voters of pushing a better name than “bail out” to the press?

And on top of that, Congressmen (in my experience) have more than healthy egos, and don’t like being treated the way they perceive Secretary Paulson did.

What would an outside-in thinker have done?

(1) Visibly care about his stakeholders.  Instead of coming across with haughty disdain, make satisfying, informing, educating, and helping the key stakeholder groups (all of them, not just Wall Street), the priority.

(2) Use clear terminology that the stakeholders can relate to.  Introduce clear wording.  Start with the nick name for the proposal - if it isn’t a bail out of fat cats, then call it something better - even something as awkward as “main street stability plan” would have been better than “bail out.”   And explain what it means in terms the stakeholders (e.g., main street) can understand, relate to, visualize.

Is it too late?  I predict that any constructive next steps in this space will be wrappered in stakeholder oriented language.

Share This