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.

 

Communication for project managers

Introduction to the series.comms encoding

This series was inspired by the growing concerns expressed by project managers about the demands being placed on them to be communicators, ambassadors, PR experts and even Marketers as they attempt to deliver complex change projects into organisations, especially in the IT field but not exclusively.
Whether you are moving 1000 people to a new location or asking them to stop doing things the way they do and trust you that a new system will work better, the challenge has been raised and if you are not equipped to meet it your project stands a poor chance of succeeding.

About the author
Before you even consider communication with any audience from one person to 100 million people, you need to first gain their respect and trust. If you don’t, why should they listen to you.
Just like you they are bombarded with messages all day every day and they only have time to listen to a choice few that come from trusted sources , that gain their attention and arouse their interest.
Gain  their respect.
Don’t assume that these people know who you are and respect your knowhow, or your authority as the case may be. If you are sent by the CEO, then tell them up front and try to get some demonstration of this from the CEO. If you are offering them expertise, then tell them about your skills and background so that they can judge it for themselves.

Gain their trust

Trust is the most important part of communication by a long shot. Respect and trust are related, but not the same. You can win respect through winning trust, but not necessarily the other way around.
If I am to interrupt my busy day to listen to what you have to say, I need to feel I can trust it.
The best way to win trust is to genuinely be interested and concerned about the other person or the audience. You can’t fake this, unless you have shared experiences and shared fears, hopes, or aspirations, then you will struggle to be convincing. Unless you already have this shared experience, then the simple and the only way to achieve it is to clear your mind of all preconceptions and start listening, start asking questions, questioning the answers and listening with every fibre.
The more you listen, the more you will learn. The strange thing about listening is that not only do you learn a lot, but you start to make a lot of friends effortlessly.

What  you are listening for

First what you are not listening for, you are definitely not listening for hooks to  let you push your story down their necks. You should be listening to what they are saying at face value. You should also be listening for the unsaid things, the little gaps in the logic and the things left for you to imply. These latter are the things you need to question to make sure you get the truth. If you are a walkover and you get it wrong, you won’t win much respect.

Tip.
Be truthful. If you don’t agree say so. This way you will still find many that agree and others that make allowance, you might even learn something.  If you are false, you will be caught out and lose all credibility.

You are also listening for communication styles the way they express ideas, the vocabulary they use, any analogies they use when discussing the issues and the general attitudes that prevail in that audience to prepare you for how to word your communications. More about this later.

You are listening for differing groups in your audience, I.E different perspectives or different ways of framing the same thing. E.G. Board directors probably have a very different viewpoint on a shop floor issue than the blue collar workers do. Later you will need this knowledge when we come to segmentation.

You are also listening for their motivations, you want to know what would be the thing that would make them most enthusiastic and what would be least motivating to be able to offer to them.

You are also listening for indicators of who their influencers are, who else do they listen to and trust and why. It may be Unions, it may be certain newspapers or magazines, or a TV show. Knowing this will help you to communicate effectively with them.

Listening is a learned skill and only practice will perfect it, it ,may also be a bit of a change for som people, I promise you that if you will try it out for a week, with no motive other than to see what happens, you will never regret it.
 

Reblog this post [with Zemanta]

Agile Agile the rumblings continue. .

Had another heated discussion with a self professed agile Guru who declined the offer to take the conversation public and place his arguments here, so I will do it on his behalf, but allow him the anonymity he desires. I will refer to him as John for argument’s sake and leave out some of the less important stuff.

The argument went like this:

John:  Your perception of agile is not right, you just don’t see the real benefits of agile because you are not a true agile practitioner, you just use it as a looser form of waterfall when it suits you, but you never really took the faith. We are delivering year in and year out in a way we never could with a traditional approach.

Ed: I’m inclined to take that as a compliment. I hold deep suspicion of anyone who takes a methodology too seriously above and beyond the actual delivery of an end. I have indeed used agile to great effect, but wouldn’t use it except in situations where I believe it is the better approach.

John: That’s just it, you believe you know better, but if you tried it in this other situations you would find , like we do that it delivers more every time.

Ed: I would be interested to see the definition of delivers for the sake of comparison. I won’t discount the possibility that you are right, because like you, I don’t have facts and figures with which to make a real argument, but I do have compelling reasons for my decisions that I am happy to share with you.

John: And they are. .

Ed:

1. Given and ideal world, the shortest and cheapest way to an end result in software is to know exactly what you want to achieve in advance, then know exactly  how is best to deliver it via software, have experienced people to do it, test rigorously against your acceptance criteria and roll out it once working perfectly.   I doubt anyone would argue with that.  I do accept that it probably has never happened and possibly never will, but it is the perfect scenario.
If we both started together and you used agile while I used a waterfall cycle, there’s little doubt that I would finish first and come in cheaper, though given the smoothness of the task, you would also perform well.

I would expect in that scenario, to get the business design right first time and agreed, to get the system design right first time and to have a very low level of defects in testing and instant acceptance by the client. Your trial and error approach would waste precious time and produce unnecessary artifacts.

2. The reason a business and I include in this definition the majority of public bodies, invests in IT is to save money or earn money. A commercial operation needs a return higher than the cost of capital as a fundamental criteria and it must also qualify as best use of limited capital.

The toughest part of a business case is nailing down the cost. If you don’t know the cost with a level of confidence, you can’t estimate the return confidently and you don’t have a case.

The agile argument about  “fit for purpose at  maximum cost” works well provided “fit for purpose can be relied on to deliver the expected returns and assuming that  it can be achieved, but ultimately, unless you can define the requirement well enough in advance to estimate the cost within reasonable boundaries and prove a business case, you are unlikely to ever get off the ground and probably should not.

 

John:

I don’t believe there would be a great deal of difference between the two performances is that case.

Anyhow, that’s all well and good, but there are many other scenarios where the business case is proven by the do nothing scenario alone E.G. defence, environment etc where the costs cannot be calculated accurately, but there is no argument about whether it should be done other than to figure out what will work best.

Ed: I agree with this entirely and in any of these many situations, I too would use an agile approach to remove the likelihood of a colossal error by learning as we go along.

It went on further but the point has already been made

This conversation went on a little longer and covered more ground, but I do feel that a lot was revealed about the importance of using the right approach for the right situation.

I do believe that a good business analyst with strong consulting skills can still earn his keep time and again by getting the requirements defined , understood , tested, verified and agreed at the outset so that accurate costing and planning can occur and the most cost efficient route can be taken.

I often see an agile approach taken as a substitute for consulting skills rather than as a good strategic decision and I do believe that this does nobody any favours least of all the agile approach itself.

About the author

What every business should know about agile

When is a business case not a business case

Agile- is this a short lived fad?

Get a bridger badge and publish your link

Get your Bridger badge and get a link to your web site or profile.

Background to the bridger group.

Recent research has returned a unanimous demand for a bigger effort from IT professionals to communicate with businesses, to serve business need and to become more user friendly.
While there are rights and wrongs and more to this than meets the eye, we can all benefit ourselves direclty and via successful clients and employers by demonstrating our commitment to these ideals.
Only by making our clients successful will we prosper and only by convincing them that we can be trusted to put their interests first will we be chosen to work with them.

The first step in this journey is to demonstrate publicly your commitment to these worthy principals by displaying the badge and promoting the principal of bridging as a way to reassure clients and employers to trust us, hire us and follow our advice.

Why get backilinks?

Marketing professionals spend vast sums annually on text adverts (URL Links back to their web sites). The reason is simply to please Google into placing your web site or profile close tot he top of the list when someone searches for a business analyst, change manager, or project manager and related terms. Google judges you by the company you keep. Expensive text ads are cheating, but free links for friends and colleagues in the business are the fastest way up the ratings, so start getting links now and I will be sending you more introductions as suitable profiles are added to the list.

Why be a bridger?

The one thing an independent consultant or a professional lacks when t comes to convincing a potential client or employer to meet with you is a strong brand. They just don’t know what you stand for and are nervous about taking a risk with you, especially if they can call a well known firm or get a recommendation form a trusted adviser or recruiter.

By publicly demonstrating your commitment to the stated needs of your potential client and being seen in the company of many more like minded professionals, you can go a long way closer to alleviating this weakness.
The more of us that display the bridger badge and talk about our commitment to the principals of briding, the sooner we will have clients entering the word Bridger in Google when they have a new project to begin or need help with an old one.

How do I do it?

There’s only a few steps and I will make it as easy as I can.

1. Choose one of the badge styles from below and then copy the code supplied beneath it.
Pasting this code into your web site or blog will produce the badge you chose with the links back to the bridger.

2. Fill in the form at the bottom and submit it to me for attention. Within a few days I will add your profile to my new associate page with a link back to your web site, blog or profile and I will include any keywords you provide to catch the attention of the search engines.

3. Soon afterwards I will begin to send you more members who would like to exchange links with you.

Note: If you have difficulties with the form below, you can simply give me your LinkedIn profile and I will create a profile out of this.

Option one

Committed to bridging the gap between business and IT Bridger


Option two

Committed bridging the gap between business and IT Bridger

Often operating as Business analysts or Project managers, Bridgers are committed a philosophy that says "1+1>2" and going the extra yard to speak simple English, Spanish, French, German . . more


Option three

Committed to bridging the gap between business and IT

Often operating as Business analysts or Project managers, Bridgers are committed a philosophy that says "1+1>2" and going the extra yard to speak simple English, Spanish, French, German . . more

Seriously though..

Given the uneasy relationships that have been communicated by countless business and IT representatives as we progressed through one of the most secure and bullish periods in modern history and given our current predicament of uncertainty and unease it is not unreasonable to imagine that relationships between the guardians and architects of IT and their business sponsors might reach new levels of difficulty.
Though I am often outspoken in condemnation of foolish attitudes from IT people, I am nevertheless not entirely without sympathy for my roots.
If ever there was a time when businesses need to get the most out of IT and IT people need to prove their commercial worth, then surely that is now.
The following is a funny little story that was popular a decade ago and could well make a comeback in the months ahead.
The IT guy and the balloonist
“A man in a hot air balloon is lost. He sees a man on the ground and reduces height to speak to him.
“Excuse me, can you tell me where I am?”
“You’re in a hot air balloon hovering thirty feet above this field,” comes the reply.
“You must work in Information Technology,” says the balloonist.
“I do,” says the man, “How did you know?”
“Well,” says the balloonist, “Everything you told me is technically correct, but it’s no use to anyone.”
“You must be in business,” says the man.
“I am,” says the balloonist, “How did you know?”
“Well,” says the man, “You don’t know where you are, you don’t know where you’re going, but you expect me to be able to help. You’re in the same position you were before we met, but now it’s my fault.”
We have all been in that field or hovering above it, or even both at different times and I expect we can all sympathise immediately with at least one of these characters. The sobering thought in all of this however, is that the man in the field won’t survive very long unless the balloonist finds his way home and the balloonist stands little chance of surviving without the help of the man in the field.

Moving forward
If there ever was anything to be learned form that story, surely it must be to start appreciating our true predicament as necessary bed mates who can only thrive through mutual success.
IT is guilty of: Being willing to act on precise instructions and refusing to take any responsibility for where the actions might take us. A sort of work to rule.
Business is guilty if: Refusing to consult early and to take firm decisions at the right time. Preferring to drive by the seat of their pants and blame it all on IT if the project doesn’t deliver.

A successful partnership requires an honest exchange of business insight and technology insight to define  feasible, low-risk strategies and well handled implementations that solve problems and create value.

Business leaders need to understand the reticence of IT leaders to take seat of the pants approaches to technology as a pragmatic  endeavour to avoid high rates of failure and to either accept the responsibility, or take the advice.

IT leaders need to realise that the absolute certainty that attracts them to technology in the first place, is a luxury not available to business leaders. The world turns on its axis in a single day and all that was certain is gone. This is the world in which business must must succeed and therefore it is the world for which technology must cater effectively.
Links.
Part one What would you like sir
Joining the dots with a business  case

Testing requirements is not optional

Part one – What would you like sir
Part two – Requirements,tests, training, help files
Part three – Why no project exists onin isolation-whwat should be done
Part four – Business rules, Process rules, Process, Data, different viewpoints
Part five – Testing requirements is not optional
Part six  -Requirements strategy can make or break your project

Yes you read it right. If you are one of those people who believes that testing begins when the supplier drops the system in your lap, then you have missed the point entirely. Testing starts when you build a business case and you test it to make sure that the solution is feasible and the figures are sound etc.
The next important test comes when the requirements are deemed to be complete.
Here’s the summary of a good requirements definition. Depending on the size of the project this could be one document or one per viewpoint. The thing that is important is that the right problems have been addressed and the problems have been identified and described clearly to the suppliers or developers in a way that makes it easy for them to get it right first time.

Business case — Tested via a Business case review, or Stage gate review.
User requirements – Tested via user and stakeholder review. (The problem)
Functional requirements – Describe the functionality that the system will provide in order to meet user requirements. (The solution)
Non Functional requirements – Describe all the constraints like speed of operation, reliability etc.
Data requirements – Describe in detail the inputs and outputs of the system and cover both the validation of human input and the specification of machine interfaces
Business Process – Describe the time phased rules that govern how the business goes about achieving it’s goal with the system. 

Business case review

Has the scope expanded, or the costs changed, or has the timeline been impacted in such a way to negatively impact the business case.
Has the level of complexity shed any doubt on the organisation’s ability to deliver.
Does the bsuiness case still stack up

Business process review

  • Do the processes join up to deliver a result
  • Does each process receive the required inputs
  • Do they handle all exceptions sufficiently
  • Are processes efficient
  • Will new processes deliver the expected benefits
  • Are the risks managed
  • Are the assumptions sound

User requirement review

  • The aim is to discover problems like ambiguous requirements, missing requirements, inconsistent requirements
  • Check against process models to ensure that nothing has been missed.
  • Check against the ten commandments

Functional requirement review

  • Traceability to user requirements
  • Design agnostic
  • Achievable
  • Complete

Non functional requirement review

  • Measurable
  • Explainable
  • Traceable to a business requirement

Data requirements review

  • Complete
  • Clear definition of types, mandatory fields, sizes,

Prioritisation of functional requirements

Armed with best guess estimates of time, cost, risk and benefits propritise them a number scale ar a scale like MoSCoW

Reblog this post [with Zemanta]

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]

Why you still need business analysts and change managers when you do agile.

The first reaction to the theory of agile is to think something like, ”great, now we don’t to pay business analysts and change manager”.

It is logical without a doubt. You are not going to interview stakeholders, try to merge all the information, improve the waste and perfect a new process or design like we did in the good old days are you?No, you are going to very carefully select knowledgeable, committed and influential stakeholders and make them part of the team. Then you are going to facilitate them while tey design the changes.

What a splendid idea that really is. In one fell swoop you have created champions, educated them and built their commitment. You have fed the grapevine, the only truly effective channel of communication, with positive accurate messages delivered with conviction and enthusiasm by respected influential people.
At the same time you have gathered the most important knowledge into one place and not only got their input but had it bounced around amongst them and built up in increments.

How could it possibly be wrong? and how could it fail to win loyal support fast?

Welltheory is a fine and wonderful thing, but experience shows us a couple of important things: >

1. When analysts go about requirement the formal way and they interview everyone who could possibly be important to the project and hold workshops and demonstrations, it often emerges that:

 

a.

yes;”> Stakeholders are often deluded about what really goes on, they think big, but don’t do detail.

Senior stakeholders have imaginations just the same as programmers and when they suddenly get the feeling that they have box of lego and nobody
is watching, they begin to get creative in their thinking.

If this is allowed to happen in an agile project, then it will quickly begin to flounder
. Here’s where an experienced BA can test the theories, verify the processes and police the scope.

2. When change managers tackle a major change there are two forces in particular to be reckoned with:

a. The early adapters and champions that are encouraged and developed and who spread the word and are a generally positive force for change. Amongst these will often be people who resist and challenge things because they are taking ownership and are very serious about the project.

< b.

The blockers who initially grumble and then sit in ambush. Some of them are very powerful generally and amongst them will be people who are always agreeable, appear to be the picture of cooperation and are a joy to evangelise to, because they have not the slightest intention of taking any of it seriously and don’t feel even a little threatened.

These people will wreak havoc left to their own devices and a strong experienced change manager is critical to identify and manage the threat in a safe and appropriate way.

 

So how agile is agile?

Agile is very clever stuff and it can deliver an awful lot very quickly and cheaply when used by an intelligent , experienced team, but is a methodology, not a wonder drug, so use it to the limits, but use it in the appropriate setting and don’t throw away all the safety nets.

Ed Taaffe

Product or Internal System why it is important to make a distinction

When do you need a BA and when do you need a Product manager? why is it critical to get it right?
Whenever I write about anything connected to product development or systems implementation, I am acutely aware of the amount of critically important stuff that I have to gloss over or ignore in order to stay readable and this is no exception.

In broad terms, it is very easy to make a distinction between a product and an internal system. The internal system is being rolled out to the workforce and there is not normally much option about whether it can be adopted and used by the target audience, that is, unless it fails to deliver.
The product, on the other hand has to be launched to a public audience who must be sufficiently convinced that it meets a compelling need or solves a pressing problem, to part with their cash and use the product.

There’s a world of difference between investigating a business problem, creating a business case and designing a solution to this problem and identifying a market sized need, establishing a product problem and designing a compelling solution with confidence that you will have a success on your hands.
The stages we go through are remarkably similar and almost interchangeable, but the big difference is in how we engineer and verify requirements.

Although many products begin as an idea in the mind of a director and are driven forward by this vision, at some point a professional product manager has to establish a strategy for verifying these requirements with the intended purchasers and developing a compelling value proposition that will sell the product.
Faced with defining requirements that will motivate users to pay for your new product, you will need a lot of new consultation and communication techniques that are generally well beyond the scope of a Business Analyst, you will also need deep knowledge of the marketplace to assess not only how well your product may be received, but how the competition will compare and how they will react to your offering.

It is remarkable how often this fundamental truth is ignored by government and public agencies who believe or assume that they have a captive audience for their brainwave, when in fact the public often remain unimpressed and find alternatives or ignore it altogether. A simple product management methodology and the use of more appropriate skill sets could save many of the costly blunders in e-government and deliver dramatically more benefits for most of the remainder.

Ed Taaffe