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.

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.

Theories need evidence, facts need proof.

Always nice to stumble upon an academic bun fight. For the very tip of a very large iceberg on the relative merits of quantitative versus qualitative analysis see here, here or here.

But I'm a PM not an academic so what's the angle? My qualitative answer would be that knowing the difference will sometime enable a project manager to make optimal decisions . My quantitative answer is about 45 degrees - which to be fair isn't much use in this context.

For reference.

Quantitative research consists of those studies in which the data concerned can be analysed in terms of numbers ... Research can also be qualitative, that is, it can describe events, persons and so forth scientifically without the use of numerical data ... Quantitative research is based more directly on its original plans and its results are more readily analysed and interpreted. Qualitative research is more open and responsive to its subject. Both types of research are valid and useful. They are not mutually exclusive. It is possible for a single investigation to use both methods. (Best and Khan, 1989: 89-90)

Qualitative research is harder, more stressful and more time-consuming than other types. If you want to get your MEd dissertation or whatever finished quickly and easily do a straightforward questionnaire study. Qualitative research is only suitable for people who care about it, take it seriously, and are prepared for commitment (Delamont, 1992: viii)

Both these excerpts are from "An introduction to the qualitative and quantitative divide"

Whether it be the generation of the initial business case, the management of risk, key design decisions or resource planning, the project manager is faced with a veritable zoo of decisions. Some are more critical than others and on a sliding (qualitative) scale we make decisions which if wrong have very limited consequences to those 'irreversible' decisions to which great heed must be paid.

Question; has anyone ever sat down with project stakeholders and asked them if they want quantitative risk management, qualitative risk management or both? Do you understand the question? Would your stakeholders? Does it matter?

Take the following examples. First, what I hope will look a fairly typical excerpt from a fairly typical quanititative risk log. All with me so far?

 Next, something from the qualitative end of the spectrum.

R1 - qualitative assessment


Failure to provide adequant fencing, or early warning mechanisms as appropriate may result in injury or death to Donald Duck.

(A little digression here on the the two approaches to risk - if you fail to communicate to your board the potential impact of a risk with numbers (quantitative) try words instead (qualitative). On more than one occasion I've managed to elicit a response by describing in detail the consequence of a risk occuring having failed by ascribing it an impact and probability.

The Beaufort Scale incidentally makes rather good use of both qualitative and quantitative approaches - that's meteorology for you.

The PERT weigted average here is purely quantitative.

Now I could rattle on at length here, but I don't know if a blog post is quite the place for it. So I'll leave you with a couple of summary points.

1. Make a judgement of which type of data suits your needs and then go and get it
2. Personally, I prefer numbers to adjectives (with the proviso that they're right)
3. Look back at the quantitative risk assessment example above. Are your quantitative risk assessments based on analysis of the statistical likelihood of the event and the impact to cost and time should it occur? If not, then your quantitative analysis is in fact a qualitative analysis.

Proportionality in controls

Early identification of the 'pinch' points and putting more effort towards controlling those elements is, in my opinion, time well spent.


In the example below, we're 5 months in on a project, the customer isn't too sensitive to cost, but is extremely sensitive to delays.

Doubtless there are a few ways of tracking quality. I've often thought that if you're handing over  project deliverables sequentially, CPI and SPI sort of give you a 'QPI' or quality performance index since your customer is signing off acceptance of products as you go. 


With IT projects you do involve the customer in test and review activities throughout the design and development work, but sign-off tends to be a bigger bang type activity. The PM of any IT project needs to be fully cognisant of the customer's wants, needs and any deficiencies as an ongoing process. This activity is encompassed within testing and defect management.


I'll do a post at a later date on the range of metrics relating to defect management which I like to capture but here I've singled out something I've always been very keen on. See the bottom of the three charts above. Something not entirely clear is that that the graph isn't cumulative. Each month the number of defects identified that month is plotted against the number of defects fixed that month. At a glance, this shows whether or not you have an unsustainable, worsening or improving state with regard to defect identification and resolution.

Note the control charts above, not only are these easily maintained and communicable, they illustrate trends and the tolerances to which the project is expected to adhere. Incidentally, I'm a fan of publishing this sort of material directly to the project team - it encourages shared ownership and good alignment of decisions throughout the project team.

As can be seen above we've got more tolerance on cost than time. Take the cost (CPI) plot, we went from a good start, to holding steady, followed by three consecutive periods of deteriorating performance. With the benefit of hindsight it would have been useful to have a more frequent reporting interval - if we'd had fortnightly reporting - somewhere between month 2 and month 3, it would have become apparent that corrective action was required, and consequently far more easy to justify.

While the time (SPI) plot serves to illustrate this point very well, what we could have seen in advance was the very limited tolerance on schedule would have benefit from more regular reporting for precisely the reason above. The emergence of a trend would have happened far more quickly.


These sort of indicators are one approach to helping ensure that within any given project, benefits are maximised and risk is minimised. The best indicators are those that inform timely decision making before things go off the rails, not simply reporting on the fact that they have.

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.

Whatever you do, don't manage stakeholders...

This post was initially going to be entitled "Dimensions in stakeholder management". But I realised I had a more serious bee in my bonnet to deal with first and then, and only then, might we be able to move on.


One thing I'm pretty certain about is the practice of stakeholder management, while probably sound, legitimate, crucial even, is about as shoddily titled an activity as any I've come across.


Management, not the practice of training horses as the sixteenth century Italian derivation of the word might lead you to believe, but planning, directing and controlling. And therein lies the problem. You're going to plan, direct and control your stakeholders are you? Well if I'm on the project team, could I be excused? And if I'm one of the stakeholders, beware!


You cannot plan, direct and control stakeholders. In point of fact the practices of 'stakeholder management' don't actually tend to encompass these activities in quite such a provocative fashion, so really, it's something of a misnomer.


The sales and marketing teams have been on to this one for years and you don't hear the phrase "Customer Management" do you? Off course not, because it's about money and these things matter. So we don't manage the customer (they're always right anyway) we manage the relationship. So right here right now, I call for the practice of stakeholder management to be abolished and be replaced with stakeholder relationship management. If successful, and if this is my only contribution to the canon of project management nomenclature, I will be more than happy.


I think this is a stand-alone post, so I'll leave it there. For dimensions in stakeholder relationship management, you'll have to wait.

Turning data into information with earned value management

While a firm believer in earned value management I have a confession to make. I've never joined a project or programme in which earned value management is in use. Either within my specific work stream or any other that I have been able to get sight of. I estimate there are potentially three likely reasons for this.

1. There is no requirement to track cost or schedue performance in fine detail
2. There is no capability or inclination to use earned value management
3. There is no market for the specific outputs of earned value management

I might be able to help with number three.

I'm a fully paid up member of the Association for Project Management (APM). The APM has several publications and its Earned Value Management Guide is (I think) one of the most thorough and clear pieces on the topic by anyone anywhere.

The document covers a great deal of material but I include here what was, for me, an entirely novel approach to illustrating earned value - namely the bullseye chart. See below.

Now, for earned value advocates I appreciate that some of the trending and intuitive extrapolation is less apparent. However, for sponsors and stakeholders not well versed in earned value management, I think its appeal is self-evident.

Equally once the initial spreadsheet is assembled, it uses precisely the same data as traditional earned value charts so really, its very little extra effort.

I owe a huge deal of credit to Jon Peltier of peltiertech.com, an MVP with superlative Excel knowledge for providing a step-by-step on his site for how to create a bullseye chart. It is remarkably finicky. You'll be pleased to know, I've saved you all the hard work by including an Excel file here which you're free to use.

I believe it's possible to add date markers to the series labels on the graph which I think would be an enhancement. And for those of you with an appetite for such things, you could publish this via Excel Services in SharePoint and, using external data sources for the bullseye chart, have a real-time dash board for all your projects.