Mike Gallagher - Portal Solutions Specialist

Some thoughts about the role of product demos in solution selling

2006-05-27T11:00:00Z

“Now, I know you’re a bank, but trust me, if you were a hospital you’d really love this feature.”

A posting about demos might seem to be something more suited to an internal Microsoft audience. However, if you’re a customer, you’re going to be on the receiving end of lots of demos from Microsoft and our partners over the coming months. In order to make the most of these, I think it’d be useful to think about some of the different approaches to demos. Hopefully thinking about these issues will make you a more discerning audience and you can ensure that you get the right type of demo for your needs.

The quote above represents perhaps the single biggest problem with most software demos – lack of relevance. Mismatching the contents of the demo with either the client’s problem set, and/or the client’s understanding of his problem set.

There are a couple of different broad categories of demo:

Feature-driven. Walk though a list of features. Don’t mention a business context, simply say “if I click on this, that happens.”
Scenario-based. Present a clear business scenario, hopefully one relevant to your audience, and proceed to show how your solution solves the problem.
Conceptual framework-driven. Show simple, generic examples of how the solution works. Encourage the users to abstract away the details, and apply the solution framework – the design pattern - to other problems within their business.

Obviously the type of demo required depends on your audience. For example, when showing new versions of a product the audience is already very familiar with, sometimes the best approach is just to list functionality. Recently I did a demo of Excel 2007. The audience were a group of financial analysts, who, truth told, were probably far more proficient Excel users than I’ll ever be. They were actually visibly excited as I walked them through some of the new functionality in the client application. I didn’t offer any real context, didn’t discuss any business value. The audience were more than capable of doing that themselves. I simply worked through my list of features. However, when I moved on to talk about the new Excel Server, this was something new for them. So I built my demo around some generic use-cases. We then held a mini-workshop where they discussed how they might use the new product in the context of their environment.

It’s instructive to ask why demos exist in the first place. I think it’s essentialy to communicate. The goal should be to communicate to the client how the solution can solve their problem. It really is that simple.

Some of the ways I’ve tried to avoid this trap include:

Never demo unless you have a clear image of what the client expects. “Before I start the demo, can you just run through the business problem, and also tell me what you’re expecting today.” Consultatively manage their expectations if necessary.
Leave out extraneous functionality. It doesn’t matter how cool it is, or how useful it is in a different context. For product experts this is really difficult sometimes.
If possible, verify that you’re on the right track as you demo.

In music composition, Nadia Boulanger talked about "la grande ligne", "the grand line". This is the idea that there should be a common conceptual line running through a piece. I think this is a useful idea to apply to a demo. What's the theme of your demo, what's the one sentence description? Establishing this can give you the means to focus and target your demo.

SharePoint 2007 Mashups!

2006-05-27T10:12:00Z

In this Channel 9 video, Jon Kauffman points out some the mashup capabilities of SharePoint 2007. At around 25:15 in the video he shows how easy it is to integrate customer data with Windows Live Local search.

I love this loosely-coupled approach to collaboration. Instead of giving people tightly locked-down applications, give them bundles of loosely-coupled "granules" of functionality with rich APIs and see what composite applications appear.

Mike Gotta makes some great points about this approach to application development and new ways of working here. "A fresh approach to collaborative choreograpy should include supporting emergent behaviors that cannot be anticipated."

Knowledge Network for Microsoft Office SharePoint Server 2007

2006-05-22T11:43:00Z

Great to see that the blog for the Knowledge Network for Microsoft Office SharePoint Server 2007.

These social networking persepectives on knowledge sharing and collaboration are really fascinating. http://blogs.msdn.com/kn/

Some additional perspectives on the product here, and here.

Running successful pilots

2006-05-22T10:58:00Z

Last week I spent some time discussing operational pilots with customers.

An operational pilot has great broad appeal. Everyone agrees that it’s a good, common-sense idea to “prove” the solution in a safe and containted environment.

Operational pilots are often used for some or all of the following reasons:

- Win over sceptical management

- Stimulate change management ahead of a broader roll-out

- Add some meat to a proposed financial benefits calculation, e.g. ROI, EVA, etc.

- Test some functional/technical aspect, such as business process verification, user interface, integration, performance, etc.

So there are political, user-centric business, and functional/technical reasons for launching an operational pilot.

It’s also sometimes good for team morale to ship something early in the project lifecycle.

All of this is good, and I agree – a small scale, controlled roll-out, properly managed and measured, can be really effective.

However, too often pilots rarely deliver as expected.

It seems to me that operational pilots are often proposed in the spirit of scientific rigour – “Let’s test our concepts in the real world, and see if our projections are realistic.” However, remember that around 99% of scientific experiements fail to achieve the anticipated result. Failure is good in science, failure is embraced in science. It narrows down the possibilities. However, I’ve never seen an operational pilot that began with a clearly defined set of failure metrics and consequences. I’ve never seen a meaningful feedback mechanism. And if something does fail, the business manager running the project invariably embarks on a spin campaign to keep the project alive.

Before you do a pilot, take a step back and think about what in fact you’re trying to prove. Too often I’ve heard vague, unquantifiable reasons such as “that it works” or “we all know the portal concept is right for us, this will just create lots of positive momentum.”

A great first step is a clear, unambiguous list of targets. This could be something as simple as “That the new system will achieve a 12% decrease in mistyped orders, and, through integration with our ERP, enable our mobile salesforce to complete orders within 2 minutes, instead of the current 45 minutes.”

Look ahead to the meeting where you present the results of the pilot to senior management.

Senior manager: So how did the pilot go?

Pie-in-the-sky pilot guy, fumbling in his briefcase: It went great. The sales team loved the new system. Why, just this morning I was chatting to a guy in the cafeteria, I forget his name. I think he’s some kind of sales-support person. Anyway, he was raving about it. So a huge success.

Normally, this is how pilot effectiveness is reported back to senior management. Contrast this with:

Senior manager: So how did the pilot go?

Metric-focused pilot guy, clicking on his notebook: Well, here’s the list of targets we agreed at the start of the project. As you can see we’ve exceeded all our targets, except the usability target, which we missed by 2%. We’ve subsequently carried out some user-testing of the interface that was causing this, and we’ve dealt with the problem. I’m especially happy about how the system enables the mobile workforce to get orders into the systems in under 1:40 minutes. And I have a report here from IT about the integration with the ERP system. They’re happy with how the system performed, and have given a greenlight for a broader roll-out. By the way, I’ve shared all these results with the sales team, and they’re all really excited about the system.

And of course metrics of this depth enable you to create a really convincing business using probabalistic benefits projection about broader roll-out.

So here are are some rules of thumb for running effective pilots.

Establish success metrics and the means to track them at the start of the project. Ensure you consider the political, business, functional/technical and user-centric aspects.
Within this set of metrics, establish priorities. Allow these priorities to establish the nature of the pilot. For example, if you feel that integration with a back office system is the biggest unknown, consider focusing an aspect of your pilot on this in order to quantify the risk. Don’t shy away from potential problems. If you avoid these now, they will come back to haunt you later.

Don’t confuse a pilot with the first-phase of the project. Once the pilot is complete, you must allow time to incorporate what you’ve learned back into the project. If there is no feedback, no back-tracking, then you’re in phase 1, not a pilot.

Actively manage the pilot. Don’t just launch it and hope it’ll work. You need to track usage, engage with users, measure results, and generally hold the things hand
Communicate positive results. Demos can initiate a surge of positive momentum. Don’t neglect this – it improves project team morale, it primes future user-groups, and it sends a strong message to management.

my first post

2006-05-10T00:10:00Z

I’m a Portal Solutions Specialist for Microsoft in the UK, working in the Business Productivity Solutions Group.

This blog will focus on the business and social applications of portal technologies. Broadly speaking I understand portal technologies to be those technologies which exhibit the following characteristics:

Aggregation of disparate data into a common interface. This data can include documents, rss feeds, business processes, workflow, etc, and can be drawn from multiple systems.
The experience can be personalised - users can create composite applications which are very task and job focused.
Centralisation of common aspects such as presentation layer, security, user authentication, and workflow.
Mostly built upon a flexible web model, powered by standards based architecture – xml, rss, sip, etc.

I plan to take a more meandering approach. I’m lucky enough to spend a lot of time discussing portal strategy and tactics with our enterprise clients. These discussions will inform the subjects I discuss in this blog. Some of the broad topics I plan to cover include:

· Project management, deployment, and change management of enterprise portal solutions

· What the Web 2.0 technologies mean for the enterprise

· How business people should think about Office 2007

· Findability – metadata, folksonomies, tagging, taxonomies, and information architecture

· Mobile computing and integrated telephonony

· Collaboration and the changing world of work

I’m also extremely interested in software development and deployment methodologies. For example, lots of Web 2.0 products seem to have adopted a radical version of the “release early, release often” model. What can enterprises learn from this "eternal beta" model of software development? Mash-ups – aggregating multiple loosely-coupled web applications to create new applications - are another fringe concept which have fascinating implications for enterprise IT.

Ideally I hope to stimulate some discussion and learn a lot from your comments.