This is not a post about critical chain project management

Ever had an itch you can't scratch? I don't have one of those.

What I do have is a lingering doubt. A sense that something or someone could answer a lot of questions if I just knew the right questions to ask and the right forum in which to ask them.

Some of these doubts and uncertainties have been discussed previously in this blog. But for clarity I'm going to cite the half dozen things that (I think) are just not good enough in project management right now.

1. Planning. Consistently falls short of what is required. Work is not identified, not adequately defined, not forecast accurately and doesn't have the corresponding supporting information to enable the brokering of appropriate resources. Successors and predecessors aren't pinned down accurately, F-S, F-F, S-F relationships aren't identified with the precision required
2. Resource brokering. If (as is the case within technology infrastructure projects) your project's delivery is dependent on skilled and scarce human resources  then resource brokering should be fit for purpose. Hands up all those people who work on projects with great resource brokering.
3. Success. Don't get me started (mainly because there's an angry man here who already has)
4. Perception. Does anyone out there hold projects, project teams, project managers in high esteem?
5. Benefits / return on investment. Goodness me but there are far to many people charging out for delivering change when surely the game should be delivering benefits.
6. Profits. Executing change effectively and efficiently will enable you to deliver your strategy with less risk and more value than your competitors. It follows that your costs will be lest, your agility greater and your profits will reflect this. 

Notwithstanding all this, there's Prince 2 and PMP accreditations, quite a bit of software intended to solve some of the knottier project management headaches, a recognition that practitioners of change are specialists and even that some expenditure on those specialists is a worthwhile investment. And, health checks, specialist consultancies, more historical data than you can shake a stick at, more than one MSc and a partridge in a pear tree. 

Perhaps most importantly (and I can speak a bit from experience here) there's quite a few bright folks in the industry and there is no limit to their determination and tenacity in trying to bring projects in on time (whatever on time means - 'cos I'm starting to get a bit jaded around that - but more on the "Aggressive but Possible" (ABM) vs. "Highly Probable" (HP) paradox another time. Discussions of 'on-time' aside, there's still the questions of scope, quality, benefits and cost.

Could it be there's something fundamentally wrong with the underlying mechanisms of project management or their application? I could go the route here of an extended negative hypothesis routine in which we discounted one by one all the other candidate explanations. I'm reasonably certain that a blog post is neither the time or the place. So let's cut to the main course.

Planning assumption #1 then; there's something wrong with project management approaches / mechanisms. Or at the very least something wrong with the way they're applied. 

If this planning assumption is born out (and there's quite a weight of evidence to suggest that it might be) then ideally we'd need something waiting in the wings as a substitute. While the current status quo is (ripe?) for improvement, it wouldn't be impossible to make it worse.

And that substitute just might be Critical Chain Project Management. I'm not going to tell you what I think. There would be an implication perhaps that you too should be thinking that. I think we all need to come to our own independent conclusions about Critical Chain Project Management but I will post on it again in the future and if it elicits only critical scrutiny of existing methods and approaches then that alone will be a worthy objective.

Requirements part 5 - a very useful spreadsheet

I think there might actually have been one or two more posts on requirements than 5. No matter the end of the tunnel is in sight.

I've written quite a bit about what not to do with requirements and conversely some useful salves for common problems. What I haven't done (until today) is state clearly my approach to managing requirements (and more besides) or provide the tool to get the job done.

To date, we've talked about MoSCoW analysis (yuk!), pair-wise comparison, cost of compliance / non-compliance, KANO analysis and quite a bit more besides. We've never talked about UML or a bunch of other stuff, but ultimately (as you'll see) that might not matter too much.

Consider the illustration below - a veritable soup of inputs relating to requirements. Equally, a customisable and completely transparent score card that can be constructed and agreed by stakeholders early in the process.

What we're starting to get towards here is an approach to requirements prioritisation and management that can be highly customised to suit any situation. 

Get the stakeholder buy-in right, get the score card right and the rest will follow.

In the example below, I've used the following scoring elements - you however can use what you like.

• MoSCow - exactly what it says on the tin. MoSCow does have its place albeit do remain cognisant of the limitations previously discussed.
• Kano - see last post. A quick and easy way of assessing non-monetary value
• Contribution to the business plan - if it doesn't contribute, should you be doing it?
• Compliance - do we have to have this to meet regulatory requirements?
• Senior stakeholder flag - if the the budget holder wants it in taupe, then let's have that right out in the open from the get go.

Your score card might incorporate the elements illustrated above or be something complete different. You might have specific organisational imperatives which mean you incorporate none of the elements above - fine. The approach is no less valid.

So - you've got a score card - what next? Excel that's what. What you're seeing below is the scorecard above incorporated into Excel.

It's not too busy a spreadsheet but it has got a couple of tricks up its sleeve.

First, the fields are 'constrained' and aligned with the scorecard.

And, we've got a a simple but long formula to do the scoring calculation. Note the red highlight. We don't put the scoring in the formula itself - we use a lookup to a table elsewhere. This is important and we'll discuss this more later.

=IF(C2="Must have",Lookups!$B$1,(IF(C2="Should have",Lookups!$B$2,(IF(C2="Could have",Lookups!$B$3,(IF(C2="Won't have",Lookups!$B$4)))))))+IF(D2="Dis-satisfier",Lookups!$D$1,(IF(D2="Satisfier",Lookups!$D$2,(IF(D2="Delighter",Lookups!$D$3)))))+IF(E2="Key",Lookups!$F$1,(IF(E2="Required",Lookups!$F$2,(IF(E2="Aligned",Lookups!$F$3)))))+IF(F2="Yes",Lookups!$H$1,(IF(F2="No",Lookups!$H$2)))+(IF(G2="Yes",Lookups!$J$1,(IF(G2="No",Lookups!$J$2))))

I've uploaded the spread sheet here and you can play to your heart's content.

Some things to bear in mind.

1. You aren't constrained to 'sum' the scores. Multiplication has its place particularly as it opens up using a zero to effective nullify a requirement
2. You aren't constrained to using this just for requirements - the same approach works very well for (say) assigning a risk rating to server moves in a data centre migration
3. I've used significantly larger spreads sheets both in terms of the number of criteria used and the scores which correspond to those criteria. Undoubtedly there's a limit but I haven't found it. If you do (and good luck with that) you can always split the formula in two and sum the output.
4. Don't limit yourself to linear scoring - in point of fact, you're going to need to justify very carefully the use of linear scoring (i.e 1,2,3,4,5,6 as opposed to 1,3,8,20). Most things (I think) will benefit from a non-linear scoring approach.
5. Make sure you get your criteria right from the get go, the scoring only needs to be 'about' right as we re-tune that later on.
6. Weighting - don't think you can't apply a specific weighting to one or more elements on the scorecard - in point of fact this is just another way of playing with the scoring but don't rule it out.
7. If you're smart enough you can probably use a custom list in SharePoint to do this.

Finally, getting the scoring in the scorecard right from the get go is tough. So tough in fact that I discourage you from trying. Stakeholders can get a bit cagey too as, while they see the merit in the approach, they tend to be less certain about getting tied down by a scorecard that they (quite understandably) can't appreciate the fullest implications of at the outset.

Fine tuning the scoring is the subject of the next post.

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.

Requirements, part 3

So far, I've had a good whinge about the MoSCoW method of requirements prioritisation, and suggested the alternative method of paired comparison. In this post I'm going to talk a little about the life-cycle of a requirement and why the management of requirements is pivotal to testing and product acceptance. In a future post, I'll come back to the topic of requirements prioritisation to provide a middle ground between MoSCoW and paired comparison.

 First, let's revisit the method of achieving quality I put forward in a previous post.

It's probably time to add a few more specifics around this, and that in turn will provide an entry point into several subsequent posts.

1. Requirements - this is the subject of this post and (at time of writing) two others besides. The scope of this activity extends to the elicitation, prioritisation, specification and management of the requirements
2. The QRA will be the topic of a subsequent post. For those impatient to get to grips with this, read Rex Black's material here. In short it's an analytic approach to prioritising the testing effort with a view to minimising risk
3. Development and implementation - we will get to this at some future point. As project manager you should be planning, directing and controlling this activity.
4. Testing - a big big topic but I'll endeavour to distil some valuable points during the course of future posts. I'm a big fan of V-Model development and sowing test activities throughout all development activities. Crucially; every development activity has a corresponding test activity. I would also keep in mind IEEE 829, a standard approach to test plan management. Links here and here Plenty more to come on this topic.
5. Defects have a management life-cycle all of their own. This is to ensure that efforts to resolve the defects are suitably prioritised, that defects when resolved are confirmed as fixed and a whole host of other activities. I'll post a couple of articles on this in the future.
6. Lastly the quality log. Technically, it is not strictly required however, in isolation the defect log (a component of defect management) paints an overly bleak picture. (Try having a defect log of 600 things which don't work - it doesn't make for happy project boards either). Incidentally, it helps too with product acceptance as opposed to the defect log (recording things which don't work) it provides a central repository encompassing all the things that do work.

So with this all said, let's focus on the role requirements play at each stage above. First, there's the requirements themselves. The QRA cannot be produced without a clearly understood set of requirements and do please note that this tool is sometimes crucial in placating legitimate stakeholder anxieties. Undoubtedly it is possible to start development and implementation activities without a detailed requirements specification. Doubtless too, this is one of the principal causes of project failure. You can certainly build something, but you cannot achieve quality without a clear understanding of what is required. Testing specifically is the activity of identifying defects and defects are defined as requirements that haven't been met. You cannot test a system if you don't know what the requirements for that system are. Defect management - the process of managing defects through the defect life-cycle cannot be undertaken without a detailed understanding of requirements.

So at every stage of this activity, requirements are playing a principal role. I think that'll probably suffice in terms of the 'big picture'. I have endeavoured to provide a solid basis upon which to build in future posts. These will include posts on how I typically approach the prioritisation of requirements, an explanation of the QRA, a complete review of the defects management life-cycle and more besides.

Requirements, part 2

Previously, I took a aim at MoSCoW as a sub-optimal approach to the prioritisation of requirements. Keen not to simply leave a deficit, I wanted to follow up quickly with something a good deal more rigorous. To be fair, too rigorous for it to be used all the time. But as the saying goes, every job has a tool, and every tool has a job.

My principal concerns regarding MoSCoW was the coarseness of its gradated priorities. Taking a little license, its categories correspond to a critical must have requirement, an almost critical must have requirement, a don’t really need it but I’ll take it if it’s going and the somewhat ambiguous ‘won’t have this time’.

As I elaborate the theme of requirements, I’ll try and specify usefully the attributes that can be applied to requirements which inform prioritisation. However, the prioritisation of requirements might not simply be a process of analysis based on ROI, cost of non-compliance or other similar quantitative measure. It might come down to what the customer wants.

The customer isn’t going to understand why you want to prioritise requirements (they’re all critical aren’t they?). Once you’ve justified the importance of prioritised requirements (I’ll cover this in a future post), you’ll have to assist the customer in the prioritisation while at the same time facilitating the customer’s participation. You’ll want to ensure the output is documented and that any prioritisation is evidence based with a clear audit trail.

That’s where the technique of paired comparison comes in. This will prioritise requirements with respect to one another achieving a potentially limitless gradation of requirements. It has to be said however that in practice you’re not going to be applying it to large number of requirements. The effort increases pretty steeply with the number of requirements being compared. For instance with 10 requirements you’d have 45 separate decisions that have to be made, collated and recorded. With 20 you're up to 180. So really, you’re talking about small number here.

See below for an illustration of paired comparison. What’s being done here is to compare each item in a group with every item in the group.

For our purposes here, we could relate various items of fruit to letters, A = Apple, B = Banana, C = cantaloupe and so on. The next step would be to compare A with B, and record what the preference is. Having done that, A is compared with C and so on until every fruit (requirement) is compared with every other. In my example above, the score is a simple count of the number of times that option was selected, this is then expressed as a percentage and finally a rank order is created. If you use my spread sheet here – it’ll do all the sums for you once you’ve filled in the table.

If you have a short list of requirements which are expensive and need to be shortlisted with respect to funding constraints, this would be good approach. Equally it could be used to get some user perspective on which features they'd like to see prioritised within a new implementation. There’s nothing to stop you underpinning this activity with deep dive technical analysis but if you have the figures you’re less likely to need to undertake paired comparison. However, if you’re in the business of comparing apples with pears and require an output which clearly reflects stakeholder preferences, this should help you out.