Building a BPM demo

Building a BPM demo is like art.
These are my tips:

Solve the business pain.
You must be able to show how your solution solves the business pain.
If the problem is a lack of visibility – emphasize reporting.
If the problem is structure – emphasize the modelling.
If the problem is SLA – emphasize the escalations and notifications

Customer tailored
Showing the standard generic demo is nice, but if you can build the demo to fit their existing/required process requirements – better.
it shows that you know their business, it shows efficiency and it shows that you put in an effort.

Show it live
Don’t show a PowerPoint presentation.
Show a live system up and running. Live is real (Even the best PowerPoint looks smoke and mirrors).
A real system shows that you have something ready (no need for long design and development)
It teases the customer “Look – it’s ready to be deployed – just buy me”

Must be a story
Don’t just show functionality.
Show a business story. People relate to storytelling better that telling facts.

First 10 seconds
The first screen that is shown is your first impression.
Show the prettiest things first. Customers are usually impressed by the pretty monitoring gauges, the Outlook integration.
Don’t start with powerpoint, don’t show a cluttered desktop

Show the runtime (execution) scenario first.
The runtime scenario is usually “sexier” than the design-time scenario.
It also enables you to show changing the workflow without the hassle and worry of redeployment.

Show 3 steps of the workflow
Showing only one or two step doesn’t feel like a workflow. (“big deal. An application that sends an email”)
Showing more than 3 steps is boring. (“ok, we get the idea”)

Don’t repeat steps
Each step should be different. Send to a single recipient, send to a group, open the task in Outlook, open the task in the portal.

Show integration
Show how the form automatically retrieves/looks-up the information from another system.
Keep it simple without bogging down in technology. (example: clicking on the “Retrieve History” button brings up a list of previous expense claims)

Careful with simulation
Easy to lose the audience when showing simulation. Don’t oversimplify, don’t dive too deep.
For most customers that are new to BPM – simulation is no more than a tick in the box. (sorry.. but true)

Go crazy with monitoring
Anything to do with visibility scores points. Reports, gauges drill-downs, trends, impact analysis. Build a story around it to show their effectiveness.

Build/change a workflow
If you have time at the end, build a quick workflow scenario with the customer. It shows them how easy it is to create and use the product.
If you don’t have time – add a task step to the workflow to show how easy it is to change the process.

Don’t talk technology
Customers buy solutions – not technology.
You might also have non-technical people in the audience. Mentioning the technology at the end is ok.
Mentioning too many products for a solution creates a feeling that the customer will need to buy and maintain all these products.

Branding
If possible, get the names of the people that will attend the presentation and use them in the workflow as recipients.
It always brings out a smile. Personalising shows that you have put in an effort (it’s not just the standard company demo).
It brings down fences and makes you part of the team.
Add the customer’s logo to the forms.

Mention how long it took to create
If it took you nearly no time at all to build the demo – tell them.
Clients worry about long development projects.
I’ve had instances where I received the workflow spec for the spec on Thursday and our presales have shown it to the customer on Monday.
(if it took me a couple of days to create a real up and running demo – live system shouldn’t take much longer)
It shows the client that we have invested a lot of effort, even if the time was short, to get it ready for them.

Refrain from smoke and mirrors
Only do things that you would be proud to tell your mum about.
For example: I hardcode the gauges (otherwise the gauges will show a flat line, as there is no data). I mention this to the customer as I present. Customers respect honesty.

Careful with bells and whistles
Overwhelming the client with too much “functionality” and “features” has a negative impact.
Don’t side-track the demo with gadgets and functionality that are cute and pretty but irrelevant to solving the business pain.
You want the customer to remember the main functionality of the solution offering.

Demo environment
Apart from the demo scenario itself, choosing the demo environment is the most important step in building the demo.
A slow environment makes the product look sluggish. The look and feel must be slick and seamless.
Set screen resolution at 1024*768. Some boardroom projectors don’t work with resolution above 1024*768
Use a closed system without internet. Some boardrooms don’t have internet or internet not is not working/dodgy on the presentation day.
If you are using a VPC like I am, uninstall redundant software, defrag and compress the disk to keep its size down (performance is better on smaller disks)
Use bold colours. Boardroom projectors make colours fade (grey looks white, blue looks grey)

BPM – added value
Spread out your BPM messaging out during the demo, instead of all at once (easier for the customer to digest and remember).
See example of BPM added value
Don’t mention BPM or buzzwords. Talk about the values that BPM delivers.

Don’t bore them
Don’t do a company presentation at the start of the meeting. Leave it till the end of the demo. Customers have come to see you product.
Don’t tell them about their problems, and then “explain” how the product solves that problem – Show it!
Don’t show them a PowerPoint with lots of bullet points.

Enjoy
If you enjoy creating a demo, and enjoy presenting it – customers will pick up on that it’s a fun product.

Presentation timeline
If I have 40 minutes:
5 minutes – Welcome, niceties, explain the scenario they are going to see
10 minutes – Runtime scenario
10 minutes – Modelling scenario (show the workflow designer an how I built the workflow)
10 minutes – Reporting
5 minutes – About the solution, about the company, differentiators…

If I have an hour:
5 minutes – Welcome, niceties, , explain the scenario they are going to see
10 minutes – Runtime scenario
10 minutes – Reporting
30 minutes – Build an end-to-end process (show the workflow designer an how I built the workflow)
10 minutes – Simulation
5 minutes – About the solution, about the company, differentiators…

I added another few tips that I pinched from “Joel on Software”

Get the nicest venue in town
if you have any control whatsoever over the place where the demo is going to take place:
Big, shiny, sparkly, modern with very high ceilings, glass and marble and wood everywhere. Your prospective customers start out with no visual image to associate with your company
Before you try hotels, look for libraries, museums, and universities: many of went into debt building beautiful, modern lecture halls

Get a room that is exactly the right size
You’d much rather have a packed room with a people standing in the back and the hotel staff rushing to set up a few more rows of chairs. This is far better than a half-empty room where the audience feels like maybe this isn’t really the hottest event in town

Serve coffee
Coffee contains caffeine, which makes people cheerful. If you’re lucky, they’ll attribute their cheeriness to your software instead of the caffeine.

Music
Crank up the music so they have to speak loudly. Loud music and loud conversation and a crowded room adds up to the sensation that this is the hot event.
Cover the place in professionally-produced, high-quality logo stuff.

If you’re not an experienced public speaker, watch a videotape of yourself. Have your colleagues give you brutal and honest feedback. You may be discover that you’re doing really annoying things while you speak: