Is that a project manager or a product manager you're after?

I typically do quite long stints with clients. This enables me to approach the market every 2-3 years with a clean pair of eyes and some ability to discern how it has (or has not changed).

And, I observe a dominant trend in the market for project managers. Something that while it may have been present previously, is now all but ubiquitous. 

Let me ask a couple of quick questions first - consider this a little warming up to the subject.

1. Which project management methodology requires the project manager to be a subject matter expert?
2. Which project management process requires the project manager to be a subject matter expert?
3. Which project management product requires the project manager to be a subject matter expert?
4. Which project management process, product or methodology requires the project manager to have implemented the same (or nearly the same) product before.
5. How many projects fail due to a lack of subject matter expertise on the part of the project manager?

(Please note - your project management subject matter expertise is a given)


And, the answer in all cases (as you almost certainly reasoned for yourself) is none of them. Even if you quibble the last one - it's almost a self-evident conclusion if you accept the other 4.

Now I do understand why project managers tend to operate in their chosed fields of (say) construction, accounting or (in my case) information technology. If you spend 90% of your time communicating, you can't spend 90% of the time deciphering what (for the uninitiated) is going to be opaque jargon.

But, that's not what I'm seeing. What I'm seeing is hiring managers who (for instance) are seeking a highly literate technical project manger, with (say) extensive CRM experience and (in particular) SalesForce.Com. But also (and these aren't necessarily nice to haves), Oracle, SQL, Agile, UML. Oh and not forgetting your extensive (for example) experience with off-shore oil and gas and the two CRM implementations you'll have already done.

Now a quick review of some of the chief culprits which cause projects to fail

1. Poor risk management
2. Poor stakeholder identification / engagement leading to omission of requirements
3. Estimating that corresponds in no way to what is achievable on the ground
4. Flawed business case
5. Poor scope control

So which of these are addressed by anything other than good project management practice? Yep - none of them.

So how did we get here? I can't say because I'm not a recruiter with my finger on the pulse of the concerns and imperatives of hiring managers, but I have my suspicions. 

1. Unprecedented levels of cynicism towards both project managers and the profession of project management
2. Organisations instinctively reaching for the comfort blanket of 'someone who's done it before'.

I'm somewhat fortunate in that my technical background allows me a certain discretion. But I know this. On any project where I'm forced to use my technical expertise, I'm not doing the job the client is paying me for. And worse still, neither is somebody else.

That's agile with a small 'a' for me please

Business agility is a good thing. But that's not Agile project management. Agile working is probably a good thing in most cases, but that isn't Agile project management either. An agile mindset is more or less obligatory for the jobbing project manager - but nor is that Agile project management.

Don't get me wrong, there's a lot to like about the Agile Manifesto and even more to like about the 12 principles which underpin it. (I must remember to say the words "...maximizing the amount of work not done is essential" in my next job interview). But neither of these things are (in themselves) project management.

I can understand the appeal of Agile to programme stakeholders. If you've adopted Prince 2, all your requests for change should technically be added to the issues log. This can sometimes lead to a distinct cooling of the relationship with the sponsor when (inevitably) it is their requests for change. And it's not just Prince 2, if you've adopted the PMI/PMP standard, then one of the sponsor's key roles is to defend the project from change.

Against this, Agile adopts the persuasive position of "Welcoming changing requirements, even late in development." And, show me the techie who wouldn't heartily endorse the value of "working software over comprehensive documentation".

But since there isn't actually any such thing as "Agile Project Management" per se but rather a collection of iterative approaches (namely; Scrum, Extreme programming, Agile Modeling, Unified Process, Agile Data, Kanban etc) what exactly were you after? Because if you don't know the answer to that question - I certainly don't. (It might be that by the time I've finished this post - there will be such a thing as Agile Project Management - its a fluid landscape...)

Is Agile something of an emerging 'norm' in software development (and selected other) projects? Undoubtedly. But I'm not even sure if that's the point. If you're a programme sponsor or budget holder attracted by Agile techniques and want to know what you are going to get and when you are going to get it, you might want to validate that Agile can answer these questions to your satisfaction.

But you've heard all sorts of good things about an iterative approach and you want one? Fine - adopt v-model development or incorporate specific iterative elements into your project methodology either by tailoring Prince 2 or adopt PMI / PMP which already has a healthy iterative element in its planning cycle.

Personally, when I hear the word Agile used on projects I'm usually on the immediate look out for either of the following potential issues;

• Is the project simply too big to satisfactorily drive out one set of objectives and requirements (in which case it should be split into multiple projects)
• Is your schedule so tight that to spend the time required on planning "is going to place the schedule into an unacceptable negative schedule variance".* (in which case you should hire in some lots of very smart planners, recognise you're running at high risk and adopt rolling wave project planning 

*Credit to Wikipedia for turning 1 syllable (late) into more!

It isn't my view that Agile 'anything' is necessarily the antidote to these two potential issues. 

The author is a business focused, benefits driven project manager with no formal qualification in Agile and no experience whatsoever in developing software. Other views undoubtedly exist.

Would you be comfortable with an independent audit of your CV?

1. Go for it - you'll be lucky to find a spelling mistake
2. I'm okay about this - there's supporting evidence for most of it
3. None of the above

Some people might regard me (and many of those who share my views) as somewhat idealistic, potentially a little naive or maybe just unhelpful. I don't.

I don't fib on my CV. Never have, never will - and there's plenty like me too. Other views do exist and they always will.

To some extent, some hiring managers can afford to be somewhat relaxed about this - they either outsource the effort to validate the CVs or structure the interview to mitigate the risk.

If that was really an optimum way to work however - they'd have been no horse meat scandal. We'd accept 'mis-labelling' as a cost of doing business and move on. But then the horse meat scandal had two victims - those who (like me) might have been partial to the odd 'Shergar pie' now and again and also the legitimate farmers and retailers who's margins were either driven down or eradicated by one product masquerading as another.

And so it is in the professional arena. We have hiring managers who are being misled (examples too numerous to quote) and job seeking professionals who are being squeezed by candidates with less professional integrity. And, when an individual is prepared to concede in the national press that not only have they lied on their CV but they'd to it again - that's a problem.

For the time-being though, all I can do is help my clients sift CVs and seek to validate in interview their content. This experience has acquainted me with business analysts who can't analyse and technical specialists who aren't special at all. Which is fine up to a point. I do however reflect lamentably on all the CVs which were passed over because they didn't measure up to someone else's masquerade.

PMs probably aren't normally distributed

I probably ought to start out by suggesting that the content below isn't supported by a shred of evidence. Now, unhindered by the need for proof, let's move along.

Let's create some arbitrary boundaries namely; does not meet requirements, meets requirements, exceeds requirements.

In the illustration below I've taken the (arbitrarily selected) profession of plumbing and assumed three equally sized buckets into which professional plumbers could be slotted in.

But wouldn't all professions be similarly distributed? No - take the example below

Here we've got a safety critical role. Constant audits, training and re-examination ensures a very different distribution. I might expect the profession of pilot to be an even more rarefied example.

So what next? I'm probably least able to speak to the profession of teaching. However, it's public sector - there's more support and management for staff yet reach the standard required. There's also less emphasis (and funding) to exceed requirements.

So what's a reasonable position to take for the profession of project management? Here's my 'gut feeling' on the distribution of project managers across the capability range.

So how did we get from our nice orderly world of plumbing to the highly eccentric world of project management? 

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.

A cow, an Alderney and a raging bull...

Apologies for the gratuitous blog title. Google's decision to withdraw their excellent Reader tool has quite scythed my readership statistics with a corresponding impact to my moral.

I'm minded to start up such cheap tactics as including the names of minor celebrities such as Paris Hilton and Miley Cyrus simply to catch some incidental drive by traffic.

As a jobbing project manager, one of course does get a reasonable level of exposure to the catalogue of general (and often dubious) apocrypha that accompanies the day to day cut and thrust of managing change.

An example of such apocrypha would be "...all projects succeed and all projects fail. Just to varying degrees of both..." which is possibly a little trite, but I quite like it all the same.

One such example which I don't like is "...you pay a project manager to worry so you don't have to...". I've never liked this terribly much because in theory a very talented worrier is suddenly a sought after commodity and I'm not one of those.

And then there's this little gem "...you pay a project manager to communicate..". Simple, undisputed fact. I like it.

Perhaps because I'm a little left of centre about these things, I've always thought that Alex Alexander Milne's "The King's Breakfast" contains many allegories useful for the project manager. There's some stakeholder management, some requirements management, setting of expectations and supplier management all in a few simple lines intended to amuse children. There's even some remarkable insights into value management. (Okay - that last one is a bit of stretch

So perhaps now is an opportune time to elaborate a little on the title of this post. One of the challenges faced by the PM is summoning the language, the agility, wit, poise and timing to communicate effectively. Don't get me wrong, the PM isn't unique in having these challenges but the PM is certainly likely to be in the room when;

1. The sponsor asks for dairy products from the cow;
2. The supplier questions whether it is an Alderney or a Friesian from which the afore mentioned dairy products should be derived and;
3. The site foreman explains that no amount of coaxing is going to persuade an angry bull to give up a pint of the white stuff.

Yes, yes - I know, all part of the usual carry on a project management. But for our purposes here, we're talking about milk, Friesian's and bulls. And, you won't be. You'll be talking about change and, likely as not changes to an existing landscape many years in the making. You won't be talking to the king, the queen and the dairymaid, you'll be talking to real people with real skin in the game each of which is likely to have different needs and agendas, some of which will undoubtedly conflict. The information they want will be put to different purposes and will need to be presented in a range of different formats and mediums. Sometimes it's a one off and sometimes it'll be a repeating and up-to-date feed potentially updated in real time.

If this isn't delivered or can't be delivered it's likely to be the PM's phone that starts ringing.

So what useful steps can taken up front to guard against the prospect that either you can't or don't communicate as required. And, to understand the expectations and, where necessary to inform them.

1. Process and procedure. I'm not going to labour this one, I hope rather that it is self-evident. If you don't have process and procedures, make sure you can report on whatever alternative is in place. And by the way, I'm not altogether sure what that alternative is Semantics aside, there's usually a way to navigate around aspects of work that are inherently not susceptible to process. Wrap process and reporting around them and 'go up the stack' to ensure that the entry and exit points are understood within an overarching 'flow of process'. Acknowledge that there may be elements of the overall flow of process which are able to be more accurately and more precisely reported upon than others.
2. Validation and verification. Make sure you're doing the right thing. And make sure that thing is done right.
3. Nomenclature and language. Make sure that you're all singing from the same hymn sheet. Make sure your inputs are capable of supporting the required reporting outputs. Do not make assumptions that the data will just join up. Define it to the required level of detail and perform the requisite static testing and prototyping to ensure that it all stacks up.
4. Create standards, generate and publish a configuration management policy which is aligned and supports your overall reporting aims.
5. And perhaps most importantly make sure you, as PM ,are in the room to inform the discussions to make sure these steps are taken and that the necessary resources are allocated to the tasks.

 So, as it turns out, the phrase  "...you pay a project manager to worry so you don't have to..." might not be so much dubious apocrypha but rather something to say three times a day before you go to work to ensure that not for one minute do you ever forget it.

Late for a very important date - again?

Say what you will, most projects don't get delivered on time. A critical appraisal might include the word late. I'm starting to think however that the terms 'on time' and 'late' are worth consideration. And maybe, if enough consideration is given to the subject perhaps there might be something genuinely novel and interesting to conclude about the nature of projects generally, the frailty of current management approaches and what can be done about it.

There's an interesting blog post here that I read sometime ago - you should read it but in absolute summary - there's no such thing as slipping dates, just bad forecasts. I remember this really making an impression with me when I read it. I don't just think its a good point, I think its a potent entry point to a much richer discussion.

A while back I prattled on about an idealised constant 'K', which represented all the work that was required to be done to complete your project assuming no waste. I've re-rendered the drawing below.

There's some simplification here. There's no discussion of change requests, procedural acumen or PMO statistics for this sort of project run in your organisation but broadly;

Work that needs to be done to complete your project is K
Work that you identify to be undertaken for your project is Kb
Magnitude of error in plans is K - (k2) + (k1).

k2 is interesting as you may or may not end up doing it and to some extent it cancels out k1 which you'll always have to do.

What's our list of variables then? Things that might influence k1 & k2. I suggest the following

1. Preliminary planning fails to identify accurate the work that needs to be undertaken or the time it will take to complete it.
2. Failure to accurately identify dependency relationships, leads and lags
3. Blunders, poor forecasting and re-work
4. A change budget (£/$) but no corresponding schedule allowance
5. HR Management issues (absence, incompetence and ineptitude)
6. Failure to manage complexity
7. Criminal or unlawful activity
8. Acts of nature

Of the 8 points above, I would suggest that item 1 is far and away the most significant. Some other time I might take the time to blog on the predilection of homo sapiens to focus on outliers at the same time as dismissing the significant but for the time-being I think I'll simply focus on items 1, 2 & 3 above.

Let's take a moment to summarise and take stock. Project delivery consistently moves to the right (perhaps systematically so) and there is (I suggest) some consistent harbingers of this movement. Interesting this isn't it? We've got a consistent output (delays and destabilisation of the project schedule), consistent inputs (I'll continue to subscribe to points 1-3 above - other views almost certainly exist). Shouldn't this mean we can do something to quantify and assess the potential impact to our projects?

There's a little bit of overlap here potentially with the schedule performance index which I mention here. But its not quite the same animal. Firstly, you've actually got to implement some rudimentary earned value management and (somewhat shockingly) almost no one ever does. But it will only help you so much as it will only use a sample of work done so far rather than a more useful measure the project in its entirety. This means you'll get increasingly good data as your project progresses but at the outset, it'll be highly unreliable.

At this point, I feel I want to talk about cooking for a while. 

Cookbooks are full of recipes. They describe the ingredients and implements required, the steps, temperatures and techniques to use and usually describe the output. They do this consistently well otherwise people wouldn't buy them.

If you follow the instructions and you have a little culinary acumen you can have a high level of confidence that what is delivered will be edible. Delicious even. If however, you use second rate ingredients, rush the prep, burn the food and respond to a late request to remove the anchovies, there's significantly less chance that what you deliver will be fit for purpose or on time.

Cookbooks are a good illustration of our idealised constant 'K' that I mentioned above. They do have the advantage however that a) they're not a unique undertaking and b) almost universally they'll have been reworked and rehearsed perhaps over several generations. So, they're not projects are they. But they do highlight the importance of knowing everything there is to know at the outset and what the benefits of knowing everything are.

Continuing on our epicurean line for a spell longer. If we removed some of the ingredients and steps from a recipe we'd be doing something to model in abstract the deficiencies in planning to which many projects (all?) find themselves prone. Would we be able to identify the omissions? What could we do with them if we did identify them?

We'll, there's one sure way of identifying that there are omissions (as opposed to what they are) and that's cook the dish. I don't think its too much of a stretch to suggest that any omissions could be identified and quantified. So what's the benefit of investing this time and effort? What can we do with the information we're now in possession of?

Can we extrapolate anything about the remainder of recipes in the cookbook (project)? Can we play any discrepancies across the remainder of the project? Well, maybe. Omissions from the fish section might not be applicable to the dessert section and should you take your cookbook to your aunt's for Sunday roast, all bets might be off when comparisons are made with cooking in your own kitchen. This is where the schedule performance index (and cost performance index) fall short for our purpose here - they focus exclusively on the sample of work that has been done, not a proportionate sample of the whole piece.

What I am tilting at here is that if we cook a few recipes up front we'll be better able to assess the cookbook in its entirety. The more recipes we test (the greater the sampling) the better picture we'll develop of the overall scheduling, scope and procedural quality.

So what next? I'll seek to elaborate the points above and answer the following questions.

1. When is this sort of critical appraisal essential as opposed to desirable or superfluous?
2. What could the job of analysis of a project scope / schedule entail?
3. What could the output be used for?
4. Who would do it? When? And for what purpose?

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 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.

Sewing up a few lose ends and knitting it all together

Time to wrap up (for now at least) on the WBS and allied products.


I mentioned that sometimes there was a lot of work and not much product. If you need better control around this or simply better control period then I enclose a work package template here.


The first half is pretty much Prince 2 all the way. The second half incorporates specific test management activities intended to root out defects.


Two interesting points about work packages - sometimes resource pools really respond well to them. They can definitely accelerate delivery. Secondly, if you ask for written checkpoint reports from assigned resources you can rely on finding out problems after they've happened. If you take the time to verbally engage with the assigned resources you might be lucky to catch sight of problems before they occur.


Next I include a small but useful resource which is distilled from the WBS (which we have talked about) and the project plan (which we haven't) which nicely sows up all the delivery dates for all the products. 


For ease of administration I recommend including the WBS dictionary, the product descriptions and the product handover log on different work sheets in the same work book. I've never done anything clever with this using SharePoint / Excel Web Services but doubtless they'd be some value in exploring this.


I'm a bit cautious with the illustration below but felt it was worth including even in its slightly flawed state. The PBS is a bit nomadic, and there are one or two abstractions too far. But I think there's more right with it than wrong so I include it here and welcome suggestions for how it can be neatened up a bit.

There's a heck of a lot more worth exploring, both central to the illustration above (testing, estimating, tracking and controlling progress) and peripheral (benefits management, value management, business case writing) to name but a few. But, that's all for another post on another day.

Taking the WBS forward towards a project plan

In my last post, I talked at some length about the work breakdown structure as a foundation for all that was to follow. I summarised some points worth noting when creating and manipulating work breakdown structures. One of the limitations of a WBS is that it can't incorporate that much detail. And for some of the WBS elements, you're going to want a lot of detail.

I'll come on to how much detail and for what purpose shortly. In the meantime, l include the following table which supplements the WBS elements with more detail and specifies the product descriptions which correspond to any given WBS element.

Most of the fields are self explanatory and most come from Prince 2. There are things which Prince does very well - this is one of them.


One or two things aren't self-explanatory. BCWS stands for budgeted cost of work scheduled and this is beyond the scope of this post. It's a component of earned value management for those sufficiently interested. The CAM is the Control Account Manager and while this terminology is fairly specific to aspects of earned value management, you'll discern that this is the person(s) who is accountable for the product's delivery and ensuring it meets requirements.


All the WBS elements should incorporate version control. The related products descriptions relate to specific products that will be produced during the execution of this work. The nomenclature is deliberately 'transparent' and it should be readily apparent from any product reference what the corresponding WBS element is. The schema of the product descriptions is larger and will be the subject of a subsequent post. You should note that if the WBS element doesn't output a product, there won't be a product description and this might be as far as you elaborate.


You can download the specimen template shown above here

The start and finish dates are fed back into the WBS dictionary when you've completed the scheduling work in the project plan.


A few points on the subject of detail and how to assess how much of it you need to have.

1. Is your project intolerant around costs? Schedule? Quality? All three? This should inform the level of detail where appropriate
2. Is the work novel or contentious. Has reference to corporate or programme lessons learned resource indicated anything about which you should be wary?
3. Are you expecting lots of change around the specific element of the WBS or resulting products?
4. Is product acceptance a particular concern?
5. Is this a new supplier or one with whom there is little prior precedent?

That's a few points to be considering when assessing the degree of detail that should correspond to a particular WBS element or its related product descriptions. 

Incidentally, at this point I've still not covered where a really helpful narrative can (and should) be included. In my last post, I included an illustration of the WBS. When publishing the WBS, I always include an accompanying table with some supporting information about what a specific element of the WBS actually encompasses.

I include an illustration below of what I usually include with the WBS.

And you can download the template here


I'll deal with the product descriptions next and then we'll be in the business of assembling our project plan.

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.

Championing document management and document quality, part 1

Consider the idealised world in which work is undertaken to a high standard with a minimum requirement for supervision by the project manager, where project communications are well managed and self-sustaining, where product handover is almost a formality, where all project stakeholders can independently source the correct information they need, when they need it with little need for involvement from the project team, where all project resources are enabled to work independently towards the management of risk and quality. Consider a world of high performing project teams and projects which take on some of the characteristics of a repeating cyclical process and where project managers can manage by exception. Sound too good to be true? I don't think it is.

I'm going to return to this theme of "projects as BAU" (business as usual) in the coming weeks, but I'm going to start with what I consider to be the single biggest step that an organisation can take towards a more stable footing for its project activities, namely high quality documentation supported by high quality document management.

I'm going to take another look at the points in paragraph 1.

• High standard of work, undertaken independently - enabled by the authoring of high quality work packages, peer reviewed and agreed with the named project resources who are to do the work. The work package's deliverables should be detailed, reviewed and approved product descriptions which relate back to the WBS. The approach to quality should be stated clearly
• Project communications which are well managed and self-sustaining - enabled by a collaborative approach to the generation, publication and sharing of high quality project products (PID, Brief, Communications Plan, Configuration Management Plan etc). Usually there isn't the time to spend on these products that they demand because everyone is too busy managing email. This in turn is because they don't have high quality project products published to say, SharePoint.
• Product handover is a formality - enabled by detailed, reviewed and approved product descriptions and a rigorous approach to quality (V-Model for instance)
• Where project stakeholders can independently source the information they need - enabled by getting out of email, getting into documentation and publishing in a collaborative platform (SharePoint, SameTime, Exchange Public folders, or your own document management platform)
• Project resources enabled to work independently towards the management of risk and quality - enabled through project resources accessing and sharing information about all aspects of the project - they're not just compelled to raise a risk or an off-specification. They can actively manage, own and control outcomes because they're equipped with the knowledge to do so
• Taking on the characteristics of repeating cyclical processes - almost every project will have some repeating cyclical processes, whether it's moving servers between data centres, packaging applications or designing web applications. Assess whether a process will add value*. If it will, work with all parties involved to generate a process which is shared, owned and understood. It doesn't necessarily need to be perfect, that will come later.

* I'll post something on this in due course.

I don't offer this without the benefit of seeing both sides of the fence and also the consistent and tangible improvements resulting from transitioning from one state to the other.

I'm not going to belabour the matter too much here  although  there are some perspectives relating to proportionality which I'll pick up another time. I think the points above are self-evident. I hope you do too.

If you want more information generally and a bit of structure you might try this from JoAnn Hackos

Requirements, testing and quality

I'm a big fan of testing, test methodologies and approaches. It's a fantastically rich and mature discipline and offers a lot to the project manager. I think the value of a project manager will almost certainly be amplified by even the most rudimentary knowledge of the discipline.


One approach I've become comfortable with is illustrated below.

Here's a link to a read only Google Doc of the illustration. Please help yourself. Here's a link to an editable version - if you can come up with something you think is better or interesting, please amend it as you see fit. If you do edit it, add some comments to the blog explaining your rationale. 


I'm only going to touch on each component briefly now. In practice, with the exception of the quality log, the components are in themselves substantial topics. But I intend to make this something of a recurrent theme and I'll try and support the process with a few useful resources along the way.


Hopefully, most of the elements illustrated are reasonably clear. Requirements, a big topic in itself, will almost certainly be the starting point for the majority of projects. I'll come back to the quality risk analysis (QRA) later. Development and implementation are condensed - they're not my focus here. We undertake testing* and either verify a requirement has been met, recording this in the quality log or find that it hasn't been met and raise a defect. 

*In practice, testing is an ongoing activity throughout the project life-cycle, but for my purposes here, it is illustrated it as a single element.

In practice, the quality log might seem a superfluous overhead. It can however prove to be quite a useful document, illustrating what has been achieved. By comparison, the defect log which, on its own, can paint a picture that isn't wholly representative.


The quality risk analysis was something I came across in Rex Black's book, Critical Testing Processes. Equally, he covers it in reasonable detail here. I include the abstract below.


Testing any real-world system is potentially an infinite task. Of this infinite set of possible tests, test managers need to focus on the most significant risks to system quality. These are the potential failures that are likely to occur in real-world use or would cost a lot if they did occur. This article describes practical ways to analyze the risk to system quality, providing guidance along the way to achieving effective and efficient testing.


I'll return to the topic of quality risk analysis and include a useful resource to support its use in due course. However, it would seem an opportune time to leave you with a very succinct and almost universal definition of quality namely; meets requirements, fit for purpose.