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.

The Great Wall of China, governance and my sock drawer

Went to a talk by Geoff Reiss tonight - author of, amongst other things, Project Management Demystified (I own a copy - recommended).

All sorts of interesting points cropped up and I thought to relate a few here. The talk was entitled "Great and Deadly Projects". Geoff it turns out has a considerable interest in singular projects undertaken across the millennia (The Great Pyramids and The Great Wall of China) to name a couple.

The Panama Canal which was undertaken in 1911 for instance (great) thought to have had 30,000 fatalities (deadly) was noteworthy. The question of whether in 2011 there were the 30,000 projects with <1 fatality begs an answer.

A well intentioned attendee suggested that there was a clearly a case of better governance. Some wag in the audience responded that this would simply have led to more accurate record keeping of the casualties.

This last is a prompt that I must set pen to paper on the topic of governance. Mind you I must first acknowledge the dilemma that if you asked 10 PMs what governance was you'd get 11 different answers. Can the governance specialists do better?

Thank goodness too that Geoff Reiss fielded something that's been on my mind for quite some time now, namely that the truly great projects were very lucky.

There's a lengthy post in its own right here but I'll aim to unsettle you bit right now. Let's set the scene a bit on the topic of risk. (I have to do this because the nomenclature used on the subject within the spectrum of project management is inconsistent and imprecise). And that's twice I've been hindered by terminology in one blog post.

First, what's risk? Something bad that may happen? Maybe. Let's say that risk management is the job of reducing the likelihood of something bad happening and reducing the impact if it does happen. So if you can't assess the likelihood of something or what the impact could be - is it a risk?

Building on this is the assertion that if the something bad that may happen is a) subject to probabalistic.distribution and b) has a known consequence / impact then it is a risk. I've been racking my brains for the perfect illustrative vehicle for this and the best I could come up with is my sock drawer. More on this in another post, but for now, if its not a risk what is it? I suggest you're standing at the yawning abyss of mathematical uncertainty. The problem is  that almost everything you read about risk will incorporate the word uncertainly. 

Something else rather interesting arose on the topic of communications today too. While bemoaning dwindling levels of interest and low rates or response to communications initiatives a fellow project professional bemoaned that stakeholders were only reporting positively via surveys about their experiences. The noteworthy point in this is that those stakeholders who were still attending sessions were feeding back positively. No channel of communication existed with stakeholders who'd left for greener pastures. I don't quite know what the communications parlance is for talking to people to who are talking to you any more, but in its absence you might try 'friendly consultation'.

Note to self - must write to Francis Maude and ask why isn't Earned Value Management mandated in public sector projects.

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.

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.

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