the Bridger

November 6, 2009

Communication for project managers

Filed under: Organisational change, communication skills, management skills, project management, soft skills — Tags: , , , , , , , , , , , , , — admin @ 3:11 pm
Communication code scheme

Image via Wikipedia

Introduction to the series.

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.

 If you are not registered, Regisrer Now to download a free paper [download#1]
 

 

Reblog this post [with Zemanta]

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?

January 26, 2009

Get a bridger badge and publish your link

Filed under: Uncategorized — Tags: , , , — admin @ 8:25 pm

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

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

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]

July 12, 2008

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

Filed under: business case — Tags: , , , , , , , , — admin @ 6:22 pm

 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]

June 1, 2008

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

Filed under: Systems, Uncategorized, product development — Tags: , , — admin @ 6:56 pm

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

April 21, 2008

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

Filed under: Systems, product development — Tags: , , , , , — admin @ 5:49 pm

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

Powered by WordPress