Sunday, January 20, 2013

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.





Saturday, January 12, 2013

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.