NASSCOM Leaders in India

Steve Towers keynotes at NASSCOM
An excellent conference with more than a thousand delegates enjoying the best of global speakers.


You can review the details of the event over at NASSCOM -
however I did want to share one especially interesting talk on the theme of story telling, that video is below


Story telling through leadership

Outside In origins

The actual of origins of Outside-In thinking go way back into scientific management, and in fact Frederick Winslow Taylor "The first step in gaining control over an Organization is to know and understand the basic processes." (http://en.wikipedia.org/wiki/Frederick_Winslow_Taylor) whose discussions around efficiency directly involved the need to be quite specific about the deliverable in external terms. We now call that the Successful Customer Outcome with a set of metrics that underpins its definition.
 

Virgin Mobile were one of the first companies to truly venture into the territory as we now understand it. In the book (I must claim an interest) published in 2006 - Customer Expectation Management (Towers/Schurter) we tell the story of how they emerged, understood the needs of a 'new' customer, and accordingly after 2002-3 organized themselves around a set of principles quite different to any existing model. You can link to an article and the book from here http://bit.ly/8cYXhB

The phrase Outside-In has been used in marketing terminology (for instance I came across its use at Salford University, England when I was studying for a marketing diploma in 1983.) I don't think the sentiment is in anyway a new one however the rise of the Digital Consumer has really thrust Outside In into the limelight as an here and now pragmatic approach to aligning organizations for immediate and sustained success.

In terms of modern reading The Outside-In Corporation was authored by Barbara Bund was published in 2005-6 (see http://www.theoutsideincorporation.com/). Since that time several authors have added to the understanding including:

Interview Harvard Business Review with HBS
Professor Ranjay Gulati (book review)
Video


http://bit.ly/RanjayOutside-In
Interview Wharton Business School with WBS Professor George Day (book review)
Outside In Forrester Research (book 2012)
Video



http://bit.ly/WhartonGeorgeDay
http://outsidein.forrester.com/

The BP Group pushes the CEMMethod(tm) as the means to the end (http://www.cemmethod.com) and it is a broadly accepted approach by people who have completed the BP Group CPP qualification since 2005-6.

So is there anything new really? What is certain the time for OI is here and now.


PS. New book, yet to be released (as of 14 Feb 2013) authored by Ram Charan, "Leading in uncertain times", has Outside In as a central theme.  You can link with Ram here.

Linking Process, Procedures & Business Requirements to Successful Customer Outcomes


Linking Process, Procedures & Business Requirements to Successful Customer Outcomes - a Business Analyst Guide

2011-05-31_1211
"Go out to the business and gather their requirements!"
How many times do we hear this said? 
When I hear this being it immediately fills me with dread; images of men in suits wandering through dark forests without maps, looking for mushrooms...needles in haystacks and the like (you get the idea...)
What generally happens in these situations is that business analysts go away and do just that - gather requirements - what the business thinks they want. Typically what this results in is a giant rambling document written in a pseudo business / IT speak that the business say they can't read and the IT guys say isn't detailed enough for them to build from. So the BA goes away and creates a functional spec which the IT guys love, but by this point in time it has morphed so far from what the business want, they have a heart attack when they see the final product!
2011-05-31_1201
"That's not what we wanted!" they say!
"But that's what you told us!" say the BA's and IT guys!
It doesn't have to be this hard. Here's how you do it:
1. Define the successful customer outcome(s)
2011-05-31_1202 
What is it that the customer really needs? What does the business need to do to meet those needs?
2. Define the process scope
2011-05-31_1206 
Establish what the process actually is from the customer's perspective - current state (if a current state exists!). Don't take the business's word for it - their interpretation of what a process is may be radically different to yours. Document the process at a high level (e.g. SIPOC) - confirm with the business. Tick in box from business? 
3. Define the current process
2011-05-31_1202_001 
Proceed to document the process at a task level. Don't waste too much time on the as-is if you are going to change the process!Photos of sticky notes on a wall is sufficient. Tick in box from business?
4. Improve the process / define new process
2011-05-31_1647 
List all the tasks in the current process and eliminate or improve tasks focussing on the outcomes required. If a new process, sticky note the tasks required to achieve the outcomes required with the minimal amount of activities. Don't just consider "sunny day processes" where everything goes right - consider everything that can go wrong! Look at the paths from every business rule in your process!Consider all process permutations!
5. Link Process Tasks to Procedural Steps
2011-05-31_1203 
For each task, create procedural steps - how and why each process step is done rather than what is done. This can be done very simply in a spreadsheet ( For example my Process Ninja Workbook that utilises the CEM Method). What's more, you can then spit it into a procedural document for your staff to use for training and day-to-day operational procedures.
6. Link Procedural Detail to Business Requirements
2011-05-31_1203_001 
The procedural detail helps to create a granular level of detail that greatly benefits the creation of specific requirements.  It forces the analyst to think of all possible permutations and options - it forces them to think in the context of the real world, not a gobbledegook business requirements document.
7. Link Business requirements to test scenarios
2011-05-31_1203_002 
Use procedural detail and business requirements together to develop test scenarios and use cases - IT can then use these for their unit testing then they can be re-used for user testing. Easy.
8. Build it. Iteratively.
2011-05-31_1203_003 Presuming that there is actually an IT solution involved (and let's face it, there usually is), it's best to adopt an iterative (agile) approachwhere there are short development cycles with high business involvement. I have seen too many waterfall development disastersin my time.
2011-05-31_1639
So in eight steps a Business or Process Analyst can create complete traceability from the customer outcomes to the delivery.
It's not really that hard, but isn't it amazing that so many people can make it seem that way?
Cheers,
TPN

Talking of BP Group CPP Masters

With his amazing Ninja prowess, Craig Reid quickly identifies the moment of truth that will solve everything! His colleagues are immediately filled with joy!

Criag Reid, Marjolein Towler and David Mottershead. Some of Australias finest CPP Masters!

The Process Ninja targets a Moment of Truth
 

Customer Experience and Outside In

Right now, in this precise moment, you are delivering an experience to your customers. Do you know if it's positive or negative? Do you know if your customers are happy, unhappy, and why?

A good graphic representation and summary :)