the Bridger

May 2, 2010

Bridging the gap between the web and the real world part 5

Filed under: Requirements, Sales and Marketing, Strategic thinking, communication skills, management skills, product development, soft skills — Tags: , , , , — admin @ 1:43 pm

What’s the right strategy for me?

Previously:
Bridging between the web and the real world
Bridging the gap between the web and the real world part 2
Bridging the gap between the web and the real world part 3
Bridging the gap between the web and the real world part 4

 

In defining a marketing strategy you will as a minimum need to:

  1. Define your USP and write it down.
  2. Define your target market
  3. Write down the benefits of your product/service to that market
  4. Position your product/service in comparison to it’s rivals so that it appeals to your market (2)
  5. Define the activities you will engage in to deliver your messages and monitor results e.g. networking, direct mail, telesales, events, etc
  6. Develop the messages that suit each method of delivery, drive home your USP, consolidate your positioning statement and motivate the required actions from your target market

Your USP, positioning statements, Elevator pitch and all that good stuff

Me (the business) has to be understood first and that is often where the exercise is rejected then the products come under the microscope.

Most networkers will tell you how important trust is in selling your products and services and this is the section that deals with that trust. Trust is not in a product, or service, but in a person or organisation delivering it and you simply can’t afford to ignore this aspect of your offering.

The simple and obvious questions 

What do I stand for? what do I want out? What am I prepared to give?  Where are my boundaries? Now you need to step it up a notch to look at yourself through your customer’s eyes.
What do they stand for? What does it mean to me? Is it an image that inspires me to deal with them? Are their changes that would improve this image and influence me to buy from them?

Now the money question
How good are my products? Who are they aimed at and why should they buy?
Now from a customer viewpoint

Do I use their products? Why? What would motivate me to start/stop, how do they compare to the opposition? And how does this influence me? Is there anything unique , or memorable about them?

It is rare that this exercise does not lead to a startling difference between the internal view and the customer viewpoint and there is always something to be learned, but be warned, the results must be consumed with a measure of common sense.
The idea of giving the customer what he wants is fallacy. The customer wants you broke and giving him products for free, even products he will never use. You have to talk to realistic customers of the kind you are able to sell to profitably. You have to ask the right questions carefully and explore the answers if in doubt.

Before you can establish a strategy for your marketing you need to be confident that you have  got your proposition right and you are projecting an appropriate image successfully. Without that you can spend a lot of cash and effort for very little return.

Unity of thought and action in all things is the key

Two messages that reinforce a strong influential theme is three times as powerful as one message. Two messages that contradict each other, even a little bit can be very damaging.

Messages in the marketing context mean every communication and action that says something to your customers.  If you deliver a day late without an apology, that sends a message even more effectively than an expensive TV advert only not the one you had intended. The lesson that needs to be learned here is Don’t over guild the lilly.

If you are not going to be able to deliver it consistently, drop it from all offers and don’t promise it. This is the commonest mistake in business and it is even more upsetting when you come to realise that the customer didn’t even rate it in his buying criteria, but now he’s upset because you promised and didn’t deliver.

E-commerce and the retail shop, email and the call-centre, networking and the marketing campaign

Have you ever dealt with an organisation, or a professional who managed to get these aspects of the business integrated even a little bit?  I certainly haven’t.

  • You buy something online, but you are not allowed to return it in the shopping mall.   
  • You see an advert 15 times in the course of an evening telling you how your bank value their customers, you call about your account and ten minutes later, with steam coming from your ears, you finally get through to a call centre person who is trained only in dealing with irate customers. Two minutes later you put the phone down in despair, no wiser.
  • You meet the boss at an event and tell him you need a big order and he is very pleased and very helpful. You call in a few days later to order and you are told, it will be two weeks now before we can deliver, if only you’d called in yesterday.
  • The call centre reminds you that your annual subscription is overdue, because they have never been told that you paid by direct debit last week

We both know that this list could go on for many pages and hopefully you are beginning to think of this in terms of conflicting messages and wasted effort. Fixing this type of thing should be at the top of every marketing strategy.

Don’t take a sledgehammer to crack a nut

The most difficult thing about developing a strategy for marketing can be to avoid starting at the beginning and making too big a job out of it.

If you are happy enough that you don’t have the problems highlighted above then in reading this you have done enough and you can get straight to the point.

 Billions are wasted every year developing strategies that are consigned to the bin by changes in events within the first year, so stick to the highest possible level and don’t get bogged down in detail.
If you want to spend a little more time at this stage then I would strongly advise a couple of workshops facilitated by an experienced external person. In particular PEST is a great way to avoid falling foul of Political, Environmental, Sociological and Technological drivers that render your plans useless.
SWOT is a powerful tool to help you define your Strengths and Weaknesses and to explore. Opportunities and Threats facing your business.   Done well with a good cross section of the team, these can be lively and informative short sessions that afford a chance to take stock and to improve management communication.

Defining your target market

Your target market is a segment or segments of the overall market that you believe is sufficiently large to deliver your targeted sales volume and offers you the best possible opportunity to make sales. Why waste time climbing for the high apples, get the easy ones.

When defining your market segments the best strategy will often be to understand;

 1. The jobs they want done as opposed to features they might want

2. How easily accessed they are
3. How profitable they are to your business.

e.g.  If you are a Lawyer who used to work in the city and now you are in practice, you have a Unique proposition in terms of your financial knowhow, you may be able to highlight a large group of potential clients who engage in financial dealings but are not big enough to retain a lawyer and you may find that there is an easy route to access them all through a particular association.  Provided this is sufficiently profitable for you, you have clearly defined your target market using my criteria.

Defining the benefits to your target market

 

If you remember, we focused on ” job done” as opposed to features when defining the target market, very simply this is because the benefit is that it allows your customer to get a job done.
This way there is less confusion over language and better defined offering in terms of language.

 

e.g. The tiler isn’t looking for a “better cutter”, but a “smoother cut”, or a “faster cut”

Don’t forget emotional drivers

Emotions play a large part in all purchases, even the very logical ones, but many purchases are dominated by emotion.  Cars are bought for the feeling they give the driver when he sits into it.
Homes are bought for what they say about the owner as much as anything else. The list goes on.

People are very swarm conscious and like to be hiding comfortably in a crowd doing what the crowd are doing. The underlying driver is fear of being singled out for r ridicule if they get it wrong, so people need a way out and they need social approval for their decisions.

You must identify these social drivers and write them down

Remember to record the constraints

It may be that only at certain times of year, or when certain conditions occur, will your customers make a buying decision, or that certain seasons are better.  Remember the low hanging fruit theory and record all of these constraints so you can use them to your benefit.

Define your positioning statements

Positioning statements are statements that help the customer understand your proposition by comparing it to the competition and by comparing it to other known things.
“The Venice of the North”.   “Accounting’s answer to Coca Cola”.  These are positioning statements.
They very simply and subtly say a great deal about what you think of your product, they are very easy to remember, because they follow the basic principal of how we remember things and if you can get the customer to accept this comparison, you will very powerfully and memorably define your product’s position in your customer’s mind.
Nothing in my view is more powerful in the marketing strategy than getting the positioning right and then driving it home consistently.

Plan the activity at a high level.

At a strategic level you don’t want times and dates etc, but you do want these key elements:

  1. Clarity about how and where you will deliver your messages for what outcome and how you will measure success.
  2. You should have a regular review strategy to make sure your strategy is working and to make adjustments when appropriate
  3. You should have clear targets in terms of sales, enquiries, list growth, share of voice, share of mind etc
  4. You should have a budget defined
  5. Divide your activities into Hunting and Farming (Hunting being the search for new contacts)

To help you decide on tactics, the best approach is to go back to your notes on target market and n particular the bit about accessibility. At that point you decided that this segment was accessible, how?
Who and what are their strongest influencers?
Where do they go? What do they read? Do they network? Can you get them to join a newsletter? are they in your database and reachable with certain types of media?

 

A simple chart like this one can help

  Offline Networking Online Networking PR Email Events Telesales SEM Website
London engineers £1 to £10m Meet senior  management at key engineering focused gatherings:
Institute of ..		 Directors will stay in touch with opposite numbers and forge new relationships Monthly announcements on the following themes:
1
2		 Quarterly newsletter with valuable key trends analysis Invite up to 50 key people for working lunches Add 200 names to the database of potential customers every month Target buyers of widget who is searching for “custom”
max budget

£n

 Provide all the information buyers need

Track visitors from all electronic messaging.

Integrate this information with offline communications records
Target 10 Potentials 50 new relationships 20% improvement in share of mind. 15 enquiries monthly 40 new potentials 2400 new contacts 10 orders per month Traffic growth 10%
Repeat/New

7:4
London legal  practices £1m+ Meet senior  management at industry gatherings Minimal as they don’t do it much Occasional announcements  timed with ..   Working breakfasts  with short informative  training sessions   Target  all widget searches Use ecommerce to capture small orders.

 

Email key bridging pages to the mailing list monthly
Target 30 potentials              
Total sales forecast                
Cost                
ROI                

 

 

Develop the messages

 

1. Write out your USP

2. Write an elevator pitch that you can give to anyone in any circumstance and they will immediately “get it”.  Imagine being forced to still use it word for word in ten years.

Define the segments by name
Define the jobs they want done
Define the emotional drivers involved
Define their key influencers

Define each of the delivery methods you have proposed for this segment

For each of these individual segment/method instances, write out what action you want them to take and what would make them take it.

For each of the above, write out the message to be delivered
Write out an example of body copy.

The actual body copy can be created close to the event so that the language and mood of the time can be built into it.

e.g.

Segment1 Type Influencers Job done Emotional Action Message
email Peer group afraid of being left behind.
Competition  . sales people telling them we are no good.
Trade body wanting their business instead		 Enter new markets.

Find new products

 Mustn’t be seen to fail even a little.

 

Must feel comfortable with these new ideas.

 

We are afraid of not being up to the job

 www Message1.doc
Networking enquire Message.doc
website enquire Message.doc
telephone Agree to a visit  

Message 2.doc
events Invite us to tender Message 3.doc

 
Direct mail Make an enquiry Message4.doc
Newsletter Visit the www

 

I expect it is much more evident what your message should be saying when you work form this chart and a good copywriter should be able to produce powerful collateral very quickly.
 What is especially good is that all your activity is now delivering consistent focused messages direct to receptive audiences and they can continue the conversation across the website, networking, events etc without any confusion. If you work a little on timing and language you can achieve a great deal from your new marketing strategy.

If you invest in some tools to help you coordinate all these communications it will make your job a great deal easier

June 13, 2009

Agile Agile the rumblings continue. .

Filed under: Requirements, product development, project management — Tags: , — admin @ 9:12 am

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 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 what 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?

June 10, 2009

The true DNA of an agile project (exploding the myths)

Filed under: Requirements, Systems, product development, project management — Tags: , , — admin @ 8:38 pm

Ignore the new vocabulary and you’ll find nothing new in the concepts.

If you have heard me pour scorn over some of the claims made for agile, you may be surprised to know that I’m an agile practitioner with some considerable experience and not at all adverse to the approach.  That said, I always repeat the words of my agile mentor Keith Richards (no not him silly) when I asked the obvious silly question. He said ” It’s horses for courses.  When you turn up for training we assume a certain level of education, intelligence and experience”.

OK so what is the big noise about. Well the underlying promise of agile emerged back in the seventies soon after the first Standish report when some of the industry leaders cooked up an alternative to the waterfall way of wasting money.
The theory and indeed the practice is totally valid when followed with a level of honesty.  You tell me how much you can spend, or how long you have and I’ll guarantee you a working system.
Note the difference from waterfall where you have two options: fix both budget and time and have a failure nine times out of ten, or fix  just one and reduce the odds by 2/3.(MSF).

Agile delivers on the promise when billed honestly and executed  honestly.
Here’s the metaphor.  Say you meet with your co-directors and agree that right now the thing that will  accelerate you to your goals is an very large extra table  in the boardroom with a tiny door and spiral staircase and you have only £n  to spend, or n months to deliver it. I will discuss your needs at length, then I will come back with a proposal that looks like this.

The minimum required to make this work is a top and thee legs. You don’t need four to make a table work, though I agree it would be nice.  It can’t be bought and even the top has to be constructed on site.
The legs are standard things and fundamental so I will order three of these and have them delivered.
We will start making prototypes using scrap wood  for legs and sticking planks together until we have a table that is just stable enough and functional enough to meet your needs.

This we are confident we can achieve within your constraints, if we have extra time or budget, which I expect we will have, we can add a fourth leg, or smooth it over, or add a coat of varnish. You can decide when the time comes, which is more important. That’s it. No miracles, no free lunches, just less pontification, more action and a product that is fit for purpose, if not always entirely pretty.

 When you wouldn’t use agile.

You would never use it to build a space shuttle. That type of project requires a right first time approach.  I shouldn’t joke about a tragedy like that. There can never be a serious consequence of getting it wrong first time. You shouldn’t use it unless you are bought in fully to the three legged table, if your mind is set on four, stick to what you know. If you are buying in the team either as contractors or a service company, it is risky, because highly competent  people is a prerequisite.
If your main motivation is to be involved on a day to day basis as opposed to making a decision up front. It is poison, keep away.

April 10, 2009

Requirements gathering the first big mistake.

Filed under: Requirements — Tags: , — admin @ 2:29 pm

Previous installments:
IT investment for the smaller business
Why the Smaller business holds all the cards
Where has alll the money gone
 Many seasoned project managers will start off a project by sending out his business analysis team to carry out requirement gathering.
Sometimes this is the right thing to do, in particular you should do this when you have a successful proven process that you want to automate using IT.  Requirement gathering then educates the IT people responsible for system design (the features) on what they need to achieve.
This is a different scenario, just think about it for a minute.  If we had the business case open and we had a succinct explanation of our goals and how success will be measured, would it not say things “like failing processes”, “lack of experience and knowhow” and would there not be talk of providing a new and better way and retraining people?

Here’s what actually happened.    
A Business analyst was hired to gather requirements and she went about learning how the business works and mapping all the tasks that people do every day. She was very thorough and presented it all back in neat UML diagrams with notes and she created a data catalogue to back this up.  An up and coming manager from the business then was appointed to find a supplier and deliver a system. He was instructed to report with final costs from shortlisted suppliers.

Off he went and began to invite various CRM vendors over to give presentations and answer questions.   They were given copies of the Business analysis in advance which some read and few paid much attention to.  Fairly quickly it became evident that this was a bit technical and he would have to rely on the vendors to keep him out of trouble and he quickly got it down to two people that he felt he could work with and asked them for quotes.  He had by now built relationships with these guys and they were advising him. The IT manager was also sitting on occasional meetings to make sure things were to his satisfaction.

He ruled out several vendors early on because their technology was not compatible.  He was a bit miffed that he was not in charge of this instead of someone who knew nothing about technology. It never crossed his mind that he knew nothing about business. He insisted on writing a features grid based on the business analysis and asking the suppliers to state whether they met all the requirements.

Eventually they chose a vendor that the project manager felt comfortable working with and that answered all the questions for the IT manager.

Perhaps this is a good place to finish this instalment and focus the attention on where we have got to from where we started.
We began with well defined business problems that required to be addressed urgently and which included lack of experience and know-how in the sales and marketing teams.  We ended up with a supplier chosen on the basis of the IT manager’s priorities and the Project managers relationship with the sales rep.
Par for the course.
At this point the budget has a debit side exceeding £30k and that takes no account of internal staff spending considerable time away from the day job.

Next week we will look at the contracts negotiation stage
  About the author

January 31, 2009

Getting the mountain to Mohammed

Filed under: Requirements, product development, project management — Tags: , , , , , , — admin @ 2:43 pm

The business dilemma

Few IT professionals have any grasp of the difficulty facing a business person who needs to stay abreast of tough competitors and try to win competitive advantage via IT without understanding how IT works sufficiently to make the right decisions. It’s a crapshoot where he/she can’t afford to lose. 
Having learned the art of decision making the hard way and knowing the difficulty of staying ahead strategically in his business, it’s not surprising that he doesn’t want to hand these decisions over to someone who is seen to be obsessed with technological coolness,  incapable of making a decision without a debugger and bereft of business savvy .
Typically, the sales director at “abc software” wins more credibility and trust with the customer than his own IT experts because he at least demonstrates some business savvy and empathy. The corporate hospitality doesn’t hurt either.

The IT dilemma

Few people in business have any appreciation of exactly how complex and demanding a job it is to ask them what they want, give it to them and get a “thank you, that was great.”

Most professionals would argue that the patient should not be defining the solution, but describing the problem and I would go along with this, but we don’t generally have the luxury of making that decision.
Business managers on the whole are adverse to personal risk and their number one priority is someone to blame if it goes wrong. This can usually be traced to their boss, but that’s no consolation to the IT supplier.

Business people try to equate complex business systems to a car or machine that can be delivered and plugged in and they expect t to buy a tool without knowing what it does and all will be well.
Systems are endless boundless things with unlimited possibilities and similar complexities to the humans who design and use them. Ultimately they are little reflections of humans.
The majority of IT delivery people, be they IT directors, department heads or representatives of suppliers have adapted the approach of defining a product they are going to deliver in technical terms that are hard to refute, insisting on a signature before proceeding and in the case of suppliers, getting their pay loaded up front.  Then they deliver it and walk away guaranteed a cheque and a profit.
 If it doesn’t quite deliver then there’s a new document, a new purchase order and the exercise is repeated until success is finally achieved.
Public sector suppliers and increasingly in private quarters too are notorious for the re-negotiation strategy.
This is simply taking the aforementioned  failure a little further to the point of using  it as a strategy to win the business with a cheap bid and then re-negotiate midstream once the client is heavily committed and in no position to negotiate from strength.
In reality, it could be argued that Agile is nothing more than a recognition of this state of affairs and an attempt to bring some element  of structure and communication to the procedure as opposed to letting it run freely into a sort of adversarial mating dance. The problem is that agile applies only to development of software and is useless to the process of buying commercial systems off the shelf (COTS).

Challenges for the business

What is the problem I want solved and is there a reliable solution to it? What are the risks and can I accept them?
Will the solution give me competitive advantage, keep me up, or keep me up with the chasing pack, what choices do I have?
Who’s going to carry the can if it all goes wrong?
Is there really a do nothing option?
Who can I trust with these decisions?
How can I get the business knowledge and the IT knowledge to somehow meet in the middle and give me some realistic answers?

Challenges for the IT supplier

How can I keep the bills paid?
How can I prevent businesses dumping their risk onto my shoulders, I am just the technology vendor, I don’t run their business?
How can I compete with the rest of my industry?
How can I say Caveat emptor without having customers run a mile?
How can I win competitive tenders for projects that almost never complete anywhere close to agreed budgets?
How can I give best advice and still stay in business?

Challenges for the Project Manager or Business Analyst dropped in the middle of all this.

How can I keep the bills paid?
Does the client actually know what they want and what am I tasked with delivering, E.G. Technology, or success?  If it is success, what will that look like? Who will measure it? Am in control of that, or shouldering someone else’s risk?
Will they trust me with their project, or will they cosy up to the supplier over corporate entertainment events and discard my advice?
Will senior sponsors take the time to understand the problem, explore the proposed solutions, make decisions and stand by them?
Will they still remember what they asked for when the final product arrives and if they’ve changed their minds, will it be clear whether they asked for the wrong thing and got it? asked for the right thing and didn’t get it? Asked for the right thing, got it, but it didn’t solve the problem?
Will challenging the client be seen as professionalism or showing them up?

To stay in touch with this series, be sure to subscribe to our feed or register

IT guy and the balloonist

Five stages of an IT project

About the author

If you are in the business of brisging between business and IT delivery, maybe you’d like to join our bridger group and display the bridger badge.

December 30, 2008

Seriously though..

Filed under: Requirements, Systems, project management — Tags: , , , — admin @ 2:02 pm

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

November 14, 2008

About the author

Filed under: Internet, Knowledge management, Organisational change, Requirements, Systems, Uncategorized, product development, project management — Tags: , , , , , , , , , , , , , , , , , , , , — admin @ 3:00 pm

Edward Taaffe has a 10 year record of achievement in project management in both the private and public sectors ranging from negotiating with local authorities to use centralised shared services to introducing ground breaking technology to government and convincing them of the benefits of early adoption.

Often referred to as a BridgerTM Ed’s career has followed a path that combines almost ten year as a marketer and sales manager, where he acquired and polished his communication skills to a second career as a Software engineer and innovator. Edward uses many modern communication tools such as Prince 2 and Agile to support and frame communications in his projects, but he has always maintained  that without the skills he brought with him to the table form his previous experiences he would have been poorly equipped for some of the challenges he faces on a day to day basis.
Today, Edward provides Project management and Product development expertise as an Interim, or short term consultant as well as providing training sessions, reviews and coaching for project teams and Product management teams worldwide.
Edward recently took up blogging as away to reach out to fellow professionals and form strong relationships for knowledge and idea sharing. You can contact Edward directly via the details below or connect via Linkedin.  Ed[at]thebridger.co.uk

October 14, 2008

Requirements engineering strategy can make or break your project .

Filed under: Organisational change, Requirements, Systems, product development, project management — Tags: , , , , , , , , , , — admin @ 8:21 pm

Part one What would you like sir

Part two Requirements, tests, training, help files

Part three Why no project exists in isolation-what 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

If you’ve been reading my blogs on the subject of requirements, you will no doubt appreciate the level of importance I place on getting requirements right and then testing them before committing yourself to a contract or a technical specification.
Just in case you are thinking that this is in some way anti agile, then nothing could be further from the truth. Please read my blog on agile requirements engineering for a discussion on this topic.

Let’s take this opportunity to recap on why we do requirements. The simple fact is that once a development team start work on creating a technical specification, the till begins to ring up with costs and every time you make a change after this point more costs are added. The closer you are to rollout when you make the change, the greater the extra the cost will be and that time phased increase is exponential, therefore the first purpose of requirements engineering is to contain costs and eliminate or reduce slippages.

The second purpose is to make sure that the end product delivers value by meeting the needs of the business precisely in order to meet or exceed the benefits targets set in the business case.

Getting requirements right therefore, is absolutely critical if you are to contain costs and deliver value

Developing a requirements engineering strategy

Each organisation and each project are different and requires a tailor made strategy for getting the requirements right by recognising, exploiting and working with the capabilities of the organisation.

To do this successfully, you will need a few things:

1. A detailed analysis of the stakeholders involved in the as-is process in order to make interviewing efficient and thorough.

2. A strong feel for the past experiences of the organisation in terms of successes or failures with software projects in terms of meeting business need and staying within budget and time constraints. This long with some tactful exploration of causes will give a strong steer about the current capabilities of the organisation to engage with a formal requirements process and to take seriously concepts like change control.

3. A feel for the organisations ability to take on and successfully adapt change will help you decide whether and how far you might decide to upgrade their skills and attitudes to requirement engineering

4. A good indicative plan that indicates the products to be created, their acceptance criteria, time scales for delivery and the amount of effort that will be needed form stakeholders.

5. The understanding, agreement and total buy-in of key stakeholders to the proposed approach with full support in terms of making people and facilities available for the process

Stakeholder analysis for requirement engineering

Step one

Using RACI to identify stakeholders for the Requirements function.

In my blogs on business case techniques and models I discussed the importance involving the right stakeholders to gain buy-in and get a real picture of what success will look like.
In order to design the system, you will need a different type of stakeholder list, one that describes roles, responsibilities skills and communication. This list will give a clear view of where the knowledge skills and the responsibilities lie within the organisation and therefore point you at the right people to describe requirements and take responsibility for their quality. My favourite tool for achieving this is a well known HR instrument known as the RACI chart. Responsibilities Accountabilities, Consults, Informs and it provides a two dimensional view of a team that helps you quickly analyse the team for adequate skills, supervision, communication and quality control. It can be adjusted in form or emphasis to suit your precise needs, but the fundamental principal serves well in any circumstance straight out of the box.
Here’s an example;

RAACI example

The table above lists nominal roles across the top and Activities down the left, each cell is then marked with one or more of RACI to show who has what role in that activity.
The example is for a software development team, but if you were building a hospital it would list things like planner, builder, architect and activities like approve plans, complete design, etc.

A software project for a builders might involve, Construction director, surveyor, cost controller, quality controller etc and Liaise with clients, agree costs, sign off completion, etc.
Apart from being a huge benefit in helping to highlight the important stakeholders for your requirements process, the RACI chart also provides a quick but effective sanity check to make sure that your team is adequate and that there no duplications, conflicts or gaps.

Horizontal analysis of each task will quickly tell you whether there are sufficient doers and accountability exists and is in the right place.
Vertical analysis of roles will quickly highlight overworked, underworked, misplaced authority or responsibility and lack of or too much consultation and information.
Too much consultation stifles decision making and too little leads to dangerous decisions. Corporate culture can lead to busy bodies who don’t always follow through, or teflon in-trays. All of these issues need to be understood and ideally addressed ahead of system design, because the system will only perform as well as the people who use it.

Once you have created this chart, the next thing is to create a list of names with contact information to place in each of the role areas. If the project is large and/or complex, there may be more than one name in each box and there may be further sifting to do in order to resolve any doubts.
Don’t be surprised to find skeletons in the cupboard and lack of agreement over who does what. If you uncover these issues, now is the time to discuss them at a high level and attempt to get them resolved ahead of requirement gathering.

Step Two
The second step is identify the Actors, the people and systems that carry out tasks as part of this process and the sources of all the skills, knowledge and decisions required to complete the process successfully. This will generally begin with the R people in your RACI chart and will usually expand to people who do the work with or for the R person. E.G. the R may be in your chart as the Technical architects for design, but on investigation, you may find a DBA, a SysAdmin and many others who play key roles and these people also need to be interviewed.
The actual actors may be more usefully broken down to specific skill sets or disciplines as opposed to specific roles. E.G you may have Document writer, Interviewer, modeller all of which are actors within the BA function. This approach gives a slightly more abstract approach that lends itself to reorganising roles for efficiencies, or to adapt to a new system.Never be tempted to accept the assurance that a supervisor can tell you the whole story and you don’t need to talk to her/his charges. If anything this should be seen with an element of suspicion and tactful verification is a good idea.

To better understand and communicate how the various roles influence the outcome of a process, it is sometimes useful to create a fishbone chart adapted slightly for the purpose. Here is how i like to create it:

Stakeholder fishbone chart

The fishbone can be made as complex as you need it to be in order to show all the influences on your new project. The thing that becomes apparent very quickly is that whether they are aware of it or not, most of your stakeholders rely on others for skills, support, knowhow, data, administration and other inputs that can potentially prevent the processes progressing and hence you need to know about it and to resolve, or risk manage it.
Your fishbone chart will immediately tell you who to talk to and by way of a bonus, it will very quickly highlight the areas of influence, both positive and negative when it comes to rolling out.

Organisational culture and requirements process maturity.

Once your target interviewees are lined up, your next step is to hold a number of short interviews and/or an interactive workshop to discuss past projects, how they went and how the organisation reacted at the time and now. Asking them what they felt went well and what went wrong will go a long way towards gauging what will go down well, or will meet with resistance in terms of methodology.
The aim is not to deliver the perfect project, by your standards, but to deliver the best you can within the capabilities and expectation of the clients.

The last critical aspect of this phase is to get a good feel for their favoured mode of communication within this area. Do they have requirements documentation that they worked with in the past? Are they comfortable working with it? Does technical documentation create silos that exclude valuable stakeholders to the benefit of technical people .

This aspect is vital, because the quality of decisions they make and their perception of you as a trusted adviser will be directly proportionate to your skill in communicating the concepts clearly to them. Not only that, but your ability to get their attention at all let alone hold it long enough to achieve a useful level of consultation will depend on not confusing or alienating them with technical or complex instruments of communication or use of unfamiliar jargon.

A clearly communicated strategy and indicative plan

Once you have gathered your information it is time to make some preliminary decisions about how to take it forward. How to collect information, how to verify your information and how to communicate back to stakeholders ahead of defining the requirements.

Identifying these tasks, the stakeholder and support staff needed and the order and dependencies of the work, it is time to add this to a simple Gantt chart that defines high level activities, high level milestones and products to be delivered.

Understanding, agreement and total buy-in.

If you have done your homework and worked in a consultative manner you will be very confident before presenting the plan, that it will be understood and supported and will be accepted by your stakeholders.
You should present:

1. An introductory explanation of the approach with reasoning

2. A list of products you propose to produce backed by a simple concise explanation of how and why and samples.

3. A Gantt describing the timeframes and milestones.

4. A simple, high level risk assessment

5. An indication of the time commitments required of key stakeholders.

At the end of this you should answer questions and ask for their full support backed by a sign-off of the plan.

Ed Taaffe is a senior Consultant in Business Improvement through technology and Hi-tech Product management.

Reblog this post [with Zemanta]

October 9, 2008

Testing requirements is not optional

Filed under: Organisational change, Requirements, Systems, product development, project management — Tags: , , , , , , , , , , , , — admin @ 7:24 pm

 Part one What would you like sir

Part two Requirements, tests, training, help files

Part three Why no project exists in isolation-what 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]

September 28, 2008

Business rules, Process rules, Process, Data, different viewpoints on requirements.

Filed under: Requirements, product development, project management — Tags: , , , , , , , , — admin @ 12:08 pm

Part two Requirements, tests, training, help files

Part three Why no project exists in isolation-what 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

Requirements look harmless enough once they have been defined and it can be difficult to imagine the amount of work that may have gone into defining them. Sometimes the issues are simple and requirements are easy to define. More often the business can be very complex and the requirements can be very tricky to define. Often the consequences of getting it wrong are very serious and other times they are easily surmountable

To fully understand requirements it is necessary to break them down and consider each on it’s own merit. First of all requirements come from different viewpoints and these angles must be fully considered.
The key viewpoints to consider are: Business rules, Processes, Process rules, Data rules and models, Operating environment internal and external, Culture, Skills, Adaptability.

Business rules

The key to understanding the nature of Business rules is to understand that whatever the business, there are certain rules the business must follow in order to win business, meet legislation, deliver value , get paid and make a profit. These are generally described as Business rules.

Often these business rules will be referred to at a high level as the business model, though business rules for our purposes will generally exist at a level one step deeper into the detail.
A business rule in a broker model might be that the business only submits to a client, candidate products that match the client’s stated requirements 100%. This might then lead to many more rules that help to better define the high level rule. These rules will most likely be implicit in documents and procedures as opposed to carefully recorded under the heading business rules.

A simple business rule might be that the business charges vat at 17.5% on all sales. Another example might be that the business never offers credit to first time customers, or that it must inspect all of it’s properties at least once a year and provide safety certificates.
A more complex rule might be that all it’s businesses must be visited by a mystery shopper on a Saturday between 12 and 3.pm at least three times a year but no closer than two months apart.

These business rules are not always cast in stone, but they tend to form part of the culture in the business and they often contribute to understanding the capabilities or lack thereof in the organisation. They also reflect the strategies and direction set by the business. Some would say that these business rules are fundamental to what differentiates and defines the business. One way or another they are critical to requirements engineering.

It is also very important to the analyst hoping to deliver well received improvements in how the business runs to understand the consequences of attempting to make changes to these rules. Challenging and changing these rules requires high level sponsorship, deep understanding, tact and respect for the organisation, its people and its essence.

Process rules

Process rules are a different entity altogether, but play an equally important role in how a business gets from point A to point B. Process rules are more flexible , less strategic and more tuned into the abilities and preferences of individuals within the organisations. Process rules say as much, or even more about the past where they were born as they do about the future they are intended to support.

A process rule might say that an individual product has to be signed off by the Quality manager before leaving the premises, or that a specific type of purchase is checked individually before being added to inventory.

Complex process rules might suggest that a detailed survey must be produced before a plan of action is presented and only after sign – off by three senior managers can a project begin.

The difference between Business rules and process rules is that Business rules set a strategy for the business, while process rules are one way of delivering on that strategy, but not necessarily the only or the best way.
The power of good process is that while people quickly forget why they do it, they do it without thinking and the process hopefully results in good consistent performance. The downside is that for the same reasons stated above, people continue to follow process blindly long after it has ceased to offer value. This is especially true when that process is enshrined in a system that is inflexible. This fact also makes a very strong case for taking extra care with the design and validation of process, not just in terms of performing well right now, but providing both resilience and adaptability.
The way in which any idea including a process is made reusable is through abstraction and this is a key element in the process modelling element of requirement engineering.
Use cases are the commonest way of abstracting requirements because they are reusable descriptions of things that must be done in a way that is technology and even functionality agnostic.

Requirements

As described in detail in When is a business case not a business case, the Business requirements are the starting point for a project and provide the motivation for proceeding to the next step. They describe clearly what the business objectives are and they make a first attempt at defining the KPIs that will indicate success. They also describe other constraints such as time to market, ROI, etc that may be very important to the project.

User requirements /Use cases

Business requirements are all well and good, but the next level of understanding involves describing in detail the cases in which people will use a product or system, the goals they will be seeking to fulfil and the constraints on each of these user requirements or use cases. Typically a constraint might involve the time it takes to achieve something, or the level of accuracy.

E.G. A business requirement may be that all paper work is eliminated in the “enquiry to payment“ workflow.

This requirement can easily be measured via a number of valuable KPIs and now a whole list of use cases will emerge such as:

1. A user must be able to record the details of a new order.

a. A user must be able to check that the stock exists

i. If it is not in stock, user must be able to order it

1. A user must be able to get an ETA on delivery.

2. A user must be able to retrieve an instant progress report.

3. Etc.

You will notice that there is no attempt to describe functionality, just to describe the activities users need to carry out and the goals they need to reach.
The second thing worth noting is that we are not burning daylight hours worrying about the order in which these things happen or who does them and all the other aspects that would complicate a traditional process map.
The difference between use cases and process maps is that use cases are written as building blocks that can be used in any order to build a new efficient process as opposed to an existing process that has to be wrenched from it’s owners and painfully changed amidst powerful opposition. The answer you receive in any area of life will depend heavily on the way he way the question is asked and the context in which it is asked. This is key to the success of the business process designer and the and the use case approach lends itself to more objective questions and more accurate answers.

In addition to this, it is often folly to assume that everything is a process. In reality there is not necessarily any time or order dimension in the way many of these events occur and it is more valuable to look upon the business as a series of events to which users must react with use cases.

In my view a process describes a situation where each activity causes the next decision or step to happen immediately. Process is required to understand the functions that will support many of these use cases, but necessarily to join together, or to explain them.

As-is/To-be

An old and respected technique for achieving this understanding of process is to model the “as-is” processes and then to design improvements based on any combination of the capabilities of the new technologies and changes to the business as a whole.

As previously discussed, Use cases pay no attention to the order in which things happen or the decisions about what comes next. This is the main attraction of use cases as a clean sheet on which to design better processes as opposed to mapping “as-is”, (about to be dumped) processes in great detail before then re-designing them in the face of resistance and contention.

The problem is that an analyst must start somewhere and the approach needs to bring along business stakeholders who may have their own ideas and preconceptions.

Our preference is to define this requirements engineering approach in advance bearing in mind whether the task is closest to a new blue sky system, some process improvements, or solving a business problem.
In the latter case, the AS-is and To-Be approach is likely to be most acceptable while a blue sky project will be more successful starting from use cases and using them to design new processes.

The key ingredient in designing or even just recording process is the complete co-operation and enthusiasm of the stakeholders involved, therefore intelligent and tactful consulting combined with open and understandable methodology that stakeholders can feel part of and buy into is an absolute prerequisite.

There no right and wrong processes, there are processes that are used well and those that are rejected

Consultants dilemna

Consulting is not a job for egotists or perfectionist. Every analyst will have seen the same problem tackled in extremely different ways at different organisations and been dismayed at having to ignore hard won experience in favour of what the current client feels comfortable with. This is a fact of life and one of the biggest stumbling blocks for consultants in every walk of life.
In most cases, as-is modelling will be seen fairly quickly to contribute mainly to actually understanding and recording use cases and the time element will be seen as less important. The critical thing is to find a way of recording this information in a format that promotes discussions and input from stakeholders.

This brings us to the last aspect of user requirements. Acceptance criteria.

Acceptance criteria.

As in all things, you need to start out by defining some sort of success criteria.

No goal posts, no goals.

It’s not rocket science, but success criteria is far too often neglected.

Process that has not been verified is a dangerous base on which to design a solution and likewise the suitability of the process to the people who will need to execute it will need a level of verification.

The only way to achieve this is to agree in advance how this verification will be carried out and how the decision will be made.

Functional requirements

Functional requirements are the next level of abstraction, not the solution. Many people are under the illusion that this is a software specification, but nothing could be less accurate. The Functional specification is a bridge between the totally abstract user requirements and the very detailed technical specifications..

This is the critical time when the technical experts get involved to explain to you the possibilities you had not considered and show how your requirements can be met using existing infrastructure.

To demonstrate this, let’s return to the example we used in previous articles.

The business wants to win more new customers through leveraging the internet to keep in touch with people who are in the market for their products.

Having resisted the “Ok let’s build a website” response, we define some user requirements.

Customer users need to be able to:

1. Study the benefits of our product at their leisure without feeling that they will be pestered

2. Compare our offering to the other major options in the market place

3. Do a price comparison

4. Ask questions about the product

Marketing users need to be able to:
5. Make new collateral available to customers within an hour of proof reading it

6. Know which collateral is most helpful to the customer

7. Know the customer’s stage in the buying process when she finally say’s hello and reveals herself.

Turning user requirements into functional requirementsRequirement 1 is up for discussion and the options are laid out, we can have PDFs and faxes cued up ready to auto respond to an anonymous request by the customer.
We can build a website with this information.
We can find a way to attract them to a tool they need when making this decision, give it to them free and make sure it keeps our information in front of them.
Etc, Etc

The recommendations will be influenced by the infrastructure already in place and what the stakeholders and the market are most likely to feel comfortable with.

At the end of this exercise we will have a list of functional requirements that sounds like:

1. The system will provide a way to publish collateral via webpage, MMS, PDF and mail shot in any combination by a creating a single document.
A good functional requirement will also list the user requirements it meets or contributes to and will include constraints.

What you have hopefully noticed is that this functionality, although crystal clear, makes no mention yet of the actual technology that will be used. That will be left to technical architects.

Data requirementsAnother common aspect of the functional specification is data requirements. These provide yet another abstract view of the business that presents vital detail to the systems architect without placing too many constraints on him/her.

Data requirements will be driven by required outcomes including legislative requirements such as accounting data to KPIs and operational reporting. Data requirements will often reach far beyond the organisation to embrace sharing and integration with partners, supply chains, customers and others as well as obeying conventions and standards that facilitate benchmarking, look-ups and other collaborative uses of data.
Last but by no means least, Data requirements will define the interfaces with existing applications that make the integration work smoothly.
A set of data requirements may include things like:

Data catalogue that gives clear unambiguous naming conventions and rules for how to collect, validate and store data as well as the daa that is required in every process,.
Data Flow Diagram (DFD) that describes how data flows in the system or business.
Entity diagrams that describe the key entities and their relationships.
Yourdon diagrams that show inputs, processes and outputs.Each method has it’s own merits and it’s own uses.
Sophisticated process design methods like six sigma measure the inputs and outputs of small processes to gauge the health of the overall system. Systems integration demands vey detailed and accurate data catalogues in order to get systems working together.

Usability

Only by carrying out usability tests early on can you avoid the expensive mistakes that alienate users and waste lots of time and hence money for the organisation.
My earliest introduction to the potential pilaffs occurred when I rolled out a cutting edge online CRM system that I had designed and built from scratch for a major utility company. It was first and best of breed, we had put a lot of effort into pulling information out of systems of every conceivable type to create a single view and we had done a pretty good job. We had also presented prototypes to the user base, but we had not paid enough attention or asked the right questions.

On roll-out day, none of the risks came to fruition and everything flowed smoothly, but the union representative on the call centre floor called the rollout to a halt pending her problem being resolved.

The problem was this, all users at developed a way of using speed keys to enter data very quickly while handling inbound calls. This meant that they were able to met targets and earn bonuses worth up to 20% extra on their base pay. With the new browser based system, the speed keys were not available and the bonuses were gone. Staff were threatening to leave and a strike was just 24 hours away.

Eventually we negotiated around this, but it took the gloss off an otherwise successful launch and it taught e a lesson that I’m not going to forget in a hurry. You must carry out well orchestrated usability tests on good prototypes in near perfect replications of the end user environment and go the extra yard to find out the problems from the viewpoint of real users.
Once these constraints have been encompassed into requirements and verified in UAT, you will be in a much more solid position to roll out a winning system.

Ed Taaffe is a Senior Consultant in the areas of Improving business through use of technology and hi-tech Product Management

Reblog this post [with Zemanta]
Older Posts »

Powered by WordPress