Some serious questions for anyone considering Cloud investment

On Feb 26th posted a piece in which I warned readers of the dangers of buying into CLOUD solutions without due care and without attention to all the little details they would pick through if they bought a small solution from me or even from an SME or “front of mind “,  big noisy solution provider. On March 1st 2017, Amazon went down to the shock and horror of the media at large. I promise you I had nothing to do with it, but I did get a flood of emails, some of them quite amusing.

Cloud services
Is the cloud right for me

The HIC problem

No I am not referring to the HICKs of Hicksville but rather to the much more common problem of “Hiding in Crowds”.  Closely related to the brand new evil you hear quoted everywhere, “ Populism”.
A populist is someone who, seeing his sweetheart taking a dip on the next plain, pretends to hear a lion and quickly convinces the herd to rush over there.

The HIC theory is sound enough for a plain dweller, if you are part of a large crowd the probability of being the one chosen for lunch by a marauder is very low, especially if you are careful not to stand out, I.E. don’t say or do anything different from the crowd.
If you are responsible for making key decisions on a modern organisation you can also retain some credibility after a disaster by saying , “Well everyone believed this at the time”,  or ” look at all the others who fell for it”.
If you are a responsible individual or if this is your own money at risk then you simply can’t afford to be a HIC.   What that means is making your own decisions on the basis of information, accepting the risks you can’t control and standing by your decisions, while always being open to new information and constantly monitoring your sources. E.G. You need to know who his sweetheart is.
Here are some thoughts to help anyone struggling with these decisions.

Business case for cloud investment
Building a business case for cloud investment

 

Some very strong arguments for investing in a cloud solution

  1. The IT department don’t want to give me a “NDB system” because it can’t be justified financially and won’t fit into the Enterprise Architecture just now. Who do they think they are, I’ll rent a cloud solution and I won’t even need to tell them let alone ask. That’s not as dumb as some might think. There are plenty of situations where this will be a good answer, just be sure that it is a temporary and not a long-term part of the business strategy and be absolutely clear that a: data is handled strictly within the law and b: You can get your data out safely when you need to and get it into another system. Remember you are responsible, not the cloud provider.
  2. I have no or an inadequate IT department and don’t want one because I won’t be able to control it. Instead I’ll get this cloud provider to give me the whole thing in one go and the problem is solved. You have to love it don’t you! If you truly do find the right solution available via this kind of deal that’s a big part of the problem solved, though by no means all of it. You are going to need a hell of lot of skilled man hours by some smart IT guys to arrive at that conclusion though and it will still be a best guess, just a very much better one.
  3. I don’t have and can’t or won’t raise the capital needed for this huge system I want, so I am going to rent it from a cloud provider and keep my capital working at the coal face. Not bad thinking on the face of it. Do consider the following: Are you really in business with insufficient access to capital to fund core process? I doubt it. Do you seriously make decisions about employment of capital in this way? Do you have a business case? If it says this is a good option, then given all the other ducks are in the right places, what are you waiting for?
  4. My business is made up of the original business plus a growing number of acquisitions around the globe, I am fed up of struggling with 7 different CRM systems and all the others, I want all of it in one system so nobody tells me again that the revenue from selling “tap”s was missed because 30% of sales were classified as “Faucets” and all the myriad of other such errors that turn my reports and dashboards into danger zones rather than information.
  5. I need my people around all of the group businesses working together to innovate and share ideas, but it is hard to achieve when they are working with so many different systems and using different vocabularies to discuss essentially the same thing. I want to migrate all of these businesses to cloud systems and administer them from Group Head Office, then we will be one business instead of 75
  6. I have fairly good systems and I am reasonably satisfied with what I have, but I need the ability to handle large demand spikes better and I need to prepare for an increase in the regularity and size of these spikes. Buying hardware to deal with this could be very costly and offer a low return on investment, given it would be redundant most of the time. I plan to extend my systems to encompass a cloud element so I can rapidly respond t short-term sever spikes in demand.

Some “gotchas” you really need to keep in mind

1 I need my CRM/ERP/other to be available via browser from anywhere in the world.
That is not cloud, that is Worldwide Web. It’s been around since the early 90s. You don’t need a cloud discussion, you need a web hosting provider and someone to find you a good free open source tool. If you don’t believe me, I have done tis more than once.

  1. My industry is highly regulated, e.g Pharma, Finance etc I need to bear this in mind.
    My personal experience of this is based on Pharma, but I believe the principles are the same.
    Right now there is a fledgling process for validating public clouds as suitable for specific types of data and sometimes or specific situations and geographies. Being a very new industry and a not well understood problem domain, the regulation is immature and almost certainly inadequate. If I were making a decision for the medium term, I’d be very slow to risk the future on what we know today and I certainly wouldn’t expose myself to any assumption that today’s regulation would be sufficient for tomorrow. Handle with extreme caution or stay way entirely is my personal view and that is based on knowing what we don’t know rather than any certainty.
  2. My business needs to be operating every day with no exceptions. Outbreak of war, epidemic you name it, this are more likely to be opportunities , or maybe the scenario is that I have a legal obligation to be operating. If this is you, don’t so it.
    a. Using the cloud depends on the internet and increasingly on mobile phone signals. This is still an area for very mixed quality of availability and signal across most of the globe, but do bear in mind that Governments everywhere hold an off switch for the mobile phone network and internet, any kind of political crisis can at any time lead to a black out in one or many regions. Can you handle that?
    a.i. The internet is not nearly as robust as people would have you believe. There are many points of failure and they are sought out and taken down from time to time. Logically, with all the publicity from the US election, this kind of thing will become more and more popular. Recently DYN the people who help with dynamic DNS issues were taken down bring the whole East Coast of Americas TV entertainment to a virtual halt and costing people like Amazon, Netflix and others fortunes in lost revenue. Expect more of this leading to more of above.

A.ii. Large providers such as Netflix for example are heavily exceeding their peering agreements or downstream traffic with the result that they are being throttled. This makes viewing almost impossible for many customers.  Such throttling is perfectly legal and it is likely to be used as part of trade wars between rivals. Your business could easily become the innocent casualty in one of these battles.

  1. Since my days in the broadcast industry I remember the affect Netflix had on the Amazon cloud when they were busy processing film. It was a well-known phenomenon and it lead my client of that time away from that solution. There has been a catalogue of large outages on a fairly regular basis since the beginning of the cloud movement and I fail to understand why somehow, senior CIOs clearly began to conclude that AWS and others were “Too Big To Fail”. Well that is reserved for bankers. The cloud can and will fail. It is technology and politicians don’t have much of value hidden there, so don’t be foolish about this.
  2. If the “Too Big To Fail” cloud provider fails, or decides this is no longer profitable, I must be able to replicate all of these services and carry on in business.
    Here is a simple piece of advice that I am grateful for having received a number of years ago.
    “Nobody sits around dreaming up risks that could not happen and writing complex legal clauses to extricate them form the risk situation when it occurs.” Let me translate that into simpler English; Read the legal contract, if the terms of the contract render the cloud provider blameless in such a situation, then they believe there is a really good chance it might happen and they know more about it than you do.

Unless you can build and rehearse a viable strategy for recovery given the reality of what might happen, you probably should stay away.

  1. Even if it were feasible, I wouldn’t put my entire business into a single cloud ERP and expect to live happily ever after, I need to be able integrate my systems in order that my people have efficient processes and data is not re-keyed repeatedly and I have an “almost trustworthy” view of the business to support decisions.

This is an area I have struggled with many times over a number of years and I can add to that the experience with non-cloud but WWW systems before that.   I have had a close and personal look at a number of leading cloud solutions and the variation in the quality of APIs provided is quite remarkable. One or two provided very consistent a comprehensive APIs, but the majority simply paid lip service the idea.
Even when integrating one of the better ones with systems “back at the ranch” we constantly ran into dead-ends where something we wanted, simply could not be done.
No is not a word I have ever accepted at face value and in the world of technology my first reaction always is, yes it can be done, even if we have to invent it. When your data is locked in a cloud data store that sometimes even the operator can’t understand with certainty and more to the point, you are not allowed any access to it, then it is beyond your reach unless the API provides access. Hence, “No API, no Data” Any architect will tell you to avoid going direct to the data store and I agree totally, but once in a while when the goals is big enough and there is no other way, it saves the day. Not with cloud services, unless of course you are referring to your own service built on PAAS or IAAS, see below. That is a different scenario and outside today’s scope.

               

 

Some definitions and buzzwords you need to keep an eye on

There are so many experts out there and so many levels of depth different people want that I hesitated to add this, but hopefully this will help some users. If you need deeper explanations google will find you more than you bargained for.

Cloud.  It began with the little cloud icons used to denote internet, and now it seems to have settled as any system you access via the internet rather than on you own infrastructure.  There is always an exception and this case it is the cloud you build on your infrastructure, see the next item and don’t get too hung up on this.

Private cloud.  This is about using the idea and the tools of the cloud to build a central resource on your own infrastructure.  The benefits are for example ability to virtualise servers of any size for a specific task  thus offering tremendous flexibility and potential savings, though licensing systems in cloud is a hugely complex area and a real minefield for assumptions about future costs.

Hybrid cloud This is simply a combination of the two above joined virtually to provide a single network so that the public part of your cloud appears and functions in almost every way like it were your local private cloud.  This gives tremendous flexibility with an ability to rapidly scale for sudden changes and reduces complexity at least at a superficial level.

 

PAAS.  This is really just the cloud providers renting you out the systems on which they build their applications. It is very similar in ways to renting virtual servers from a hosting organisation and building your application on that. The same principles apply. It saves a lot of time and capital investment and is especially useful when you want the ability to fail cheaply with something.

 

 IAAS.  This is as PAAS except that they are only renting you the infrastructure .
Within this are some very useful services that provide an end to end Continuous integration pipeline ready to log in and start developing software.  This is hugely valuable to software business not just impacting cost but also quality and consistency.

 

Previously

Good management strategy and practice supported by intelligent modern systems

Lernaean Hydra, your time is up.

Give big data the heave-ho for now and get a birds-eye view of your business without a single nosql database.

Here’s how we approached the solution

Naturally I can’t publish the whole thing if only for sheer volume, let alone sensitivity of information from some of the underlying cases, but I will pick a few areas just to demonstrate the approach and hopefully let readers see how. At this stage we have a high level description of goals we need to achieve, but before we get to the point where we have plans with timescales, budgets, resources, success criteria and all the other important things, we need to know a little more about what is involved in each solution, whether we have the capability to do it successfully, what order they need to be done in and what impacts positive or negative each solution might have. We also need to produce business cases to establish that the investment in the solution is at a level that provides an acceptable return taking into account any risks and opportunity costs and finally we need to establish measurement means and metrics in order to track benefits. Before thinking about delivery of something like this you have to first analyse the receiving organisation and understand the dynamics into which you are introducing solutions. Everything that is wrong is as it is for a reason and sometimes that reason is a force that is still in place and waiting to thwart your best efforts. Using models can sometimes be overkill, especially when used by enthusiasts rather than pragmatists. In reality if box doesn’t need ticking don’t tick it, but the time it took to decide that was a very small amount of time well spent in the interest of thoroughness.   Already, the small section of this picture we picked upon has exhibited a complex web of problems that impact each other in many ways and we have as yet not even attempted to find solutions. The identification of solutions and selection of the best approach to each is the next important step. Once we have this in place we then need to start thinking about how these solutions will be delivered successfully within this specific organisation.   In order to demonstrate the method, lets take some examples that are not too complex or too simple. I will select thre problems to address but later I will focus on just one of these in order to keep this readable. 1. Poor packaging. 2.       Poor help and support.  3. Low skilled staff. Having again used the “ask why 5 times” approach we came to the conclusion that: 1). Staff were not trained because we had no written materials with which to train them. Even the offshore staff could be trained if we had the materials. The reason for no materials is that we bought the hardware in Asia and the little black and grey manuals in 6pt txt were unreadable and unfathomable, but we just accepted this as par for the course in our business. We accepted it because nobody had veer suggested any other potential solution and there was a assumption that had we ever considered doing it, it was probably very expensive. The main reason though was that we felt we had already paid for this and were not willing to do it again. On top of this, there was no role in the hierarchy with accountability for the customer experience. 2). Help and support was poor because support staff had no idea how to help them and were only there to listen and to deal with total failures demanding returns. 3). The packaging was poor because we accepted the Asian packaging aimed at a different market, language, culture and price-point and never took responsibility for this, nor did we ever appreciate the importance of packaging in the user experience.  Visit diagram 1 in the last episode for a reminder of the user journey A simple dependency chart revealed the order of attack and we had a plan.

dependency
Dependency chart

There are a few headings you need to use when considering an organisation in this context: Here is an example of a very simple and fairly abstract table used for this purpose.

Goals Create legible training and help material Design attractive packaging and instructions Train the support staff
Participants   New people need to be hired or reallocated for this New people need to be hired or reallocated for this The people who develop the material are ideally placed to train as well
Social structure This activity has never been built into the structure and currently there is neither budget nor accountability in place. The knowledge Is with suppliers and in another language. . This activity has never been built into the structure and currently there is neither budget nor accountability in place Purchasing are money focused not customer focused and they buy this stuff in Asia very cheaply. This activity has never been built into the structure and currently there is neither budget nor accountability in place Sales staff walk away when the deal is signed leaving nobody responsible. Customer service is seen as a cost base
Environment This stuff is purchased by “Commercial”. They are a law unto themselves and seem to have gained almost untouchable status. Ideally they should be considering this type of issue when selecting a supplier. Sales won’t touch this.  It needs a place of importance in the structure This stuff is purchased by “Commercial”. They are a law unto themselves and seem to have gained almost untouchable status. Ideally they should be considering this type of issue when selecting a supplier. Sales won’t touch this.  It needs a place of importance in the structure No consideration has ever been given to training Recently we outsourced most of it and this has made matters even worse. Nobody seems to have much contact with the offshore call centres and it is a very hot potato just now
Processes The process currently involves receiving batches, spot checking goods and then checking them into the stock control system. QC happens again just before dispatch but it is poor and often there is an acceptance that support will have to carry the can. Sales have sold and dispatch have dispatched. The process currently involves receiving batches, spot checking goods and then checking them into the stock control system. QC has no interest in packaging they only consider the hardware items Nobody questions the quality of packaging, support or other peripherals. People ask the guy next door when stuck and they tell customers to read the manual, or they are if in doubt, to  send it back

Before you can attempt to drive these changes through, you need to understand the way decisions get made in this organisation. Remember we are not doing this with the intention of changing or fixing any of these behaviours, our only goal is to make the most of what we have in order to deliver our changes. There are three fundamental lenses we use to look at decision making in organisations, and in the interest of remaining jargon-free, lets call them Rational, Political and Garbage can. There is usually an element of all three but generally there is a strong leaning in certain functions such as in this case programme management. In this organisation it looked something like this: There are a few headings you need to use when considering an organisation in this context: Here is an example of a very simple and fairly abstract table used for this purpose.

Goals Create legible training and help material Design attractive packaging and instructions Train the support staff
Participants   New people need to be hired or reallocated for this New people need to be hired or reallocated for this The people who develop the material are ideally placed to train as well
Social structure This activity has never been built into the structure and currently there is neither budget nor accountability in place. The knowledge Is with suppliers and in another language. . This activity has never been built into the structure and currently there is neither budget nor accountability in place Purchasing are money focused not customer focused and they buy this stuff in Asia very cheaply. This activity has never been built into the structure and currently there is neither budget nor accountability in place Sales staff walk away when the deal is signed leaving nobody responsible. Customer service is seen as a cost base
Environment This stuff is purchased by “Commercial”. They are a law unto themselves and seem to have gained almost untouchable status. Ideally they should be considering this type of issue when selecting a supplier. Sales won’t touch this.  It needs a place of importance in the structure This stuff is purchased by “Commercial”. They are a law unto themselves and seem to have gained almost untouchable status. Ideally they should be considering this type of issue when selecting a supplier. Sales won’t touch this.  It needs a place of importance in the structure No consideration has ever been given to training Recently we outsourced most of it and this has made matters even worse. Nobody seems to have much contact with the offshore call centres and it is a very hot potato just now
Processes The process currently involves receiving batches, spot checking goods and then checking them into the stock control system. QC happens again just before dispatch but it is poor and often there is an acceptance that support will have to carry the can. Sales have sold and dispatch have dispatched. The process currently involves receiving batches, spot checking goods and then checking them into the stock control system. QC has no interest in packaging they only consider the hardware items Nobody questions the quality of packaging, support or other peripherals. People ask the guy next door when stuck and they tell customers to read the manual, or they are if in doubt, to  send it back
Programmes Commercial Sales Operations
Rational behaviour   Logic and rules above all else, including sometimes common sense Programmes insist on business cases and examine the rationale when a project or programme is ready to begin All decisions are made on a cost basis and calculated don to small fractions of percents Most decision are driven by pound and pence targets Ops is mostly rational and processes are driven largely by systems
Political behaviour   Worrying about impacts on self ahead of all other concerns There is a Program Office that insists on following certain procedures and everyone in this is very careful to be seen to follow he rules regardless of the outcomes of their chosen behaviour. There is some political thinking in terms of correct behaviour when dealing with vendors but apart from this it is not a prevalent force. If anything the odd corner is cut when maybe it should not. Lip service is paid to the rules but they are broken as and when it can be done without too much risk. The outcome is everything even at the expense of negative impacts The rules are more important than the outcomes in Ops, nobody gets sacked for following the rules
Garbage can   Jostling to get own pet projects ahead regardless of what is  best for the business Deciding which project gets started and funded is almost entirely about jostling for space and funds with others. When it is politically favourable then old campaigners will quickly suggest their solutions to the problem of the day ad grab some budget. For all the process, it is mostly organised anarchy No real evidence of this behaviour mode This months target is more important than anything including the long term good of the business Little evidence of this behaviour

Who are the key stakeholders and what is their interest? Now lets diagram the key stakeholders who can impact delivery of our project.

stakeholder proximity chart
stakeholder proximity chart

Above you see a representation of the various groups involved and the distance apart represents their level of interest and involvement.  The ones outlined in Orange are the ones directly impacting the customer experience though as you can see some could scarcely be more remote and detached from it. Others such as finance and Purchasing are key drivers if not always actors in the state of customer experience, though mostly unaware and disinterested. Clearly there is work to be done to rally these stakeholders sufficiently to deliver a result.       Here is another view from a communications viewpoint communications matrix

  1. Clearly we need to convince finance to release some capital. Finance are mostly outcome driven, though they also like to stick to process so  until we present a strong business case correctly presented, we will not achieve much.
  2. We need Operations and Customer services both to adapt new ways and this will stir up certain rivalries that need to be handled by HR.
  3. We need HR onside for process changes, but also because we are recommending a Head of Customer Focus to champion the customer experience and have jurisdiction across channels and across departments form the proposition right through marketing and sales and support and who above all else, will be accountable for customer experience. We need a well defined and supported plan with clear structures and accountabilities for any changes and enlist HR in refining this, debugging it and implementing it. We can then get their moral support.

 

  1. We need Purchasing to get much more involved with the customer experience aspect so they understand the total cost, not just the hardware when making their decisions and we need to communicate better with external and offshore customer service people. This will be a substantial change for purchasing and will need to be carefully planned with HR to ensure there is sufficient incentive. .

Finally we will need to take a closer look at the technical situation to see what is possible and how big a job any changes might be.   The technical solution was twofold.

  1. We needed to purchase a  Knowledge Management System to keep track of the training materials and make it available to the website, the trainers and the customer service staff as well as to the SME and author teams who would keep it up to date.  There are many good COTS versions available and this is a straightforward technical solution.
  2. We needed an ESB solution to hold a single copy of each piece of critical information in SAP so that we could access it quickly in high volume and without putting any strain on the SAP installation. This we would need no scaling of SAP and no high cost integrations for each new web page or system. A standard ESB would provide simple APIs, web services and publish subscribe PUBSUB approaches for our dev teams.

Before   before integration architecture or as-is     After Integration target architecture   The programme plan     Let’s now create a first draft of the programme for this one chosen problem of high customer support  costs and low customer satisfaction. Do remember that we are not trying to document an entire programme in a blog and there will be major omissions, but do feel free to bring this up in the comments section. Below are the key headings

  1. The vision and benefits. Important changes in any organisation or even in an individual rely on beginning with a clear vision of the future and why you want to get there. This vision should motivate you along the way and provide guidance in times of ambiguity. The benefits should form a solid business case and stand up to close scrutiny.
  2. The journey Every vision entails a journey and it is made up of a beginning, a middle and an end. The middle will develop fully later when we get into project planning, but for now the” where we are”, “where we want to be” and a high level understanding of “how we will get there” is what is needed to get off the ground. The important thing about the middle is that we include the business and IT changes required to drive benefits along with technology.
  3. Knowing when we have arrived. Benefits measurement strategy and progress monitoring are both part of this.

We must have a measurable outcome to focus on even if the measurement metrics seem vague to some, we also need a way of knowing how we are doing while still on the journey to the first deliverable. Remember that there are usually deliverables in the sense of process, or technology to come first and quickly followed by business change and benefits realisation. Before the process or technology changes are made there is no opportunity usually to begin on delivering and measuring benefits. I am not about to blog an entire Programme plan so I will leave you t imagne the remainder.

Why the SMB/SME holds all the aces when it comes to IT

I know you probably wanted me to tell you how unfair and inequitable the world is and how tough it is to be small. We’re in that sort of phase just now. Well you are going to be disappointed, but I challenge you to read on anyhow.
Not only is it easier, cheaper and less risky to implement state of the art IT, but rarely do your big brothers tap into the advantage effectively once they have implemented it. Now there is a new twist that puts the smaller business back at the cutting edge.

Small is beautiful when it comes to costs

When I rolled out a nine million pound IT investment for a government department, I spent more than a million getting the messages through to the workforce that things would be changing and preparing them and yet another million fighting the bonfires to get it rolled out and accepted.
When I rescued a large project a few years ago, they had already spent close on a million on feasibility and had got nowhere with it.
Implementing a mission critical system for a huge nationwide organisation, I got to roll-out stage and not even the CEO could make IT go any faster, we waited three months while they  put us off with new problems each day and they negotiated for increased budgets for running the system that would have supported a medium sized island, despite having agreed all of this previously at planning stage. Each slight effort from IT requires forms, a process and a very long wait.(Partly justified, because bigger IT comes with bigger risks).

Small is beautiful when it comes to change

Bringing about even fairly small changes in a very big organisation is slow, very expensive and not at all guaranteed.  The employees have no sense of connection to anything , or anyone, it’s just a huge employer and change is inconvenient. Customers have a stronger relationship with the brand than employees with their management and shareholders. Established employees can easily resist change without suffering any consequences and often do so just to prove that they can.

When a big business is forced to compete with small business on a level playing field, it is like a train attempting to  catch a rabbit.  Trains are only good for long straight and fairly even roads. While the train is moving the tracks, the rabbit is enjoying the grass on a greener slope.

Business case

The average cost of a feasibility study and business case for a large business today is estimated at around £60,000. There are more stakeholders with more complex propositions and communication grinds to a slow shuffle. There is usually little or no true big picture and everything you produce then has to be reviewed on the basis of, “do I really look like that that?” .I recently completed a feasibility and prepared a business case for a large SME/SMB and it cost just  £7k.
Rapid painless implementation
When that business described above comes to implement their plans, the system will be hosted on the cloud without a single click of a mouse by their IT department and it will be running and operational in a one day.
It will have world class back-up, disaster recovery, failover and  all the things an SME/SMB struggles to afford and  it will be maintained 24/7.
They won’t buy any hardware or purchase anything up front and their modest budget will be spent on improving their business to take advantage of the new system’s capability, communicating their requirements accurately to the service provider, training people to make their lives easier and their jobs more secure with this new super tool and getting their data into good shape to take maximum advantage.
 Dynamics of IT investment for the SME/SMB
 Where has all the money gone?
 About the author

 

 

 

IT investment for the small businessman and novice.

Previously:

The advantages a small or medium business has  over their larger competitors and how they can save vast amounts of money in implementing high productivity software and gain the benefits faster.

1. It investment should never cost you money, it is an investment and the ROI should be clear.
 Build a business case professionally and then invest with confidence.
The question to ask is; who would you rather trust with your capital, your own business, some investment bank, or maybe a fund manager?

2. Cash invested in your own business via IT systems or any other properly planned investment is always going to outperform any other investment and it remains within your control.

3.  In a free market economy, you always have to match the performance of the market leaders sooner than most of your competitors, or you are out of business. It’s not optional.  If they have automated successfully, you are at risk until you follow suit, or outdo them.

Types of IT investment

One thing every business man/woman or at least his/her CTO should understand is the dynamics of costs and returns  for different types of IT investment in different sizes and types of organisation and for different purposes.

There is absolutely no broad sweeping brush that can be used here and there are few reliable rules of thumb.  There are huge risks for the unwary and there are massive opportunities for the savvy, there are things that are not optional and things that are very much optional.

IT infrastructure versus productivity systems

The first big source of confusion is between the purchase or replacement of networks, servers and workstations, printers, operating systems and office systems like Microsoft Office.  The risks of a failure are dramatically less in this area and the potential to realise benefits and make gains are also much less.

Putting off the upgrade of workstations or operating systems by a year will rarely have any effect on bottom line unless you are losing time due to stoppages and unreliability.  This is an area where business cases need to be scrutinised with great care.

1.       Unless there is real risk of lost productivity, or very high maintenance costs, it is going to be hard to justify not keeping the old stuff as long as possible.

2.       Upgrading to smarter tools with new cool features will only benefit the one or two geeks on the team unless you take steps to train people on the new capabilities. Is that included in the business case?

Automating process

This is what business systems are really all about. The database replaced the card index and made it possible to share that information with colleagues globally, to search on fuzzy logic and to send a message at a single mouse click.  This was a pretty easy decision on hindsight and the business case is obvious now, but at the time, ditherers and weak leaders continued with their card indexes until they saw their customers walking into their competitors arms.
Plenty of leaders continue in the same vein today and every new step forward in technology will have innovators, early adapters, last minute Harrys and hard luck stories.

Technology is not the enemy

Since records began, businesses have had to find ways to deliver better products or services, do it at lower costs and win and keep more customers. There’s a percentage at the top end of this battle and there’s a percentage on the way out, the rest are headed in one direction or the other .  Businesses that choose to close their eyes to the importance of technology in this struggle have already consigned themselves to the scrapheap.

Face facts and make the most of it
Success at harnessing technology requires understanding a few basic rules and working with people you can trust to deliver.

Strategic advantage or state-of-the-art

The first big differentiator between software systems is their status in your market segment.
If you are considering a system that you hope will bring you in line with the main players, then this is probably “state of the art”, though if you are a long way down the pecking order it may still be classed as “strategic advantage“.
E.G.  If you run a large business carrying out maintenance type work like Sky TV maintaining satellite dishes, you will have automated scheduling that plans the shortest routes and sends jobs directly to the engineers PDA or mobile.   This has cut operating costs by 25% on average for these businesses and is a fast maturing industry.   If you want to bid for sizeable projects then you won’t stand a chance of winning competitive bids unless you have this in place.  That’s “State of the art” IT.
If you run a local cleaning business with a few dozen teams in vans and you are growing and ambitious, you probably don’t have this systems yet and your direct competitors probably don’t, so to you it is still probably “Strategic advantage” IT. If you are serious about growing, guess what you will be planning now!

Not only will the ambitious smaller firms be scrambling to get this competitive advantage, but the guys at the top are already planning to push the bar up higher and guess what you will have to do when that happens!

There’s one fact that is simply unavoidable whether it thrills you or fills you with horror;
Competing and winning in business in the 21st century is primarily about winning the technology battle.
 Where has all the money gone?
 About the author

  

 

 

 

 

 

  

 

 

 

 

 

Delivering benefits is no longer about getting a system signed off

(Who’s minding the shop?)
This blog is an attempt to stimulate discussion and understanding of the balance of responsibility for delivering business benefits from IT investment.
It is now fairly widely recognised that this is not as simple as choosing a system, getting it working and reaping the benefits, but as yet we can call on very few examples of good practice in making it work.
The business argument.
We have no time for discussions about how it all works, we just want a business case and if it gives us the ROI we need with acceptable risks, we want to do it. At least that’s the CFO’s line. In reality, many of these projects begin life as pet projects of the CEO, or other senior manager and it is clear from the outset that the question is not will it work, but make it work.
This is largely an understandable attitude, because businesses must be directed and managers must manage and sometimes the outcome can be a life or death one.
The IT supplier argument.
Be the supplier an in house department or an external supplier, the situation is not hugely different. The supplier tends to confine their responsibilities and activities to making the technology work. Better suppliers provide advice and guidance on rollout, but that is the limit of the activity and there is no responsibility beyond meeting technical requirements. This is wholly understandable, because the supplier has no control over whether the business case was correctly put together, whether the requirements were detailed enough or whether the culture is sufficiently flexible or disciplined to make the new system work and deliver benefits.
So who‘s minding the shop?
Well the answer very often is that nobody is minding the shop. Rarely is anybody in the business equipped to do this job and the suppliers are not getting involved.
The most usual scenario is that the system is delivered and there are issues and misfits that become immediately apparent, then there’s a return to the drawing board and changes are made and a re-launch and things are much better. Often you’ll find a new project with a new name the following year, billed as an upgrade and it finally knocks the thing into shape. Two years late and dramatically over budget the project is complete and nobody ever asks whether it delivered benefits because at this point the busines is bus with a whole new set of issues.
The other common scenario is that a consultant is hired to manage the project, he/she is expected to have a project management qualification PMI/Prince etc and have handled one of these type of projects before, maybe even in this industry.
Often the contract is already in place, the product defined and dates and budgets set.
Where does a Consultant go from here?
1. Recommend someone else who needs a bit of experience.
2. Take it on and hope for the best
3. Challenge the client at interview and get passed over as wrong attitude
4. Take it on and then challenge the client later via a robust consulting methodology
5. Challenge the client at interview via a robust consulting methodology
6. Offer to challenge the project’s soundness for a reasonable fee and provide a dispassionate report.

When is a business case not a business case (part 4)

 Read part one  Read part two Read part three  Read part four

In our previous instalments we discussed the preparation of a business case and calculation of the data needed to prove it.

Today we will be discussing the art of delivering the business case in such a way that it competes on a level playing field with all other initiatives currently on the agenda.

There a re a few fundamental rules to bear in mind when presenting any proposition:

1.       Recognise and understand your audience so that you can directly target a known need or desire with your proposition.

2.       Use the appropriate language and context to present your proposition.

3.       Get your timing right.

4.       Demonstrate understanding of and sensitivity to the operating environment.

 The first paragraph should always be entitled ‘Executive Summary’, but it should be the last one written.

The next paragraph should be a backgrounder that demonstrates succinctly and understanding of the operating environment, I.E. political, environmental, social, technological.  Make sure you don’t fall into the trap of contradicting the CEO. Work form the five year plan or current year plan or what ever is the most relevant document and if there have been significant changes in the operating environment since it was written then discuss it with senior people so that you reflect it accurately and delicately.
You may find for example that the CEO published a plan for robust growth ina bullish market three years ago and the CFO is now investing inwardly in cost avoidance projects while they watch the news with interest for an indication of the way forward.

In this case you need to be able to reflect this in your businss case so that it sets the scene for your cost reduction proposal.
 When it comes to writing down your propositions, bear in mind that there will be two distinct audiences, those who want to scrutinise the details and those who want the bottom line only.
The latter type will very often be relying on the former to take care for the detail for them so it is very important that you address each in the appropriate manner, presentation and language.
In part two we drew a map that linked features to benefits. In this section we will expand this idea further and we will map those benefits to stakeholder driven propositions.

Here is a simple example from my own experience.

Strategy and KPI mapping

 Strategy and KPI mapping

 In the diagram above we can clearly see that the CEO has published a key goal for the current period which is to improve net profit margins by 1 %.
 The CFO has a related KPI called indirect costs/sales volume and he is hell bent on improving this KPI by 1 point in order to meet the CEOs  goal.
The Operations Director is working on a goal to reduce the paperwork element  involved in picking, packing and shipping products, while maintaining or improving delivery success rates

In your business case the value propositions would address each of these stakeholders in his/her own terms and use context to draw an accurate picture of the scale of benefits.
E.G.
The proposed system will positively increase net profit margins by a factor between .2 and .4% in it’s first year of operation and reach breakeven in the first quarter of year 2.

In achieving this, it will increase the costs/sales volume KPI by a factor of around .3 through virtually eliminating the paperwork involved in the picking, packing and shipping aspect of operations.
Additional benefits will be reduced propensity for error in this area that we have not attempted to quantify.
For detailed breakdown, see the financial analysis section.
You will note that this sentence describes the system in terms of benefits that can be readily understood and appreciated by each individual stakeholder.
By quoting KPIs the scale of the benefit is immediately put into context so that you capture the attention of your target readers.

Presenting the figures.
You don’t need to be a financial analyst to figure out that bringing in benefits early has a dramatic affect on the financial results of your project.  If you cast your mind back to part three when we talked about Net Present Value (NPV), you will realise that bringing in, or saving  a million next year rather than the following year, supposing a discount rate of 10% will deliver an extra 100,000 in benefits.  Not only that but it reduces the total investment required, thus improving ROI and freeing up capital for other important projects.

This simple exercise will help you optimise your business case by bringing forward benefits where it can be done.  You may remember that in part one we talked about listing the features and benefits that make up your projects and creating metrics for each feature.
Here is a simple tool we use to prioritise these features.

Tool helps with prioritising features

 If you need to analyse more complex and more data rich cases, then a Pareto chart can be an excellent way to single out the low hanging fruit.
For non financially aware people you may be able to put the benefits in context by taking the ROI and calculating how much extra revenue it would take in order for the business to deliver that same return through extra revenue generation.
In order to make this case rock solid you need to also present at least one potential alternative tactical solution and a do nothing scenario.
In your final analysis, you will compare the do nothing scenario, the tactical solution and the proposed solution and demonstrate clearly the basis for your proposal. 

Project plan
An indicative project plan should be included in order to demonstrate the likely timelines including benefits realisation activities, implications for personnel, budget and  team structure.

The executive summary.
In this section we always place two things:
1.       Our proposal, stated in direct no nonsense language aimed at all relevant stakeholders jsut as we discussed earlier.

2.       Our paragraph of analysis that briefly describes the alternatives and the rationale behind our proposal.

The executive summary should contain nothing but the bare facts and concise value propositions, no rambling intros or winding up paragraphs. It is a business document and it is about cold hard cash so keep it clean and factual and get straight to the point.

Sign off sheet
Don’t forget a sign-off sheet so that they are very clear of the immediacy and urgency and the fact they will be expected to make decisions as opposed to having a discussion.
Presentation

n order to present the business case, our strong recommendation is that you produce three artefacts.

1.       The full business case

2.       A one page summary including the executive summary  and financial conclusions

3.       A presentation of four or five slides demonstrating pictorially, the background, the benefits, the financial analysis, the project outline.

The first  communication should be the short summary sent by email to the stakeholder list along with an invite to discuss it in a formal setting.
The second communication should be a presentation of the business case with opportunities for questions and answers and the full business case handed out about half way through the presentation once the key points have been presented.

  Read part one  Read part two Read part three  Read part four

 

Reblog this post [with Zemanta]

When is a business case not a business case (part three)

Read part one   part two Read part three  Read part four

In this part I will be talking about  the importance of the financial analysis and the practicalities of putting the figures together.
After all the bottom line in any busines case is going to be financial although individual stakeholder priorities and concerns will play important parts as will the organisation’s history with similar projects and even good old office politics will often play a part.

At this point I would caution that despite the importance of the figures, it would be foolish to present a business case without taking into account the stated aims of the business in it’s short and long term plans and the key performance indicators and critical success factors of the key stakeholders.

If you are able to tie your benefits very clearly and distinctly to the corporate goals and to the personal KPIs of your individual stakeholders, then you stand a much greater chance of getting their attention and you may even be able to enlist their help in fleshing out your arguments.
You will also have an aopportunity to spot delicate or contentious areas that are best played down or avoided.

The approach to financials

Financial decision based on Cost v benefit v risk

When approaching financial analysis for a business case, three subjects immediately emerge as important topics:

  1. Cost benefit analysis
  2. Quanitfying and presenting intangible benefits.
  3. Risk/reward analysis

The reasoning behind our approach is simple.
Ultimatey, your business case is about costs versus benefits so a good estimate of costs is critical alongside of a realistic estimate of benefits.

The majority of projects bring benefit that are not easy to measure in reduced costs or increased profits, but are nevertheless important and valuable.

Given that some benefits are easier to hook and land than others, it makes perfectly good sense to have an indicator of how likely you are to succeed in delivering the benefits and to stay within cost estimates.
This way you are able to cherry pick the projects that suit your organisation’s current appetite for risk and you have an option to delve further into risk management if the potential reward is particularly attractive.

 Positioning the business case
It  is important to position your business case and calculations correctly from the outset and to put in the appropriate level of analysis and checks in collating the figures.
This activity will begin as an outline business case offering your best estimates based on hard data where available and tacit input form key stakeholders to fill the gaps and make adjustments where appropriate. This type of estimation is often described as stake in the ground estimation. It’s purpose is to decide whether a initiative is worthy of pursuing further.

Later after you have received appoval to proceed, you will continue to refine all the estimates until you arrive at a baseline part of the way through the project.

Doing the mathematics

Rule number one;  Unless you are trained in financial analysis, put somebody else in charge of this part of the work and act as the collector of data. If you can’t delegeate it then you are still going to need close cooperation from the finance department to get access to key numbers and you will need them to scrutinise your figures before you show them to anybody else. 

The financial benefits can generally be described as either of Cost avoidance, or Increased revenue. These events have very similar effects on Return On Investment (ROI).
A key measure for most organisations will be ROI and a simple viewpoint can be that the project represents an investment of capital in the hope of achieveing better returns than it could achieve elsewhere.
One of the options for investment of retained capital would be the equities market though the key indicater here is the organisation’s Cost of Capital.  This figure is unique to every organisation so you need to find it out.

Costs

First you need to do some good old stake in the ground estimating of costs. Use as many reliable and respected opinions as possible to get ballpark figures at the start and refine this with as much verifiable data as you can get hold of. You can also try some online tools like Gartner TCO analyst, WIPRO TCA tool, or a number of services available online.

Look through old project budgets if you can and learn from experience to make sure that you don’t leave important costs out. Nothing can erode your credibility quite llike having a glaring ommission pointed out to you in front of the board.

 If you are estimating costs for a new  CRM system for example,  you can begin with internet research and you will find detailed case studies and benchmark costs there, which give a very useful starting guide once you factor in comparisons of scale and other knowns.

Next you can look at the organisation’s history of deliveirng similar projcts. This is a critical sanity check, because not all organisations have the same capabilities and you need to estimate realistically. Look at similarly sized projects and similarly complex projects and look for overall time, scope creep, cost escalations and the obvious areas of weakness.

Factoring this information into your initial estimates will give you a very sound footing for moving forward to attempting an actual breakdown of costs:
Typical project deliverables are a useful way of making sure you cover ebverything; Project planning, management, requirements analysis, licensing, etc until you have a comprehensive list.
You wil then need to seperate the ongoing costs form the capital costs. E.G. Support, annual licenses etc.

In the case of an IT investment I would generally expect to have three columns in my spreadsheet to cover three years going forward.
Now total up all of your costs for each year and make sure to account for indirect costs with a best estimate.
The last step in calculating costs is to apply a confidence level to each calculation based on the maximum you expect it to slip. E.G. you predict that testing will cost £100,000 and you expect that the most it could slip by is  8%. Your confidence level  8% the max figure is 108,000

Tangible benefits

Once you have finished calculating the costs, you can begin to calculate the tangible benefits.
In most cases this is a fairly simple set of calculations such as 20% reduction in returned goods.
cost of a single return = n total saving per annum = n * 20% *average returns level.

Always remember to do simple cause and effect analysis to determine what extra benefits might accrue that could be included and to be aware of any adverse effects that might result. The approach should be the same as with costs, the more collaboration you do, the more beleivable your results wil be and the more buy-in you will get.

Intangible benefits

Bit by bit organisations are coming to accept that intangible benefits are important and should be measured and accounted for. The difficulty is that measurement is as yet not a science and the responsibility of signing off large budgets without masurable benefits is too great for many senior executives.

The reality however, is that intellectual capital, the real classification of these intangibles is a major part of the calpital of every organisation and becomes especially noticeable when valuing a business for sale or valuing an equity. The business with an innovative loyal staff, an attractive location and great reputation is infinitely more valauable as an assett than an identical organisation without these attributes.

Physical and intellectual capital in an organisation

Above is a view that illustrates in a very simple way the part played in an organisation’s value by intellectual capital. The type that might be dismissed as intangible unless you make the attempt to represent it correctly.

One area where some progress has been made is the company Brand.
E.G. A favourite areas of disagreement used to be the expenditue on building and maintaining a brand.  CFOs were reluctant to sanction spendng on what they often saw as “pink and fluffy stuff ” that delivered nothing at the bottom line.
Recently Coca Cola had their brand revalued to $67.5 billion dollars and you can bet your last dollar that it appears on the balance sheet.
Today it is easier to get  formula for calcualting the value of the brand than it is to get a sensible definition of what a brand is, so don’t be put off by apparently intangible benefits. Tackle them and tame them.

There are three approaches that we tend to use most:

  1. Take the same aproach as brand valuation, I.E. how much more would the business be worth with a better reputation in the recruitment market and first call on the brightest talent.
    This type of calculation can be easier to do than seems apparent at first. If you can get hold of competitive analysis reports it will be easier still because the strengths and weaknesses of immediate competitors wioll be listed there and you can aim right at the bulls eye.
    Once you have made an estimate add a sensible confidence level to it and run wih it.
    Once again, remember to be collaborative and to bear in mind the language and culture of the orgnisation.
  2. Identify a KPI that will be significantly afffected by the benefit and discuss it with the owner of that KPI.  Perhaps the HR director is tasked to reduce staff churn and has a KPI measuring this.  Ask her to help you work out the value to the business of imporving that KPI by 1 point.
    Armed with this estimate, predict how mny points you expect to improve it by and then calculate the financial benefit. Again apply a sensible confidence metric.
  3.  Track benefits via impact analysis, represent this on simple fishbone charts and then quantify the bottom line beenefits that can be identified.  E.G.  Improved reputation as an employer -> reduction in churn -> reduced costs of recruitment (£) + More skillful staff -> win bigger projects from competitors ->(£)

Now that you have done the figures it is a simple matter of presenting them in a table so that they can be easily evaluated.

In my example you will notice that I have included my confidence levels on a seperate row so that the reader can take whichever view point he/she wishes.

The only  calculation we use in a standard business case is the NPV. This represents the Net Present Value of a sum of money, I.E the value of that money in todays currency after factoring in Cost Of Capital.
E.G. It is infintely better to have a poundt in your hand today than to receive it in three years, because it will purchase less in three years.  In the NPV calculation we use the same thinking except that rather than inflation we use a Discount Rate that is based on cost of capital, because to better represents the investment options for that capital.

It is key to get the cashflows right i.e. to work out a benefits schedule, because you need to know when cash is coming in and going out if you are to calculate NPV.
Once you have this in place you can use the NPV function in Excel to calculate the NPV for you.

The Payback period is a straightforwar and obvious calculation and the Internal Rate of Return (IRR) is just an interest rate representing the return on the investment of capital.

 

Year 1

Year 2

Year 3

Delivery costs

 (£6,256,871)

 

 

Delivery incl. risk (n%)

(£917,142)

 

 

Ongoing costs

 £0

 £0

£0

Ongoing incl.  risk (n%

£0

£0

£0

Benefits

 £11,896,000

£11,896,000

 

Benefits less risk (n%)

 (£4,664,800)

(£4,664,800)

 

Net Cash flow

 (£7,174,013)

£7,231,200

 £7,231,200

Options

(£1,600,000)

 £66,650,000

£66,650,000

Options risk

 (£45,060,000)

 (£45,060,000)

 

Net options

 (£1,600,000)

£21,590,000

£21,590,000

Discount rate

 15%

 

 

NPV

£3,984,186

 

 

Payback (months)

12

 

 

IRR

 63%

 

 

 Risk analysis

As you will have noticed we built the risk analysis into the individual calculations as opposed to applying it to the whole calculation at once.
If this is a sensitive area, then it is a simple matter to calcualte these elements as an overall cost risk and overall benefits risk and look at best and worst case scenarios.

 At this point we have a fit for purpose finacial proposal and now we need to set about optimising the presentation.

 

 

 

When is a business case not a business case (part two)

Read part one   part two Read part three  Read part four

In this section I will be talking about benefits, why they are so important to the business case and how they can be tracked right through the project, thus making the business case  a key document in successful project delivery, rather than just a tool to get the budget released.

Benefits map diagram expains the bridger method of mapping requirements to benefits

The model above illustrates our basic theory of benefits delivery.
On the left side of the diagram, we represent high level requirements.
This is intended to illustrate the level of requirements that is generally outlined in the business case.

This requirement is then tied indirectly to the composite benefits illustrated on the far left of the diagram. These benefits are the ones providing the key arguments for action.
That part of the model is very simple and intuitive. We have high level requirements and we expect to deliver the identified benefits.  The denotes that this metric is to be measured.

A key element of this approach is to remember at all times is that the requirement exists in the business case only to deliver the identified benefits and any change to the requirement or surrounding circumstance that impacts it’s ability to deliver these benefits is a red flag issue and must trigger a business case review.

The devil may be in the detail

 Between the high level requirement and the composite benefit, naturally, lies a lot of very important detail.  While this detail is not represented in the business case, but in other documents such as requirements specifications and benefits realisation plans, the exploration and bottoming out of this detail, will be critically important to the final conclusions of the business case process.


We look at this benefits mapping activity in terms of feature level requirements I.E. identifiable succinct features of the product or deliverable and with this we associate two things:

  1. The measurable benefit that is expected as a result of this feature, along with a suggestion of how it might be measured.
  2. The risks management attached to realising this benefit.  We describe it as risk, because we want to confine the change management activities to those that are necessary in order to deliver the benefits.

By taking this approach, we are proactively testing the likelihood of our successfully delivering the benefit and we are planning the change activities required to ensure that they are delivered.

Benefits realisation example

E.G. In the CO2 example, we may have assumed a fuel saving of 1000 gallons per month resulting in a measurable reduction CO2 emissions.
In order to actually realise these benefits, we might have to take steps to ensure that all the lean cars are not last to be taken from the car pool, while the big luxury ones are first choice. The approaches can vary considerably, but they have to be planned and in many cases included in the costs of the project.

Without this risk assessment and change management activity, the likelihood is great that the potential impact of replacing luxury cars with lean ones will deliver little or no benefit to the environment or to the organisation, No ROI and a project failure.

Now if we look again at our diagram, it may become obvious that we will have quite a few of these feature level requirements and that each will have it’s own mini business case including the level of ROI and the level of risk attached to delivering benefits.

 As the project takes shape and more is learned about each of these requirements, this mini business case needs to be constantly reviewed and updated so that poorer candidates can drop off the radar and stronger ones get promoted to a higher priority.

Approaching the business case in his way and continuously managing it as the development continues from outline business case to full business cases will keep the business in control and minimise the likelihood of pursuing projects that perform below expectations.

 Read part one   part two Read part three  Read part four

 

When is a business case not a business case?

Read part one   part two Read part three  Read part four

  1. When it establishes that there is no case for the proposed initiative.
  2. When it fails to identify and present the benefits of the propsal sufficiently well to win support.
    Both of these situations have the same result only the second one is a lost opportunity for the business.
    A process for deveoping the business case for IT change

You can talk to five different people who have that word in their CV and each one will probably have a different take on what a business case is for, who should prepare it and what it should contain.
In fact, you could say that  the whole science around business cases, especially those involving IT investment has moved on substantially in the past two or three years.

Many of the concept of benefits were rarely discussed ten years ago, let alone benefits realisation.  Today all that has changed. Some examples of the importance this subject has achieved is the Cranfield university  Benefits Dependency Network Tool  and more recently the Microsoft REJ framework.
Here is a simple explanation that takes into account more recent developments in thinking and puts a simple framework around what a business case is and is not.
1. A business case must live up to billing and make a case for the proposed project. That means demonstrating how the project will deliver benefits for the business
2. A business case should take three forms,
a. Initially it should be an outline business case. This is a non detailed and very tacit explanation of why some very knowledgeable stakeholders feel that this is a very good idea.
b. A full blown business case with detailed cost benefit analysis and detailed financial calculations such as ROI, EVA, IRR,NPV etc
c. A one page summary of the final business case for people with little time for detail.
3. A business case must take a analytic view and not be an excuse to purchase my new toy, hence it should examine tactical solutions and doing nothing.
4. A business case should take into account political ,economic, sociologic and technologic trends likely to impact on the projects ability to deliver
5. It should take account of the organisations ability to deliver the project and realise the benefits.
6. The business case should always be a living document that is carefully managed by someone who carries a key responsibility for the project.

The diagram above shows a simple process for producing and managing a business case.
The top section represents the activities that generally occur prior to going into the implementation phase of the project .
The bottom section represents the activities that continue during and after implementation.
The first priority is to expand a little on the initial concept and capture high level requirements.   In dong this it will be key to get an understanding of the benefits hoped for by stakeholders and to abstract form them the knowledge and experience that has lead them to this conclusion and the assumptions that are underpinning it.
Next a high level examination of the potential solutions, include the ones that are likely to be already suggested, a do nothing scenario and a tactical solution.
From here an outline business case can quickly be created that encapsulates all the motivations, expectations and tacit understanding of the problem and potential solutions and provides a building block for stakeholder mapping.
In the next instalment we will look at some of my favourite tools for helping to create a business case that serves it’s purpose.

Read part one   part two Read part three  Read part four

 

Reblog this post [with Zemanta]