Archive for February, 2012

Sales Playbooks

Written February 28th, 2012
Categories: business development, management, performance improvement, sales development
No Comments »

Playbook: an American sports term - it is a book or booklet that diagrams and explains a compilation of strategies a team may use during match games.

Managing a sales team can be difficult. Salespeople, by nature, make thing happen. They move fast, often faster than the business can keep up with them. And there lies a problem. If a salesperson is asked a question, or needs to demonstrate a product, they are quite capable of ‘winging’ it – and in trying to please the customer they might just over-promise, or misquote, or… any number of nightmare scenarios.

You might also have the problem of staff turnover – how can a new salesperson perform as well as an established rep? Does the sales manager have to shadow and coach the new salesperson for the first couple of months before they can be trusted to go out on their own?

You might have a new product launch – and all the sales representatives are expected to hit the road and sell the new product, while appearing to be experts in all the nuances and facts of the product, even though they may not have actually seen the product, or even been aware it existed until a week previously.

Finally, the technical aspects of a product set may be moving so fast in comparison with the competition, with monthly releases, jockeying for position, press releases, press articles and comparison sites all put into the mix that it is difficult for sales people to keep up.

One tactic that can be used to address these problems is to use a Sales Playbook.

A Sales Playbook can be thought of as a guide for a sales team. It contains the living expertise and experience of the organisation in indexed summary format available for use by the sales team as and when they need information at their fingertips.

Content

Sales Playbooks can contain the following information:

  • a product description
  • positioning messages – customer benefits, customer feedback
  • the sales process – with sample documents, letters, etc.
  • case studies – where the product has been used for customer benefit
  • press articles, favourable reviews, and advertising
  • competitive positioning – points of advantage, press articles negative towards the competition
  • contact names and numbers of goto people (technical support, pre-sales, marketing communications, etc)
When to Use a Play Book
A Play Book is a sales management tactic that can be used to help raise average performance across a sales team.

Beware though! As Buckingham and Coffman set out in their ground breaking book – First, Break All the Rules, in many occasions just trying to raise the average performance across the team may not be the right tactic to use. Their argument is that the best performers have a greater potential to improve than the worst performers, and that management coaching is best focused on the better performers across the team rather than those who need to raise their game to the average. The implication – design the sales play book for the best performing team members, mid-level performers should be able to use the book for their benefit, and poor performers may fall by the wayside – yet you should see overall team performance improvement. Designing a sales play book for the worst performers will make it unusable for the best performers, and mid-level performers may not get much benefit from it too.

Development

It is a mistake to polish the playbook so it looks like a professional publication. Keep it rough and ready, so it is clearly an assembly of the best information available at the time. Don’t be afraid to cut and paste, delete whole sections, add new sections, or simply hack it around as needed.

Try the following approach to develop a play book:

  • plan – discuss the needs for and from a play book, develop an outline contents list, appoint a content editor, commission the development of a play book
  • assemble – prepare an initial set of contents, use whatever material is to hand, complete some of the contents list, publicise the existence, and issue copies to all sales staff
  • use – provide training if needed, let sales staff use the play book, capture feedback on effectiveness and needed improvements
  • review – at a suitable point, review the feedback, decide if the play book should continue to exist,
  • prioritise - decide what updates will be made, prioritise from all possible updates and comments
  • update – modify the play book, re-issue, and return to the use step to cycle the process
Technology

Sales Playbooks can be developed using any suitable technology. We’d suggest taking a look at:

  • paper – in a binder, easy to do, cheap, and can act as a prompt to share with clients
  • a Wiki – so it can be available online from any browsing devlce (such as a tablet), and easily updateable
  • OneNote – this supports sections, pages and shared updates – ideal for a small sales team
Benefits

A Sales Playbook can help to raise the performance of sales people in a team by providing easy access to expertise drawn from across the group. It can help reduce the burden placed on sales managers to coach new starters, and under performers.

Further Reading and Links (external sites)

Marketing Profs – How to Write a Sales Playbook - article

How to Create a Killer Sales Playbook - pdf file

link to First, Break All the Rules on Amazon (we receive a small commission if any purchase is made)

Review: Understanding A3 Thinking

Written February 21st, 2012
Categories: book review, business processes, management, performance improvement, project management
No Comments »

disclaimer: link provided to Amazon for your convenience, if you visit and buy we will receive a small commission.

In my reading into agile techniques I keep coming across references to A3 management. I learned that projects could be managed using a summary laid out on an A3 piece of paper, and I could see some example A3 charts. They looked intriguing, yet, nowhere could I find an in-depth explanation of what the A3 technique was, how to use it, and adapt it for my own purposes.

That was until I found this book.

What is the A3 Technique?

In most organisations you’ll find overblown, bureaucratic project management methods, used to direct business improvement projects of all sizes and complexity. They require the production of project plans, project descriptions, initiation documents, reports, risk logs, and many other artefacts. And they can all be considered waste because what really adds value is what is produced technically by the project and deployed as a solution to the original problem. At the end of a project all the project management material is just thrown away.

OK, this is a bit extreme. Project management is there to provide control over the technical work, to control risk, and ensure an effective result. However it can’t be denied that the project management work is overhead, and to be minimised where possible.

Arrive the A3 technique.

This is a way of thinking and practice that believes an improvement project can be managed and summarised on a single side of A3 paper. All a project manager or team need do is produce a well-designed A3 sheet, divided into sections, with appropriate text, tables, or charts in each section, and the project documents itself. All senior management need see is the single sheet of paper, and this reduces overhead, improves communication, and enables management to use their time effectively advising the project team.

What is in the Book?

The book contains a description of the basic elements behind the use of an A3 chart and how it can be used to manage a problem solving project – according to the authors, the chart needs to be logical, objective, focused on results and the process used, visual, aligned, coherent and be based on a systems view.

Having described the elements of an A3 chart, the book explains a number of different uses and formats – for problem solving, for proposals, and for status reporting.

Finally, it provides notes on style, form, and using A3 charts within a project office and for coaching.

All in all – what you need to understand to start using A3 charts in your business.

How We Use the Book

We have developed our own version of an A3 report based on this book and the one-page project management series. We use these when delivering change programmes on client engagements – a summary chart for the overall change, and separate charts for each component project.

We’ve also designed process management scorecards that explain how an operation process works, its current performance, planned improvements, and the status of current improvement efforts.

Both the above have resulted in happy customers – because communication was effective and efficient they were fully able to engage in conversations about project progress.

Business Intelligence Requirements Management

Written February 15th, 2012
Categories: business intelligence
No Comments »

Introduction

Business intelligence projects are different. The nature of the work, the breadth of knowledge, the volume of data, and system integration expertise needed make developing such systems very different from classic system development or package implementation type work.

Over the last 10 years, we have seen great strides forward in the way software systems are developed. Newer, agile approaches prioritise delivery of value, early, over formality, with great impact on end user satisfaction and developer work-life balance.

The business intelligence community has been left behind somewhat.  The nature of business intelligence systems under development don’t lend themselves very well to direct adoption of system development techniques.

This article is one of many I plan to write about how newer requirements management techniques can be adopted and adapted for the BI community – I’ll structure them as a series of tips (and will definitely publish on other topics in between). It presents the topic from the perspective of my experience – I have over 25 years’ exposure to the discipline and have kept in touch with developments over that time.

Tip 1 – Use Stories to Express Requirements

What are Stories?

Business intelligence systems should use the story technique to express requirements. These are a recent development and I believe excellent technique that forces some discipline and thought on what is expressed without adding too much formality.

Stories are short sentences that set out what a system should do, while adding important context. See http://en.wikipedia.org/wiki/User_story for a discussion. There are a number of template structures, but here is one I’ve found useful:

As a <role> I need to <do what> in order to <deliver what value/benefit>

Stories can be written about any system – a whole business, a complex business operation, or an IT system. Most literature focuses on IT systems – but extending it out to other systems in the wider sense allows its power to be used elsewhere.

Examples

For example:

As a sales manager I need to analyse sales by sales representative by month over this financial year in order to inform how I coach individual sales people in my team.

As a site maintenance manager I need to analyse the replacement rates of light bulbs of different types and different suppliers in order to prepare a maintenance plan.

As a board director I need to ensure the business conforms to the data protection act in order to discharge my responsibility to ensure the business operates legally.

Hints

The technique is deceptively simple. When you use the technique you should think about the following points:

  • Try to be consistent in the use of role names. If you have a maintenance manager role then make sure you use the term maintenance manager consistently wherever mentioned.
  • Roles are not the same as organisational posts. A given post may perform multiple roles. A role may be performed by multiple posts. For example, a sales analyst role may be performed by a sales analyst post, as well as by the sales manager post, the financial controller post, etc
  • Try to use one role only in a story – don’t use ‘As a <role 1> or a <role 2> or a <role 3> I need to …’. If the story then goes on to use the same <do what> and <what value> statements, then think – have we identified another role – one that exists to benefit from the value created? Multiple roles suggest we are too close to the organisation chart.
  • Roles can be general or specific. For example, we may identify a department manager role that needs all kinds of information about their department in order to manage budgets. However, we may identify a sales manager role with specific sales information needs. The sales manager post may perform both the departmental manager and sales manager roles.
  • Try to avoid compound statements. If you find you are using the words ‘and’, ‘or’ in the <do what> statement then take a close look to make sure you are not really expressing multiple, separable statements in one. If you are it is best to separate them.
  • Make benefit statements as measurable as possible. Maybe the story enables a role to perform a task (it could not be performed economically before, but by adding the capability <do what> this becomes possible). Maybe it improves effectiveness or efficiency (a task is performed faster, with greater quality, or at lower cost). Try to quantify where possible.
  • For reasons I will explain in a later post, I think stories should be kept in a repository. Agile developers prefer to hand write stories on cards, stick them onto wall charts, and throw them away when completed. Yes, I agree that is perfectly appropriate for development work. But there is a wider context within which the project works, and someone has to fund the project, so keeping them in a system for non-development reasons provides value. At the least, the <role>, <do what>, and <what benefit> statements need to be kept separate.
  • Stories can exist at different levels of scale, granularity and precision – use Themes, Epics and Stories to classify your requirements, or adapt your own scheme. For management purposes three types of ‘story’ can be used: a Theme is a strategic top level objective for a system (a major feature of a system), themes are decomposed into lower-level themes and eventually into epics; an Epic is a high-level, coherent but multiple-featured bundle of functionality – an Epic can’t be delivered without significant effort, Epics may be decomposed into lower-level Epics and eventually into Stories, Epics are difficult to estimate (other than ‘big’); a Story is lower level, independent, small, stand-alone item of value, and can usually be delivered by a project team relatively quickly. (See http://agile101.net/2009/08/10/the-difference-between-agile-themes-epics-and-user-stories/ for an explanation and diagram).

Conclusion

Using stories provide real benefits to your requirements management efforts. They are useful because they are easy to learn and use, they force the writer to identify a role and benefit – making the story focus on business not technical needs, and they are low-tech so a team can make rapid progress using nothing more than pen and paper cards.

Further Reading

Mike Cohn: http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements; and http://www.mountaingoatsoftware.com/topics/user-stories

Mike Cohn’s book – User Stories Applied (Note: link for your convenience, we receive a small commission if you end up buying from Amazon).

Older Entries

subscribe to RSS feed

Subscribe to our digest newsletter

Recent Posts

Recent Comments

Archives

Journal Categories