The Geraldton Printer



Still under the heading of ‘Rule #2 – There are no rules’. Here’s another example.


Prior to a significant IT project, the Chief Information Officer and I visited a provincial hospital in the town of Geraldton with a view to discussing the administration changes needed to accompany the incoming technology.

We were well received and it was a successful trip. On the way out the door one of the front office staff asked if we could look at a problem that they had with one of the main hospital printers. Although my background was technology I’d been in admin for some years and my technical skills were a bit dated. My advice would have been to call the local IT support contractor but my boss simply agreed, “Sure, we’ll take a look”.

I know better than to contradict my boss in public and so played along. We spent perhaps an hour or more reading the printer and network manuals and fiddling with the printer and network settings until we got it working.

In the privacy of the car I challenged my bosses decision, “That could be the most expensive printer fix in history. We have people to fix printers you know”. I’m still not sure if John didn’t recognise, or simply tolerated the sarcasm in my voice but I was genuinely bewildered. “I know” he replied, “But if the top IT guys had come and gone and the printer still wasn’t working it would have tainted everything we talked about”. He went on to explain that we were not just there to tell them how to restructure their administration team to accommodate the incoming technology, we could do that in an email. We were there to instil trust and establish a working relationship. We talked about the incoming technology, about management structures, skill requirements, resource funding, and we fixed the printer. I sat quietly. I felt like a naughty child.

For me it started the ‘think why before what’ thinking which underpins much of ‘What they didn’t tell you about project management in class’.


free book!


, ,


As part of a book promotion, the publishers are offering the book through Amazon for free – presumably it’s for a limited time only!  If you like the sentiment expressed in the blog search for it on Amazon or click:

Project Management Rule #2 – There are no rules


, ,


I say ‘Rule #2’ because there’s always something more important but the desire to project manage by rules, templates and check-lists just increases the chances of getting blind sided by the unforeseen. This is one manifestation of the theme underpinning ‘What they didn’t tell you about project management in class’ (hereafter referred to as ‘the book’) which is to use mission to dictate action. Understand why you are there and let that guide you as to what to do.

Over the years I’ve held a few workshops on the subject of facilitating meetings and by my own standards if you need four hours to complete what is supposed to be a two hour meeting then you are doing something wrong. This was the case in the George project (In the book under ‘War stories’) routinely. Weekly team meetings on occasion involved tears, resignations, the odd suicide attempt (slight exaggeration – I’m pretty sure they wouldn’t have gone through with it). The whole company was in chaos not just my project. There were issues not related to my project that were causing disruption to my project.

I found myself saying over and over again, “These are issues which you need to take up with your own management.” Eventually I consulted Dennis, my boss from Clarity Consulting. Dennis came to the next meeting. He sat and watched. The gladiatorial exhibition began, but when I tried to suppress debate on topics not directly relevant to the project Dennis stopped me. “Let them talk” he said. As I listened to the tirades Dennis tapped me on the shoulder, “Are you writing this down?”.

In the aftermath of the meeting Dennis sat down with me and explained that although these issues were not within my scope to control and not related to the delivery of the project, they were affecting the delivery of the project. My team leaders were raising them because there was no other forum that would listen to them. I typed up the minutes, detailing issues that the team leaders had identified as compromising their ability to deliver on the project. I brought the minutes to my sponsor the next day. “We appear to be thrashing and at last night’s meeting we identified some reasons why”. I went to his office with the mindset of asking him for help with issues that were outside my control.

He didn’t say much. He took the list and sent me away. Suffice to say that he dealt with his staff and his fellow executives with the same bull-in-a-china-shop manner that I originally thought was reserved for me. Many of the issues miraculously disappeared. The minutes became an official record of company issues which were holding back this high profile project. That made them the property of the sponsor.

Rules are a traditional management tool. Rules describe what worked so that if you follow the rules and you’ll be able to repeat the success upon which the rules were based. If things aren’t working, stop asking yourself ‘what do I do?’. Instead ask yourself ‘Why am I here?’. Project management is about managing accountability, so very simply if it’s not your problem then who’s problem is it? Then the question is simply how to we make them accountable? Sometimes you can’t but your sponsor can and in the context of your project world, that makes it your sponsor’s problem. Just by asking them in the nicest possible (recorded) way, it becomes their responsibility.

Choosing a project to manage


Seriously you don’t often get to choose your projects, certainly not early in your career. Assuming your selection is based on whether you get the job or not, here’s an insight which may tell you how to dress on your first day, ie whether you’ll need a bullet proof vest or not.

If you see the project management position advertised with, ‘Must have experience with product X’, then by all means use your experience with product X to get the job but be warned it is going to be a fun project. In case you’re having difficulty reading between the lines, ‘fun’ means a long way from boring, in much the same way as getting shot at is exciting. What the add says is that the administration wishing to recruit a project manager either lacks confidence in their product experts or they can’t differentiate between doing and managing which is an issue because if you’re spending enough money to warrant engaging a purpose built project manager then ‘managing’ is going to be a full time job. Either way, at some point in time you are going to have to drive some painful truths home to your sponsors.

I go back to a mantra which I use quite a bit in ‘What they didn’t tell you about project management in class’ which is that the payload of the project will ultimately be delivered by the delivery experts in accordance with the decisions made by the sponsors and business managers. It has little to do with you. As the project manager you are the facilitator. You are the game show host and not the contestant. If you use your subject matter expertise to deliver the project, how long will that change survive in the environment once you’re gone? A project is about changing the status quo. How successful would you consider a project if the change collapses the day you move on to your next project?

In smaller projects you often have two roles to play. You may have been given the task to oversee because you are the local expert and you are expected to use your expertise to affect the change. In this case you are both the project manager and a contributing resource. The danger you face here is the temptation to make assumptions about how other contributors might work. Even if you know how their contribution is supposed to work, unless you plan on micro-managing everybody contributing to the project, it is their expertise which will be on display at the end of the project and not yours.

Sometimes it actually helps to not have subject matter expertise. This is an extract from ‘What they didn’t tell you about project management in class’.

When I took on the PACS project I had already decided I was done with project work. I took on the project for two reasons. Firstly, the hospital where I would spend most of my time was two hundred and eighty metres from my front door – very convenient. Secondly, the recruitment add said, “PACS experience would be highly regarded but is not required.” The ’not required’ told me that these guys were able to distinguish between doing and managing. Curiosity (and insufficient funds to retire) lead me to apply. Having no prior experience with PACS meant that I had to ask a lot of questions. On more than one occasion while a team leader was patiently explaining the technology to the dumb project manager, someone else in the room disagreed. The ensuing discussion barely raised an eyebrow but had it not happened then, it would have led to a disastrous misunderstanding later. Disaster was averted simply because those doing did the explaining and not the project manager.

The take-away is that managing and doing require different skills. On smaller projects you may have a ‘doing’ hat as well as a ‘managing’ hat but if you’re looking at a multi-million dollar investment then managing is going to be a full time job and if you get the job because you have a background in the underlying technology/environment – dust off the bullet proof vest, you’re going to need it.

Risky Business – The art of risk mitigation planning


, , ,

When they set off the first hydrogen bomb there were a number of things that could have gone wrong. One worthy of mention is that it could have set off a chain reaction in the atmosphere and effectively frying the planet. It was a slim probability and of course if it happened there’d be no one left to answer to, so as a mitigation plan they kept their fingers crossed.


Although this is pretty much an extract from ”What they didn’t tell you about project management in class’ my approach to risk mitigation planning is not radical, but it is simple and effective. The gist of the book is that as project manager you are all about keeping people accountable. If you are to keep the decision makers accountable for their decisions then they must be informed decisions. If you’ve kept information from them then ownership of the failure is yours. The risk mitigation plan is an important communication device. There are a number of ways you can present it. Below is the table I use. The trick is in knowing what should (and what shouldn’t) go in it. Think carefully about things that could rain on your parade, document them and present them to your sponsors. For example:





mit. plan

New Bird flu affects team members


Project activity requires interaction with international students


There may be delays in data gathering, which is not on the critical path


Issue flu shots to all team members. Encourage remote submission of data

Earthquake renders Corporate Office unusable


Tremors have been reported in the news but geologists do not expect after shocks


Project could be delayed indefinitely



About the columns:

Event is the thing that can go wrong. Remember that it has to be relevant to the sponsor’s decision to proceed. Avoid inclusion of operational issues/risks that can be managed within the scope of the project. Consider the sentence, “Boss this is something you need to consider before we start the project”. If it doesn’t apply to the event you’re thinking about then you should probably leave it out.

Probability is the likelihood of the event happening. Use ‘low’, ‘medium’ or ‘high’. Avoid using percentages or fractions as they imply a degree of accuracy which cannot be supported by data. Include a few words of explanation as to why the risk event has become a probability worthy of executive attention.

Impact is the extent to which the event will impact the elements of the triple constraint, ie time, cost or deliverables. Again, use low/medium/high rather than a percentage. Include a brief description of the impact, eg ‘will take longer’, ‘cost more…’ etc.

Exposure is the combination of probability and impact ie how exposed is the project to this risk event? Probability and impact are not enough because you can have an extreme impact event like ‘earthquake’ but with a probability so low that you’re not really worried. On the other hand you can have a relatively low impact issue like the emergence of a new flu virus but it is quite likely to affect your protect. ‘Exposure’ is the column in which you summarise for your sponsors the severity of the risk. Again use ‘low/medium/high’ and sort the table so the biggest concerns are at the top. Use one word only in this column to make it stand out. The details are in the other columns.

Mitigation plan is where you state the action the project team will take to minimise the probability of the event occurring and/or to minimise the impact of the event on the project should it happen. It’s OK to put ‘none’. If you’ve listed a possible event because it’s been in the news and the boss might be worried, but you’re not and you don’t plan to do anything about it, then say so. It will give you the opportunity to discuss the risk with the boss and it will give the boss the opportunity to overrule you which is their right. It may be that there are political implications less obvious to your level of operation. If the boss sees ‘none’ and decides some action is warranted then that decision will come with the required budget, resources and timeline adjustment.

Hopefully you can appreciate that the risk mitigation plan is important, and not particularly difficult to do, but do you have to do one each time? You are expecting the boss to make a decision. Part of that decision is knowing what could go wrong. Perhaps there is nothing, in which case you could leave it out or leave it blank, but don’t pad it out with issues which don’t belong for the sake of ticking the ‘risk mitigation plan’ box.

In the table I’ve used earthquake and influenza as risk event examples to demonstrate relationship between columns of the table. I do this in class too but as they’re walking out the door I threaten them with grievous bodily harm if they include swine flue and earthquake in any real risk mitigation plan. Include only events that the sponsors need to take into consideration when deciding whether to proceed with the project or not. A blank risk mitigation table will provoke thought. “What about…?” and your boss is now doing your job for you which might be a bit embarrassing but it is productive. Padding with events not specifically relevant to the decision to proceed are likely to cause the reader to start skimming, reducing the quality of the communication that you have with the reader.

Your risk mitigation plan is all about communicating what could go wrong and what you are going to do to minimise the probability of it happening and/or the impact of it happening if it does. One possible outcome is that the sponsors decide not to proceed with the project, which is their right, but no matter what happens the risk mitigation plan (done well) will ensure that you, your team and your sponsors stay friends through the rough patches. This is not only good for your stress levels but also gives the greatest probability of a successful outcome. .

Minimalist Business Case Template


, ,


Proposal/Business Case Template

There are lots of examples on the Internet. This is what I use. Before you begin go back and read the earlier articles about why you go about writing a proposal and how to incorporate appropriate influence.

While this is a minimalist template, your document can be even simpler. Stay focused on what you’re trying to achieve with the document and incorporate only what you need to get the message across. Be economical with words and remember that the reader will form an opinion of you and your proposal within the first few seconds of looking at your proposal.

1.0 Executive Summary

Very important. Short & sweet. See earlier article dedicated to executive summaries.

  1. Introduction &/or Background

In a big formal business case, likely to attract a high profile include it all, otherwise Include whichever of the following is necessary to make your case.

  • Background
    Describe the chronology of events that lead to this proposal becoming relevant. Eg: In response to concerns expressed by staff at last year’s PD day, HR staff surveyed …. and recommended …

  • Major Stakeholders
    Get into the head of the decision maker for whom this document is authored. In this section you are answering the questions: ‘If I say yes, who’s going to be happy?’, ‘Who’s going to be gunning for me?’ and ‘What resources am I going to have to free up?’.

  • Environment
    Describe the part of the working environment that will be affected by this project. This is the context for the scope which you will write for your charter document. If your proposal is to introduce a water cooler then there will be a small change to the office geography but a big change in the social interaction between staff members.

  • Author(s)
    Sell yourself.

3.0 Proposal

Critical – of course! This is where you describe what you want to do. Consider the following sub headings:

  • Outline
    Describe the change that you propose. Remember to use terminology and language appropriate to the reader.

  • Alternatives considered
    There are always alternatives, even if it is to do nothing. You include this section to demonstrate that you have considered the options and that you are recommending the best one for the organization, not just you. Make a bullet point list, ending each alternative with a ‘but’, ie why it is not the recommended option.

  • Arguments for
    Don’t confuse this with costs vs benefits. Arguments for is regarding your proposal compared to the alternatives.

  • Arguments against
    Again, this is about your proposal compared to alternatives. If there is a down side at all it is appropriate (and better for your case – influence! See earlier proposal article) that the decision makers hear about it from you.

4.0 Costs

This is a section you would normally include. If your proposal is leading to some project work then there are two areas of costs which you need to address.

  • Initial
    What is it going to cost to execute the project? Ie how much is needed up front.

  • Ongoing
    Once the change has been implemented how is the budget for the target environment going to be effected? What are the on-going costs? Eg subscriptions, maintenance, additional resource requirements etc.

5.0 Benefits

Firstly you need to establish a link between your proposal and the corporate mission. How will what you are proposing contribute to what the organization is all about? Check out the the ‘Joe Locker’ post’. For extra brownie points use words from the mission statement. There are two elements to benefits:

  • Tangible: The more obvious, measurable benefits like projected revenue, reductions in staff turnover or reductions in operational costs.

  • Intangible: Sometimes the real payload of a project are the benefits which are most difficult to quantify. There’s no doubt that a happy workforce tends to be more productive than a miserable one. I’ll go into how to quantify the unquantifiable in a future article.

6.0 Proposed Implementation Plan

This is the document equivalent to draping a scantly clad woman over the bonnet of a car clearly marketed at men. It’s not a working plan. You are just painting a picture of what it looks like having made the decision to go ahead. Tangibly speaking it’s a very brief project execution plan. It needs to be brief for two reasons: Firstly, you most likely don’t have the data to do a detailed plan yet. Secondly, remember why you’re writing it. It’s not a plan from which you micro manage resources.

7.0 Risk Analysis

Risk Event




Mitigation Plan

See previous article re: writing risk mitigation plans. Remember that the events of interest here are those that affect the decision to endorse or not to endorse the proposal. Ie if the project goes ahead, what could compromise or negate the benefits described above? You’ll have the same table in the project charter but there you’re concerned about threats to the execution, ie delivery. Here you are concerned about threats to the organization that accompany the decision to do or not to do.

8.0 Constraints & Assumptions

List here any any parameters imposed on the proposal either internally or externally. If you’ve had the conversation with your boss in the corridor and he’s said, “OK but you have to keep it under $10,000”. Documenting the proposal is the next step but you cannot ignore the instruction you’ve been given. List it here. It will affect what you can and can’t achieve with the project. Perhaps on reading your draft, your proposal is given greater consideration and you get a call rescinding the limitation, perhaps not. Either way the outcome is affected by this constraint.

Likewise if you’re doing things a particular way to accommodate company policy or legal requirements, note that here. If there is an immovable deadline, list it here.

  1. Endorsement

If your proposal is in the form of an email to the boss, all you need is a positive reply.

If your document is formal enough, include a signature block at the end of your document. It helps to remind them to think carefully, they will be held accountable for their decisions.

It is also important that the sponsor knows that at this stage they are agreeing in principle only and that they will have the opportunity to review a plan of execution (project charter) before you start spending the money.

A Decent Proposal – Part 3. Making the right connections


, ,

In my Uni days I did some direct selling in a desperate attempt to earn some money between classes. The training was morally bankrupt and about manipulating the unsuspecting and ill-informed victim. I was in the job for about a day… There were some valuable take-aways, like if you are trying to sell an idea, start with identifying the decision maker and what’s in it for them.

When it comes time to endorse a proposal, the priority that your proposal will be given will depend on the extent to which it supports the corporate mission – whether it’s officially documented or not. What is the ‘bottom line’ and how does your proposal contribute?

This is an example that I use with my students when it comes to writing a business case.


Joe Locker is a locksmith. Who wants more customers. His shop is on Brunswick street and his shop is barely noticeable as you drive past. Joe asks for your opinion: Should I put up a new sign?

Some figures:

  • Joe’s shop earns him $100,000 pa gross. After he’s paid the rent, operating costs & utilities bills, he takes home $30,000 from which he has to pay his home mortgage, car loan and live off what’s left.
  • 75% of Joe’s customers are passers by who notice his shop.
  • Only 10% of people who walk by notice his shop.
  • A new sign would cost $1300 which is A LOT of money to Joe.

Over to you:

Write a business case, justifying spending Joe’s annual entertainment budget on a sign.

The students spend about half an hour putting together a proposal that they then have to present to the class. The maths goes something like this:

75% of Joe’s $100,000 gross revenue are walk-ins, ie people walking by, who see the locksmith and think ‘I need…’. If the sign increases the percentage of people who notice the shop from 10% to 20% then it’s reasonable to expect Joe’s gross revenue to increase by $75,000.

The big question is, ‘Where did you get the 20%’ figure from? The truth is, that it is a guess. Can it be refuted? Yes it can; but if you’re arguing about whether the sign will attract the attention of another 5% rather than 10% of passers-by then you have already won the argument. By then you’re talking about the size and colour of the sign; not whether to have a sign or not.

When you first sit down with Joe to convince him to put up a sign, Joe is thinking of all the things he’ll have to give up in order to spend $1300. Now he’s thinking about the impact that the sign can have on his gross revenue.

Your job in presenting a proposal is to make a connection between what you are proposing, to the bottom line. Can you make up the supporting figures? Yes you can as long as you word it honestly. The key word in the presentation of the figures above is ‘if’. ‘If the sign increases…’. The numbers can be contested but doing so acknowledges the connection between cause and effect, which is what you are trying to achieve. It means you’ve won!

Next: A minimalist template of a business case.

A Decent Proposal – Part 2. Elements of Influence


, , ,


So what are the elements of ‘influence’ and how do we incorporate them into our proposals? Here are some to consider:

Carrot and stick:

Perhaps I’m showing my age… think of it as incentives and threats. Get into the head of the decision maker for whom the proposal is authored. How is this proposal going to make the reader feel good or look good? How is the reader going to benefit from the proposal? We’re not talking about the organisational mission or values, this is personal. The ‘benefits’ justify the cost to the organisation but don’t forget to weave in the benefits to the reader. How is it going to make them profit, look good or advance their career?

Conversely what horrible fate awaits those who miss this opportunity? Again it maybe that the negative consequences are legitimate for the organisation but you need to make it personal. Ie ‘Do you want to go down in history as the one who let this get away?’. You need to choose your words carefully, but don’t let it go unsaid.

Credibility and trust:

Why is it that when you’re buying a car the salesman happens to drive that exact model? They want to align themselves with you. They’re saying, “I am like you. I have the same interests and tastes. I’m in the car business and I’ve chosen this car, just like the one you’re looking at…”. In ‘What they didn’t tell you about project management in class’ I talk about project ‘champions’, people on the receiving end of the corporate change as opposed to the driving end, who begin to see that it might be a good idea. The concept is exactly the same. Hearing positives from one of their own is so much more influential than anything anyone on the implementation team can say. So in the introduction of your proposal, where you list the key stakeholders, include yourself, your qualifications and experience pertaining to the subject and your interest in the subject.

In the good old days when companies had ‘style manuals’ which stipulated the fonts that were to be used on memos vs letters, reports were accompanied by a ‘letter of transmittal’ which basically said ‘here it is’. It was usually a short letter and it invariably began with, “Thank you for asking me to look into….” and finished with, “… the report is attached”. Those words themselves are influential. You don’t ask someone to research a topic on which they were completely ignorant. You ask the expert. So if you’ve been asked to look into a particular proposal, don’t lose the opportunity to say so. The modern equivalent might be the email to which your report is attached. Use it. “Thank you for asking me to look into this. It has been a passion of mine ever since…”.

Shared vision

Not only are you credible (qualified & experienced), but your thinking is similarly biased. Demonstrate empathy with the reader’s position on the subject. Demonstrate how the proposal will support the corporate mission but remember that your words must speak to the aspirations of the decision maker personally and directly. Perhaps it could save the company $50,000. If it does, would that not demonstrate how this department can lead the way in efficiency planning? This is not sneaky or underhanded spin. The benefit is legitimate. You are simply making the connection with the boss’s desire (need?) to demonstrate the effectiveness of his team (and therefore his own leadership).

A word of warning: I once wrote a career limiting report on the subject of choosing a word-processor. There was a corporate move to replace MS-Word with MS-Works. My boss asked me to look into the implications for our department. My conclusion was that although the functionality was significantly less, MS Works would improve productivity. This was in the days before graphical user interfaces (that’s right, pre Windows & pre Apple Mac) and although MS Works was a bit Micky Mouse, it did have an integrated database and spreadsheet so that even a novice user could (remember pre-windows) cut and paste between them. Most members of the department were not computer literate enough to use the features of a fully blown word-processor anyway. What I failed to grasp was the subtext to the request which was, “I want to keep MS Word. Give me some ammunition to fight the corporate decision”. I could have done that! If only he had been clearer about what he wanted! To influence, you must develop your ability to empathise and sometimes to read between the lines.

I’ll go over an example of a business case template in a future post.

A Decent Proposal (With apologies to Jack Engelhard) -Part 1



aka: ‘what matters is more than logic…’
aka: ‘the logic and lust model’

I couldn’t decide on a catchy title…

Under ‘Why would you’, we put the business case into the context of the organisation at large. In this article I want dig a bit deeper and start talking about writing one.


There are two elements of a proposal or business case. There’s the logic ie the benefit outweighing the cost, the solid process that you followed and the alternatives which can be demonstrated to be inferior of course. Do your homework and you’ll come up with the logic but decisions are not made on logic alone otherwise why would advertisers drape scantly clad women over the bonnets of cars clearly aimed at men? There are some very clear examples of Asperges syndrome in my family and while I didn’t get the phenomenal capacity to focus I do have a Dr Spock like attraction to logic and like so many technical people I’ve coached since, I tend get frustrated when I think I’ve presented a logical argument but it is not accepted.

Consider the scenario where boss Julia is trying to find her desk under a mountain of papers. In her in-tray there are two proposals. In terms of value to the organisation they both similar. One is written by Anabel. Julia knows from past experience that Anabel’s work is solid, reliable and thorough. Anabel is good to work with. The other is written by someone called Sandra…

We’ve been doing this since child hood. Did you use logic to convince your parents to let you stay up late or get the icecream desert even though you didn’t eat all your vegetables? Did your children present statistical analysis to justify the iphone that they so desperately needed and everyone else at school already had? I’m guessing they used emotional blackmail questioning your community standing as worthy parents and promises of family bliss that only the right smartphone could bring. Somehow when we put on our business cloths we pretend that we are all immune to ‘influence’ other than logic.

Think about the elements of influence that relate to your project. For my next post I’m going to talk about how to include elements of influence into your proposal document.

The Business Case – Why would you?


, , ,


I once worked for a corporate office which rented a projector every week to support presentations and training. Not only was rental costly each week at least a half day was lost in picking up and returning the projector. Even though back them, projectors were quite expensive, it made sense that we had our own. The boss agreed. “Write it up” he said. My first attempt was returned to me with more red ink on it than my accounting exam paper. It stopped being fun well before the sixth iteration by which time I became less concerned about disguising my annoyance with the entire process.

“Now can we get one?”
“We got one last week, and now we have the appropriate justification to go on-file”.

I walked out of his office with mixed feelings. I was pleased with the outcome. I was proud of what I’d written, although slightly confused about why. Upon reflection, I think it was about teaching me to write a good business case. Allow me to share.

The business case is one of two documents that I’d consider critical to any project. Lets start at the beginning: ‘Why bother?’ One of the themes that underpins the book ‘What they didn’t tell you about project management in class’ is to consider ‘why do…’ before you decide what to do. So in keeping with that theme: Why do a business case? Who’s asking for it? What is its purpose?

In most cases the reason you’d write a business case is to ‘sell’ your idea to those who can put up the money to make it happen. That in itself should tell you what structure, tone, language and format your document should take but look a little deeper by putting yourself in the boss’s shoes. Why does she need a documented business case? Two possibilities spring to mind. Perhaps she needs to sell your project further up the management ladder in order to secure the funds & resources to go ahead but even if the project is within her power to endorse she will need to be able to explain and justify her decision to auditors now and in years to come.

Thinking backwards from the auditor’s obvious conclusion that it was a sensible decision, on what is that decision based? This gives us the payload for the business case document which is to show that the proposal:

  1. supports the organisation’s mission,

  2. is demonstrative of corporate values and

  3. is in keeping with current business strategies.

Internet searches should give you plenty of examples/templates. That it is is a persuasive document tells you that it needs to include pros and cons etc. Your business case needs to demonstrate, not only that what you propose is desirable but also that it is an appropriate activity for the organisation to be engaged in at this point in time. Easy!

If you’ve looked at a few examples/templates you might be wondering why they included ‘arguments against’, and what’s the difference between ‘pros Vs cons’ and ‘costs Vs benefits’. Stay tuned. Future posts will look at the anatomy of an argument, the art of persuasion and we’ll pick apart a template with a view to developing a deeper understanding of how to write an effective business case.