Quotation incrustation (and a little inoculation)

Francis Bacon said, 'There arises from a bad and unapt formation of words a wonderful obstruction of the mind'. And where better for a wonderful obstruction of the mind than the program kick-off meeting? A slide-deck which has been over worked, with pictures of sinking boats (that will never happen here of course), some incidental shots of a medal winning track team and maybe even the odd roaring lion. And of course the quotes. Where would the slide-ware of any self-respecting change practitioner be without some well chosen quotes from a few notable luminaries?

You know the sort of thing... "I don't measure a man's success by how high he climbs but how high he bounces when he hits bottom" or "Success is not final, failure is not fatal: it is the courage to continue that counts".

But quotes are funny things. And, it was only when recently reading Daniel Kahneman's "Thinking, Fast and Slow" (which I can't recommend highly enough incidentally) that I realized just how potentially beguiling a quote can be.

Now even I am not going to try and distil Professor Kahneman's comprehensive insights within a paragraph or two of my blog but among the great swathes of wisdom provided, Professor Kahneman discusses something called the 'confirmation bias'. The tendency to search for, interpret, focus on and remember information in a way that confirms one's preconceptions.

So with that in mind and to underscore by point a little, I ask that you cast your eyes over the following, almost universally flawed, quote-ware; 

“Marriage is a bribe to make a housekeeper think she’s a householder” (Extraordinarily naughty)

“Better to be on the ground wishing you were in the air than in the air wishing you were on the ground” (Unhelpfully playing on latent fears about more or less anything)

“Hat’s divide generally into three classes: offensive hats, defensive hats, and shrapnel” (Smirk-worthy undoubtedly, but entirely content free)

“The only fetters binding the working class today are mock-Rolex watches” (Mildly offensive and with some obvious pandering to smouldering prejudices)

“It is queer how it is always one’s virtues and not one’s vices that precipitate one into disaster.” (Stealthily seductive and quite possibly dangerous!)

“The truth is that our race survived ignorance it is our scientific genius that will do us in” (Truth? Prove it!)

“Dreams come true; without that possibility, nature would not incite us to have them” (A bit of grandiose whimsy)

"A policitian’s words reveal less about what he thinks about his subject than what he thinks about his audience". (Rather insightful actually).

You might find that (in view of Professor Kahneman's run-away success) that your audience isn't quite as susceptible to an approach of "...here's a quote to back up what I'm telling you so it must be true...". You might also be less easily beguiled by a well chosen (if specious) quote should you be on the receiving end of it.

But, most importantly, you won't need roaring lions and Benjamin Franklin in your communications if you simply answer the questions; what's the point and why does it matter?

Equine allegories

First, please excuse the title  - a cunning attempt at promoting my blog. Anyone (and I mean anyone) who Googles "Equine allegories" is sure to be directed straight here. A winning strategy I think you'll agree.

Now, for those of you not in 'my manor' as it were, there's been a bit of a scandal of late with beef not being beef. Suffice it to say, jokes about Red Rum Steak abound. 

I think this has got some fascinating insights for anyone in the business of change.

Let's talk about quality assurance and product acceptance first. Projects are comfortable in a landscape of customer / supplier. Other approaches exist. I've always adopted a stance that the supplier is accountable for quality assurance. Equally, the customer never divests themselves of the onus for due diligence corresponding to product acceptance. It is too risky to rely wholly upon the supplier's quality assurance.

Now, risk. I've never been comfortable about the whole 'transferral' of risk thing. Mainly, because I don't think you can transfer risk predictably and reliably. I'm minded of a supplier who was responsible for building the new Wembley Stadium and F.A cup finals which were held in Cardiff (Wales) for 2 (3?) years due to delays in construction. And similarly here, while the supermarkets in Britain can point the finger at their suppliers, the fact they've not done their own testing isn't going to sit well with their customers. Particularly when they've almost certainly profited from the whole fiasco..

From a consumer point of view, it seems to me that the consumer demands choice at the lowest  price. Now hold on a minute there, because actually, I don't.. But, it's the line spouted by the business's involved in grocery retail so there may be a grain of truth in it. So, if we only make a purchasing decision predicated upon cost, then we're likely to get a supplying decision predicated wholly around cost with all the consequences it brings.

You'd think governance would play the part of fair, honest and effective broker in all this. I wouldn't. Basel II, Sarbanes Oxley and FSA couldn't avert the biggest banking crisis of a generation. You can try all the tricks in the book to minimise risk, maximise value and ensure the right decisions are made by the right people to the right criteria at the right time. But, if greed, gain and guile are the prevailing cultural themes within an organisation, it won't matter.

But, there is an up. Discovering that stuff has gone wrong today makes you better off than you were yesterday. You can start the job of corrective action, you can learn some lessons and strengthen whatever is needed to prevent re-occurrence. 

Finally, there's something else to take away from all of this. We can read and write all the books we like. Develop the discipline of project management in new and exciting directions. Effective and sound judgement however is something ephemeral, acquired slowly and lost quickly. 

Requirements part 4 - Kano Analysis

One of the things that I always keep in my mind when assessing and prioritising requirements is the cost of fulfilling the requirement relative to the cost of not fulfilling the requirement. I tend to think of this as the cost of compliance versus the cost of non-compliance.

Cost is an important dimension to incorporate into the overall requirements management effort, stakeholder engagement activities and so on and so forth. The application of this sort of approach is broad. I've recently been working with a client to work out which of their 'extensive' software library they wish to retain and which they can afford to withdraw. 

It isn't quite the case that there's a one to one relationship between a software application and a set of requirements. But there is often a 'service' comprising of one or more applications (and possibly more besides) which together fulfil a set of business requirements.

With all of this said, costs of compliance / non-compliance, serve as a useful entry point to start a conversation about 'what's in, and what's out'. It's quite useful too to bring any written business objectives into the equation as well.

But, as I say above, the cost argument is an important dimension, it isn't the whole story.

It can be difficult to sell a decision based wholly on cost (even if the decision is actually wholly cost based). This can be particularly trying when the end-user is divorced from the costs. So, we can bring something else into the equation which can help namely, Kano Analysis.

Kano analysis nicely skewers the fact that there are some very different types of requirements as far as stakeholder perception goes.

1. If you walk into a room and turn the light on, and it comes on you're only ever going to be so happy. On the other hand, if the light doesn't come on you will be dis-satisfied.
2. If you walk into a room and the temperature is too cold, but you can adjust the temperature with a thermostat, you'll probably be satisfied.
3. If you walk into a room and there's coffee and biscuits laid out for you, you'll probably be delighted.

Kano analysis is intended to give you a structured approach to identifying which category your requirements fall into with your stakeholders. It has the added bonus of being very quick and easy.

See the illustration below. All we need to know is the answer to two questions - the answers need to represent a consensus of the stakeholders. Workshops can be used to elicit the information and you could do something useful in a room of people with sticky labels (I'm all for getting decisions made at the coal face)

With these two questions answered we can map a requirement to one of the following categories. In practice, you don't tend to get any of the combinations marked null. It does happen an usually it's because there's a lack of consensus or clarity.

We can usefully articulate the requirements as follows. I haven't bent my meagre brain to it yet, but I can see a useful bubble chart in Excel mapping out the requirements - do let me know if you beat me to it.

And, in the event that ultimately all decision making is cost led, you can engage and communicate with stakeholders to manage expectations (and sometimes fallout) from commercial decisions that have implications for them. It's all good, useful information.

We've got two last bits to cover off and then I think that'll be an opportune point to take a break from requirements.

More on forecasting

Before going on too much further let's discuss a couple of real world scenarios that apply to any project plan.

You're relatively new on site, new to this particular project, or perhaps new to project management. Nothing wrong with any of those by the way.

You're of the opinion that as a project manager you should be able to tell the client where he's going to be in 3 months time (reasonable). The client is applying pressure for a project plan so he knows what the next 12 months looks like and there is a requirement to commence resource planning as soon as possible. A common enough set of circumstances. 

We can approach project planning in any number of ways, but I'm going to make a useful distinction between two approaches. In doing this I'm going to mis-use a couple of terms - who knows maybe it will catch-on and then it'll be correct use.

We can adopt a 'top-down' planning approach where we define the duration (say 12 months) and then attempt to undertake delivery of the project's scope in this time. Or, we can adopt a 'bottom-up' approach in which we define the PBS and WBS (I discuss these in previous posts), elaborate the work and resources required to deliver the work and let our project planning software tell us when the work will be finished.

For me, the imperatives that serve project sponsors and project management are conflicting, difficult to reconcile and are a re-current source of tension. It should be as simple as enshrining the approach in the PID, mandate or other documentation, but in my experience it isn't.

Let's look a bit more at the various advantages and disadvantages of the two approaches.

In theory at least, I'm all for top-down project planning. Sponsors define the durations (and I might add the scope and budget) and authorise (compel)  the delivery of the project's scope within a that duration. All sounds terribly straight-forward doesn't it? But then, I am of course reminded of the words of Commander C. Theo Vogelsang, USN “… in its relationship to strategy, logistics assumes the character of a dynamic force, without which the strategic conception is simply a paper plan.”. I don't think anyone has ever put it better than Commander Vogelsang.

A positive zoo of wise pragmatism on the subject of logistics from military theatres can be found here.

So, while we like top-down planning, we now recognise that it's not the be all and end all. 

So - let's have a look at bottom-up. We have a scope, that we're going to elaborate into a product breakdown structure, create a work-breakdown structure that will deliver the product breakdown structure and commence delivery. Well, no, you're not. You probably won't have a detailed project scope at the outset of a project, you won't have any funding to commit resources to the work necessary to deliver the WBS and PBS, let alone enter into the commercial contracts potentially required to deliver the actual work. In fact, you won't even get past funding approval.

Some readers may be falling back on a bit of real world experience at this point and envisioning that we commence project start-up with the top-down plan and successively work towards a bottom up plan and in reality that is not uncommon. However, this too has its problems as funding and cost expenditure profiles are often aligned to the top-down plan, and don't necessarily adapt well to that schedule being destabilised by something as annoying as a plan that actually reflects the work that needs to be done and the duration that it will take.

Recognising that I'm beginning to drone on interminably here, I'd better quick bring the end of this post into view.

Consider the following illustration. Hopefully this is broadly self explanatory. The only note I'll add is that (particularly in my field of technical infrastructure, there will always be an unalterable volume of work required to get a job done. Short term variances arise in the identified or forecast volume of work due to imperfections in diligence and discovery at the start and blunders during the work's execution. Below I refer to this unalterable volume of work as 'K'. 

In an ideal world, Kt is about the same as Kb which is about the same as K. in reality you never know K until you've finished your project. However, deciding on how important it is to know Kt or Kb accurately, or the acceptable variance between these and K should be decisions made with full disclosure at the outset of the project start-up. Needless to say - any decision should be data driven and the criteria that might inform this decision might include; cost, criticality, complexity and risk.

I think there's a few more interesting observations to be made for the illustration above - but I'm not going to elaborate that too much. What does it mean for your project's in your organisation?

More yet to come on forecasting.

Something a bit fishy...

Well it's no good beating about the bush with this one. I've produced a double headed Ishikawa diagram for the purposes of illustrating causal factors corresponding to the influence and repositioning of stakeholders. I think it's fair to say no one's done that before.

So what's the point?

First, if you need to get some background on Ishikawa / fishbone diagrams, pop along to Wikipedia. They are worth having some background information on whether or not you're a convert to my eccentric approach to presentation above.

When writing my post some weeks back "Influence - a pragmatic and effective approach" I recall a sense that I hadn't quite nailed the visuals. Sometime later I had to generate a communication management strategy for a project and, when re-visiting the topic with fresh perspective, I came up with the approach above.

So, with the combined knowledge supplied by Wikipedia and my initial post, I hope you can at least intuitively grasp what I'm trying to do here. 

But why? And more to the point, why include something like this in a communication management strategy?

Well first, I think this is a good workshop approach to elicit input. You're not always going to have enough back story on a client site to generate one of these yourself, but you can provide the footpath and fill in the information as (hopefully) the client supplies it. You can also record that input and articulate it in a way that makes sense.

Incorporating it into the communications management strategy (or other similar document) has the benefit that all communications undertaken under the aegis of the project have the opportunity to be informed by themes that should assist that overall stakeholder engagement effort. Better yet, it should do that whether or not you're there to review and edit prospective communications yourself. Generate one of these Ishikawa diagrams, provide a supporting narrative in the communications policy and hopefully, you'll see helpful references and positive themes sewn throughout the project communications effort.
*Per my previous article - the credit for the better part of the approach to stakeholder influence goes to these guys.

Making life easier (and a bit of process stuff)

Projects generally have a lot of 'interconnectedness'. And please - I don't just mean railway projects.

Processs are rarely 'stand-alone'. The outputs from one process are, more often than not, the inputs fir something else. (So help me) you'll start to hear the words ecosystem and (abandon hope all who enter) 'synergy'.

In an ideal (and possible mythical world) you have ERP, CRM and EPM tools into which all your various risks, issues etc are included. But, from time to time, the enterprising PM may find themselves without these tools and forced to fall back on more prosaic mechanisms (by which I mean Excel).

I've provided a spread sheet here. I call it ACRID (derived from Assumptions, Constraints, Risks, Issues and Dependencies). You'll also come across the term RAID (minus the constraints), and you'll probably not often come across a CORDIAL log which (of course) contains the lessons learned log. Any attempt to include a quality log is headed for the rocks.

We don't want to make life too hard for ourselves and, of course, we'll want to keep an eye on the whole process ecosystem angle so we're not duplicating effort left, right and centre.

I include here a template for a highlight report. I like highlight reports as I know of no better way to bridge the divide between the poets (for whom business transformation is a mere pen stroke) and the plumbers who lie awake all night worrying about it. I take some license but there's a sliding scale in there somewhere.

So, back to the whole inputs and outputs thing. If you take a look at the highlight report template (which is aligned with Prince 2) you'll notice there's quite a bit on work packages and products. Check back to previous posts and you'll have all all you need to cut and paste into the highlight report.

In fact I'll paste in the contents page from the highlight report template and append it with where you derive the content from each section from.

1. This reporting period

Not much going on in here

1.1 Work Packages

...Or here

1.1.1 Pending authorisation

If you need them, you'll have been writing them and you'll know which ones are outstanding authorisation

1.1.2 Completed in this period

From the project plan, paste in relevant sections of WBS

1.2 Products completed in this period

From the project plan, paste in relevant sections of WBS

1.3 Products planned but not started

From the project plan, paste in relevant sections of WBS

1.4 Corrective actions taken during the period

Issue log or other sources as appropriate

2 Next reporting period

Not much going on in here

2.1 Work Packages

...Or here

2.1.1 To be authorised

From the project plan, paste in relevant sections of WBS

 2.1.2 To be completed in the next period

From the project plan, paste in relevant sections of WBS

2.2 Products to be completed in the next period

From the project plan, paste in relevant sections of WBS

2.3 Corrective actions to be completed in the next period

Could be anything - use your judgement to include what you feel is appropriate

3 Product and stage tolerance status

SPI / CPI figures as appropriate (this will have to wait for another day for detailed coverage).

4 Requests for change

From the ACRID log so long as you raise all your changes as issues

5 Key Risks

From the ACRID log

6 Issues

From the ACRID log

7 Lessons Report

From the ACRID log

***************************************
Some points to bear in mind.

1. Truncate (i.e. hide a few columns) on the product descriptions, WBS elements, risks etc as you'll not fit them all on a single landscape A4 and the detail is probably more than your audience will want
2. I'll cover off a bit on the cost performance index (CPI) and schedule performance index (SPI) another day.
3. Corrective action could mean almost anything - include what you think is appropriate
4. Some stakeholders will want detailed information about resource burn, budget status or other detailed information not included above - this is a good sign and shows that the sponsor is 'on board' and giving the project focus.

And, to wrap up the topic of the highlight report I conlude with the following key points which I hope will impress upon you the benefit of producing it, even if your stakeholders are sanguine on the topic.

• It is an excellent tool of communication to all stakeholders, both to relay issues and status concerns but also to keep all parties abreast of progress. It is a principal tool by which the project manager can relay, escalate and communicate issues and anxieties which require board / sponsor input.
• I find it amongst the best ways of structuring a project board meeting, particularly for stakeholders less experienced in sitting on project boards
• If (like me) you keep all your WBS elements, product descriptions and logs up to date, with practice, you can produce one of these in about 20 minutes.

Conundrums in communications (part 1)

I have a bit of a love hate relationship with communications. They can suck up resource, they're fiendishly difficult to get right (I sometimes even wonder what 'right' even means) and I can't be alone in having been burnt on one or two occasions by a nanosecond's lapse in concentration on the topic. 


Conversely, they give the project team an opportunity to raise their profile, to champion their aims and objectives and, done right, they can be one of the more satisfying aspects of the job.


Here's a few headline manholes.

1. You might saturate communication channels
2. Someone else might saturate communication channels 
3. Your stakeholders 'lose sight' of the communication plan
4. Your stakeholders actually tell you they should have read the communications, but they're sorry they didn't and now they're in a bit of a mess
5. You've racked your brains but you can't work out a way to ascertain whether or not your stakeholders have read, retained and understood your communications.
6. You're facing universal stakeholder apathy (this is on a sliding scale from mildly disinterested to venomous mischief making)

At this point I could espouse the virtues of a carefully crafted communications plan or stakeholder engagement plan. But I'm not going to and here's why. If you're fortunate enough to have specialist communications input, or even just a chunk of resource to throw at communications you can spend all the time in the world on soft market research, repositioning key stakeholder groups and deciding the precise colour scheme to use across the breadth of your media interfaces. So not only will you have time and money to develop specific purpose built documents and strategies, you'll be able to underwrite the resources for them, manage them and (one assumes) see them through to a successful conclusion.

Meanwhile, back in the real world, you've fought like a tiger for the limited resource you've got, your fingers are bleeding from back to back authoring of the business case, mandate project brief, project initiation document, configuration management plan WBS and product descriptions and the sponsor is wondering when you're going to start delivering something. So you make a note somewhere that the communications plan will be included in the RAM on stage 3 of the project (or something similarly vague).

This all said, you might find yourself facing problems 1-6 inclusive, or some uniquely quirky issue particular to your project and needing a bit of communication lubrication. Below I include my suitably pragmatic salve to the issues above.

You have saturated your communication channels

The symptoms

Communications have become less effective, stakeholders are grumbling, you hear the words '...not another project blah email...' in the lift, Paradoxically, because people are starting to disregard your communications you have to send out even more. People are setting up email rules to junk your mail.

The cause

You've overcooked it. You might even simply be following the communications plan (that needs an update by the way).  You've got no temperature check or feedback loop in your communications so you keep on spamming the entire stakeholder pool whenever you feel slightly anxious that your message might be getting lost in the corporate soup.

The solution

Prevention is better than cure. You need to recruit communications stooges (confederates in the stakeholder pool or business) who will primarily assess your communications from the receiver end of the equation as well as being your eyes and ears in those environments. If you've missed the prevention boat, take a two week communications holiday while you recruit your stooges - that should kill two birds with one stone.

Someone else has saturated your communications channels

The symptoms

Broadly the same as before. You have the satisfaction of knowing that you are not directly responsible for the blunder, but the annoyance that you will have to directly fix it.

The cause

Could be a lot of things but two spring to mind which I cite specifically because you'll approach the matter differently.

1. Poor email etiquette from co-workers. You're getting a lot of reply alls on emails or, other, similar blanket channels of communication are springing up. You're not managing them (in fact no one is), messages are getting garbled and coherence lost.
2. Someone in the customer's organisation, the stakeholder pool or simply someone you need to do business with is suddenly and deliberate fielding a great deal of communications, most of which is making your day a good deal harder than it needs to be.

The solution

In the first case, you're going to need to get that someone some feedback on email etiquette or simply the fact that communications for project blah start and end with the project team. That'll probably get you fixed.

The second case is a bit more of a curve ball and is correspondingly a little tougher to fix. Remember the communications plan we were going to right in stage 3? You need to get that thing written promptly. Don't kick yourself - having it earlier wouldn't have done you any good. 

You're going to need to define your communications interfaces, media, authorised and approved communications providers and get the plan approved by your project board. You will of course ensure that you've specifically outlawed stakeholders exploiting project communications channels to prosecute their own agendas and you'll also include that breaches of the communications plan will result in a project issue being raised to the board.

I can't promise you this is the panacea to every stakeholder that decided their views superseded those of the project board or sponsor - but this does tend to either quiesce over active stakeholder communications or, in the event it does not, reduces your exposure as PM to the problem as you've got some structure and a readily available channel of escalation.

I'll see off the remainder in the next post. If anyone has any communications issues not listed, do add a comment - I can't promise to have an answer, but my readership is almost into double figures - we'll crowd source an answer!

Influence - a pragmatic and effective approach

Robert B. Cialdini's book - Influence: The Psychology of Persuasion is a good read. The consistently underhanded techniques of car salespeople and evangelists for one or other faiths is entertaining, enlightening and extremely useful in terms of knowing the sorts of tactics employed by sales, marketing and a host of other people trying to get you to do something they want.

However, its not that much use for this project manager other than gaming* members of the project team on who's turn it is to make the tea round.

* One of those verbalised words becoming increasingly popular. However, links to game theory and a constant reminder that complexity manifests unintended consequences means the author has a ticket for this bandwagon. 

Typically I have fallen back on the techniques learned in the field of service delivery. Equally I have had the wonderful opportunity to see just how powerful presenting stakeholders with new and better information can be. Don't ever underestimate the potency of this very simple approach. And while we're at it, don't ever confuse simple with easy!

By pure luck (a lot more on this in the future) I was fortunate enough to attend a talk run by the excellent APM on the subject of Influence. This was an hour long distillation of some of the key points contained in the book Influencer: The Power to Change Anything  - a deservedly bold title with too many authors to include here easily.

I'm not going to seek to reproduce precisely what the book encompasses, but I will include the illustration below which I think is certainly a core principal.

I've used here the simple example of encouraging cycle helmet use amongst cycle commuters. The book's authors, backed by a bibliography longer than is typical, contend that people don't do things because they either can't or don't want to and do things because they can and they want to.

Straight away, I think there's an interesting observation to be made right there - people only need one box ticked not to do something, but both boxes ticked to do anything.

Next, the book's authors identify three domains in which these motivations can arise, the personal (you), the interpersonal (peer pressure) and environmental (what's sitting in the immediate vicinity).

Supplemental to this having been proven to be a very effective approach, it is a wholly defensible and legitimate strategy to employ with stakeholders, one that can be documented and one even that the customer will find it difficult to find fault with.

The book elaborates some remarkable success stories using this approach. It makes the point that you only need to 'tick' four out of the possible six boxes in order to stand a very great chance of success.

Again, the dimension of proportionality must be considered, but if you need to reposition stakeholders and this is critical to your project's success, then I contend there are few better approaches.

Dimensions in stakeholder engagement

In my last post, I tried to make the case for the abolition of stakeholder management. In summary, people don't like being 'managed'.


Don't misunderstand me however, neglect your stakeholders or under resource this crucial aspect of project management and you're in trouble.


There's a very good article here published in The Register in 2007. Quite apart from making some very good points about about Gartner's Magic Quadrant generally, it's got some solid points which can be applied here.

This illustration is perhaps best described as atypically typical. It embodies superficially the approaches adopted by some organisations in appraising stakeholder's importance and influence to a project or programme. 


There are shortcomings in this approach; it's a snap-shot in time, your appraisal of a stakeholder's importance might not tally with theirs, it's too coarsely graded - there are shades of grey here and, perhaps most importantly, it seeks an 'absolute' measure of stakeholders when I feel a far better approach would be a 'relative' measure.




A few amendments can mitigate some of these shortcomings.

We've now got a more finely graded system of measurement. We have (slightly) alleviated the issues of labelling a stakeholder as unimportant, we've got a relative approach via which one stakeholder can be appraised relative to another.


It's still a snap shot in time, and it doesn't incorporate as many dimensions as I personally would like.


Let's keep going.

Okay - so now we have some way of illustrating the different types of stakeholders. In the example here, stakeholder 1 could be an individual and stakeholder 2 could be an organisation and I've used the size of the marker to indicate this. I've coloured one red and one blue and this could indicate anything you want really. Say what you will, we all have the occasional 'red' stakeholder.


Where stakeholder 2 has come from and where we'd like stakeholder 1 to go is also illustrated. We could change the shape too - adding still yet more information.








You'll note too that I've added identifiers to each quadrant on the chart. This is a good way to tie up the stakeholder matrix to the communications plan enabling you to cite which communications go to which stakeholders (if you need to).


Nothing we've discussed here has encompassed the very important issue of proportionality. I do not say what you must or must not do when it comes to stakeholder engagement activities. I'll  post on this more in the future.


This question of proportionality will go along way towards informing how you proceed in terms of generating, maintaining and publishing this information. You could scratch this out on a sheet of paper with paper and pencil and often that might be wholly suited to the activity. In this instance, remain conscious of the limitations and adopt a more appropriate level of rigour if circumstances change.


At the other end of the scale, you could derive stakeholder's position relative to one another with questionnaires, plot the output via Excel, publish via SharePoint's excellent Excel Web Services and have hyper-links to stakeholder contact information and host of other information. 


Some points to finish off with. It doesn't have to be importance and influence. The following may be just a valid; impact, interest, sponsorship, tenure, location, sensitivity and probably quite a few more. Often influence and impact work just fine, but don't just 'go along' with those measures if they're not optimal.


Undoubtedly, the question of how to reposition stakeholders must be asked. That'll be the subject of another post.


Also, has anyone ever thought of sitting down with stakeholders and asking where they feel they are most appropriately placed? This resolves the potentially knotty issue of ascribing stakeholder's a standing that they do not support.


Lastly, what I've tried to do here is remain consistent with the point made in a previous post. Don't manage stakeholders, manage the relationship. Do this through engaging with stakeholders.