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 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).

I had one particular aha moment when reading the book – where Richard explains how businesses make mistakes when they try to set a strategy by copying what is seen to be successful elsewhere.

His argument goes something like this:

1 – time gaps between cause and effect… A feature of complex dynamic systems (such as businesses and markets) is that there is a time-gap between action and effect. So, for example, if you decide to cancel all training in your business to save money (wow! wonderful profits!) you won’t see a deleterious effect on business performance for a few months – and then there’ll be a gradual increase in quality problems or accidents. This will seem to be a small increase at first, maybe put down to statistical variation. But in fact it is often the early part of an exponentially increasing problem, the part where problem growth appears linear and gradual. By the time the problems become pronounced they are well into the growth acceleration, with an alarming rate of increase, and the problem can be difficult to halt without significant effort. There may be a significant time disconnect between the cut of training and when the impact becomes noticeable.

2 – human perception on causes… Humans have a perception problem. If something happens, the natural state is to assume it was caused by some recent event. So, as per the previous point, because quality or accident problems are identified only when there is a noticeable jump in incidents, management will look at what caused this by considering recent events. Maybe there was a new policy, or a change in line manager, or the canteen changed its menu. Patterns will be spotted, the cause announced and the ‘guilty’ punished.

3 – wrong attribution on causes of success… because of the previous statements, if a business has a success or failure then the natural reaction is to look to recent events to explain the success or failure. For example, a business may be successful because it has a near-monopoly, and that near-monopoly is there because of a patent a previous owner had secured many years ago. Some monopolies are licenses to print money – they generate profits completely disconnected from how well or how badly they are managed. Yet, because the business is successful, the CEO is revered as a wise guru – all this management stuff they are doing must be the cause of the success. Books are written on their management style or strategy and their wonderful business results are attributed to them. (Richard points out that books even discuss things like the car park policy or dress code of the firm in revered tones, as if that makes a difference).

4 – business life-cycle … if you look at the life history of successful businesses they tend to follow a predictable path. When they are young they are lean, aggressive and focused. If they are successful they take on larger, established competition and win in their selected niche – and grow. As they grow they start to mature. They need to add the trappings of a larger organisation – a head office, a management team, corporate staff. Over time they sprout divisions and multiple product lines. Their old competition (the established companies) are vanquished, taken over, and disappear from the market. Because the business is now so big there are lots of people with different interests, directors, product managers, account managers, research managers – all with ideas about the business strategy. Internal power politics usually means the business broadens its efforts (because it can, and because it is too difficult to challenge the wishes of some power bases), doing multiple things, chasing incompatible strategies, and weakening its hunger for competition. Then it is vulnerable to a new generation of businesses – at an earlier stage of their growth – and so the decline starts, leading to eventual failure (which can take some time).

5 – fear of wasting away… management eventually find out their business has lost its edge, that it needs to be reinvigorated if it is to survive – they want to extend its life and compete effectively again in its market-space. So they look for answers. What should their business be doing to be successful? Because of point 3 they are faced with a wall of messages, books, and consultants who say ‘you can make the difference, copy these successful businesses, copy these other brilliant managers – their strategies, or business practices are causing their success’! So programmes are started to transform the business to copy the successful. And these programmes rarely work, because they are implementing superficial solutions – practices copied from businesses that are no longer sharp. Yes, some practices may add value, some may be downright dangerous, but all fail to create the basis on which business value was created in the first place, so success cannot be sustainable. If these changes fail, the diagnosis is that the change programme can’t have been run properly, the practices or strategies weren’t implemented in quite the right way, and by then there will be another trending solution to copy for the next programme.

6 – and the answer is … if successful business models take time to surface, then don’t look to the successful behemoths for examples of good strategy or practice. Look to the emerging successful businesses – these are the ones who have worked out what the market wants, what strategies and business models work, where the soft parts of established businesses are, and what business practices will succeed. If they’ve been smart in designing their business model then larger businesses will find it painful to copy them – they may have to cannibalise existing services, or shake up existing power centres, and results may suffer. But learn from them they must.

What does this mean for your business – what can you learn?

If your business is an established one – then you have to get in early, learn from the emerging businesses, adapt, use your size to compete by investing the kind of money an emerging company can’t have access to, and ideally develop a better-tuned business design than the start up because of this size advantage. (There are real risks in copying business models, which we can cover in a separate article).

What features do current emerging businesses have?

In today’s market the realities have changed. Growth isn’t automatically guaranteed. Capital is difficult to source. Emerging markets are seeing economic power tilt their way. Political change, economic and environmental change both create and destroy market opportunities. Yet some exciting and emerging businesses are successful. We have researched some of these businesses to find out what they have in common that allow them to compete so successfully in the market. In looking at a number of businesses, and talking to these business owners, we’ve been able to identify four practices that they think are important to their success:

• a deliberate, tailored, and insightful strategy (good strategies) with creative, difficult to replicate business models
• a relentless emphasis on sales, and business development, right across the company
• factual, data-driven products, business processes, plans, competitive positioning, based on sound data management principles
• fairness and flexibility, especially to customers and staff, this brings agility and responsiveness

Have a think about what this means for your business. We are here to help.

* (see Richard Rumelt, Good Strategy/Bad Strategy: The difference and why it matters; also his blog at http://www.strategyland.com/)

Wikipedia defines Technical Debt as: “…referring to the eventual consequences of poor software architecture and software development within a codebase.

Common causes of technical debt include (a combination of):

• Business pressures, where the business considers getting something released sooner is of more value than avoiding technical debt
• Lack of process or understanding, where businesses are blind to the concept of technical debt, and make decisions without considering the implications
• Lack of building loosely coupled components, where functions are hard-coded; when business needs change, the software is inflexible.
• Lack of documentation, where code is created, but may be difficult or time consuming for anyone other than the author to understand, as functions are not documented

“Interest payments” are both in the necessary local maintenance and the absence of maintenance by other users of the project. Ongoing development in the upstream project can increase the cost of “paying off the debt” in the future.

Best Practice in paying down technical debt is to refactor code as part of ongoing development.”  (Wikipedia)

This is a very useful concept – and one that certainly resonates with my experience of coding and software development. I like this because it allows for reality – yes you will cut corners, yes the architecture can get out of kilter, and the result is technical debt. This is a normal situation because of the business reality within which all development occurs – yet to avoid getting into too much debt, it needs to be paid off, by investing in technical tidying up from time to time.

Steve McConnell has an excellent article on technical debt that classifies it – depending on how intentional the debt was and how the debt was incurred. This tries to put the debt into business terms – an exchange of quality for time. Cutting corners leads to a reduction in quality, yet time to complete a project is reduced. The quality needs to be fixed later (paying down the debt) but doing so incurs additional costs (the cost of tearing down the area of poor quality and then building it right, and the cost of building it wrong in the first place).

All this is very well – however I’ve recently come across the term of Enterprise Debt (see PEAF for a slide show).

This is used in the context of business architecture. Business architecture gives the design of a business area or function. It contains processes, organisation units, competencies, IT systems, etc and explains how they all fit together.

As an intellectual exercise, business architecture is similar to software design. And therefore it too is subject to debt – except in this case under the title ‘enterprise debt’.

We’ve all worked in organisations where management have taken short cuts in setting up the organisation – where processes may be inefficient or just plain wrong, the team lacks the right skills, or any one of a whole range of everyday niggles about how the business functions. And these niggles result in the business just not performing to its ultimate capability – there is some kind of system yield or impedance at work causing loss in efficiency and effectiveness. This can be quite significant. If, for example you are only running at 70% effectiveness, and 70% efficiency – then that means you are losing out over 50% of your full potential. A business could double performance if only it could architect its business to become 100% effective and efficient (a laudable wish, but not really possible). Yet – surely we can improve on the 70/70 performance – and a modest investment that leads to a small improvement in performance usually offers an excellent ROI.

This whole concept has changed how I look at those difficult discussions with management – why we need to spend time doing maintenance instead of developing new things. The language of debt and the consequences of bad debt are an easy one to communicate and the organisation benefits from having an adult discussion about the options rather than the pointing and blaming that often goes on in its place. Take a look at the links and see what you think.

This article is getting popular – so I have decided to extend the review with additional material… see below.

(Disclaimer – I’ve provided you with a link to Amazon for this book in case you want to buy, it has a 5* review status there so I am not the only one who likes it. I get a very small commission from Amazon if you do buy after linking from this site.)

I like Eddie’s books – as they are easy to get through and thought-provoking. I have re-read most of them 3 or more times, each time through getting something back, or reminding myself of some interesting insight. In this one he takes a look at project management – of business change. This particular book is difficult to put down once started! And having read the book you’ll be motivated to manage your own project.

This book is great if you have been given a new project to run in your organisation. More formal project management books launch off into management processes, roles and bureaucracy; Eddie takes a softer, people-oriented view at how to manage project success criteria – and explains some useful techniques on problem analysis, planning, co-ordination, communication and leadership. And as all experienced project managers know – it is poor people handling that kills a project rather than administrative incompetence. The book will change your mindset, improve your effectiveness, and (most importantly) help you deal with project sponsors in an adult way.

As usual, he splits the book into two – one part as a short business novel, explaining how a project manager learns to deliver a business change project through various trials and tribulations (we quite like these stories, just don’t look for literary merit); and the second part (turn the book upside down and read in from the back/front cover) explaining the various rules and tools introduced in the story.

Eddie challenges traditional thinking, and the philosophy behind the toolset is based on systems thinking.

If you like this book – try Putting Strategy to Work (setting up change programmes), New Rules for the New World (attitudes needed to work in a leaner, more agile organisation), and the Money Making Machine (I’ve discussed ideas from this book to clients who see Eddie’s insight as a complete revelation in thinking about how their business works).