Thursday, June 28, 2012

Conundrums in communications (part 1)

I have a bit of a love hate relationship with communications. They can suck up resource, they're fiendishly difficult to get right (I sometimes even wonder what 'right' even means) and I can't be alone in having been burnt on one or two occasions by a nanosecond's lapse in concentration on the topic. 


Conversely, they give the project team an opportunity to raise their profile, to champion their aims and objectives and, done right, they can be one of the more satisfying aspects of the job.


Here's a few headline manholes.

  1. You might saturate communication channels
  2. Someone else might saturate communication channels 
  3. Your stakeholders 'lose sight' of the communication plan
  4. Your stakeholders actually tell you they should have read the communications, but they're sorry they didn't and now they're in a bit of a mess
  5. You've racked your brains but you can't work out a way to ascertain whether or not your stakeholders have read, retained and understood your communications.
  6. You're facing universal stakeholder apathy (this is on a sliding scale from mildly disinterested to venomous mischief making)
At this point I could espouse the virtues of a carefully crafted communications plan or stakeholder engagement plan. But I'm not going to and here's why. If you're fortunate enough to have specialist communications input, or even just a chunk of resource to throw at communications you can spend all the time in the world on soft market research, repositioning key stakeholder groups and deciding the precise colour scheme to use across the breadth of your media interfaces. So not only will you have time and money to develop specific purpose built documents and strategies, you'll be able to underwrite the resources for them, manage them and (one assumes) see them through to a successful conclusion.

Meanwhile, back in the real world, you've fought like a tiger for the limited resource you've got, your fingers are bleeding from back to back authoring of the business case, mandate project brief, project initiation document, configuration management plan WBS and product descriptions and the sponsor is wondering when you're going to start delivering something. So you make a note somewhere that the communications plan will be included in the RAM on stage 3 of the project (or something similarly vague).

This all said, you might find yourself facing problems 1-6 inclusive, or some uniquely quirky issue particular to your project and needing a bit of communication lubrication. Below I include my suitably pragmatic salve to the issues above.

You have saturated your communication channels

The symptoms

Communications have become less effective, stakeholders are grumbling, you hear the words '...not another project blah email...' in the lift, Paradoxically, because people are starting to disregard your communications you have to send out even more. People are setting up email rules to junk your mail.

The cause

You've overcooked it. You might even simply be following the communications plan (that needs an update by the way).  You've got no temperature check or feedback loop in your communications so you keep on spamming the entire stakeholder pool whenever you feel slightly anxious that your message might be getting lost in the corporate soup.

The solution

Prevention is better than cure. You need to recruit communications stooges (confederates in the stakeholder pool or business) who will primarily assess your communications from the receiver end of the equation as well as being your eyes and ears in those environments. If you've missed the prevention boat, take a two week communications holiday while you recruit your stooges - that should kill two birds with one stone.

Someone else has saturated your communications channels

The symptoms

Broadly the same as before. You have the satisfaction of knowing that you are not directly responsible for the blunder, but the annoyance that you will have to directly fix it.

The cause

Could be a lot of things but two spring to mind which I cite specifically because you'll approach the matter differently.
  1. Poor email etiquette from co-workers. You're getting a lot of reply alls on emails or, other, similar blanket channels of communication are springing up. You're not managing them (in fact no one is), messages are getting garbled and coherence lost.
  2. Someone in the customer's organisation, the stakeholder pool or simply someone you need to do business with is suddenly and deliberate fielding a great deal of communications, most of which is making your day a good deal harder than it needs to be.
The solution

In the first case, you're going to need to get that someone some feedback on email etiquette or simply the fact that communications for project blah start and end with the project team. That'll probably get you fixed.

The second case is a bit more of a curve ball and is correspondingly a little tougher to fix. Remember the communications plan we were going to right in stage 3? You need to get that thing written promptly. Don't kick yourself - having it earlier wouldn't have done you any good. 

You're going to need to define your communications interfaces, media, authorised and approved communications providers and get the plan approved by your project board. You will of course ensure that you've specifically outlawed stakeholders exploiting project communications channels to prosecute their own agendas and you'll also include that breaches of the communications plan will result in a project issue being raised to the board.

I can't promise you this is the panacea to every stakeholder that decided their views superseded those of the project board or sponsor - but this does tend to either quiesce over active stakeholder communications or, in the event it does not, reduces your exposure as PM to the problem as you've got some structure and a readily available channel of escalation.

I'll see off the remainder in the next post. If anyone has any communications issues not listed, do add a comment - I can't promise to have an answer, but my readership is almost into double figures - we'll crowd source an answer!


Wednesday, June 27, 2012

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.



Tuesday, June 26, 2012

Defining the output via product descriptions

This post and other recent posts relate to one approach to progressively distilling the voice of the customer into project plan.


It shouldn't be adopted in a vacuum and other posts here on quality and requirements are important as is (doubtless) a world of detail specific to your particular ecosystem.


I have focussed in detail on the WBS (3) though elaboration of the WBS itself, a useful supporting narrative for the WBS and the WBS dictionary. This post will look at product descriptions and touch a little on the composition of work packages.


The schema for the product descriptions is quite large so I've transposed it as shown below. Again, it's Prince 2 aligned and you can download the template here.


  1. Identifier- needs to be unique and should be traceable to the corresponding WBS element
  2. Title - something meaningful
  3. Purpose - Important. Be accurate, succinct and clear - what's this product for?
  4. Composition - What's in it? If it's a document, you might describe the particular section headings
  5. Derivation - how will this be derived or what from? 
  6. Format and presentation - speaks for itself
  7. Development skill required - if you need a rocket scientist, here's where to state you case
  8. Quality criteria - how will the product's fitness for purpose be measured or ascertained
  9. Quality tolerance - and how much can it deviate
  10. Quality method - how will it be checked (review, inspection, external audit?)
  11. Quality skills required - anything specific? Subject matter expertise, certification or other.
  12. Quality responsibilities - who's head is on the block?
  13. Status - draft, approved, completed, late and so on and so fourth.

There's probably more detail than is needed for most products and that's fine. Understandably, you're not likely to add additional columns just because you come across a specific product for which you wish to define additional detail. So include all the fields but leave them blank where appropriate. The additional structure can serve as a useful handrail for reviewers.



Those of you with keen analytical eye might have observed a discrepancy. All this work to elaborate and specify detail corresponding to products - fine. What about for all the work for which there isn't a product or for which there is a disproportionate amount of time / money committed for the given product? Where do we instate the control necessary to govern the activity? The answer is in a formal documented 'work package'. I have some views on this so will hold off going into too much detail and make it the topic of a future subject specific post. I'll include a template and some particular content around testing which adds value.


In summary then. A while back I looked at the following abstraction and talked quite a bit about 'achieving quality' and defined quality as 'meets requirements, fit for purpose.


I laboured (but didn't finish) requirements and requirements management, talked in detail about the quality risk assessment and just touched incidentally on defect management and the quality log. (By the way, my quality log is the opposite of the defect log - i.e. it records stuff that's okay as opposed to defective. This is distinct to the Prince 2 quality register which records 'quality activities'. Technically you don't need a quality log, but it can be quite a bleak experience going into project board meetings with a defect log and nothing to illustrate the more positive end of the equation).


This post and the last few posts have dealt in the development and implementation space. Taking the customer's vision, I generate a WBS and an accompanying narrative and get it reviewed and signed-off. I then elaborate the WBS into a WBS dictionary and identify any products. Where products are identified, they are elaborated via product descriptions. Note too that work packages play a part in controlling work without obvious products or for which the cost was disproportionate in comparison to the output. For the WBS elements with products we can probably take items straight off the QRA and apply them to the product descriptions as appropriate.





Saturday, June 23, 2012

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.




WBS as foundation

In my last post I said I couldn't add much to the existing breadth of knowledge on work breakdown structures (WBS) or the product based equivalent the product break down structure (PBS). And, I can't. However, I don't want to preclude any potential readers who may not be familiar with the technique. I can pull out a few points worth re-noting and, simply because it's so important a component of the overall planning process, it won't hurt if we all start from the same place.

One of the things that makes the WBS so likeable is that it's very simple, readily comprehensible and consequently, rarely needs much by way of explanation. The product breakdown structure is an excellent tool of communication to illustrate a project's scope. The work breakdown structure is a slightly more focussed tool, but nevertheless is a great way of engaging with resource brokers.





Here's a few of the things I keep in mind when constructing a work breakdown structure.


1. Proportionality - I decompose elements of the WBS to a level that 'makes sense'. This is often informed by early assessments of the volume of work and who's going to do it.

  • Estimating is more accurate when work is broken down into small chunks. 6 separate work breakdown structure elements of 3 or so days each tends to be more reliable than one of 18 days.
  • There's some logic in breaking tasks down to a level of work that can be completed by one person only - this has some benefits when manipulating and scheduling the project plan in software
  • Resource brokering - ideally, I'd like each element of the WBS to be undertaken by resources brokered through a single individual. Or to put it another way, I want to go and see one team leader about a job, not two or more. The resource brokers are likely to be happier about this too as it reduces constraints in resource planning.
2. Manageability and maintainability - I usually create the WBS in MS Word - there's a couple of hierarchical structures in the SmartArt feature that lend themselves quite well to the creation and maintenance of the WBS. I find the 'Organisational Chart' works well. Microsoft tend to pick and choose which features they include in any given version of a piece of software - I use MS Office Professional Plus 2010 - other versions may differ. If they get really big then you could use some like MindJet's MindManager, but there are some practical points to be born in mind. The WBS above was created in Google Docs.
  • You do want to be able to produce this on a single page (whatever it's size) - a multi-page WBS is probably more like multiple WBSs
  • If it's getting unavoidably big, you lose some of the benefits such as the WBS being a readily comprehensible tool of communication
  • The bigger the WBS the more likely errors will creep in
  • I find a three tier WBS works quite well for most of my work and if things are getting beyond that then I tend to segment the work into more manageable stages.
  • If you've got, by necessity, a very large WBS under constant edit and amendment by multiple parties, you're going to need a different tool - they do exist.
3. A requisite level of detail - while there is a little bit or wriggle room, if work needs to be done and resource needs to be brokered it must be on the WBS
  • There is an obvious conflict here in terms of keeping the WBS simple enough to work with. This is readily managed by taking the WBS elements within the WBS and elaborating them further in other products (more on this in another post) but so long as we have a WBS element with a unique identifier - we can (and do) expand this elsewhere.
  • Certain things don't go in the WBS. These mostly relate to work that generally comes under the heading 'Level of Effort' or LOE or the effort relating to project management processes themselves.
  • In my illustration, I've included quality activities (the snagging and building control sign-off) this is a good way of seeding quality through-out the activities and illustrating this to all parties early on. 
  • I've also included certain activities like estimating and make or buy decisions
4. And generally - the following can be helpful to keep in mind
  • Generally speaking, left to right and top to bottom reflect the chronological sequence of events. This isn't critical, but can just assist the overall readability
  • I haven't identified a reason why the elements need unique titles - happy to hear otherwise, but you must have a unique identifier
  • Avoid trying to incorporate too much detail at this juncture (dependencies, resourcing and scheduling) this isn't the tool for the job
  • Peer review is vital - you're unlikely to be a subject matter expert across the whole WBS - get the appropriate individuals to formally review and approve specific parts of the WBS - you must be on a firm, consensus led footing when this activity is finished.
The next few posts will take the WBS above and supplement it with additional detail to make it a self-contained resource. We'll start to look at the WBS dictionary and product descriptions too. 


Breaking it down and getting it done

Somewhere in my many posts related to this must be the observation that the business of getting on an delivering anything has, thus far, been conspicuously absent. 


First, don't go looking too hard for activities related to delivery in the 'achieving quality' model. That's an abstraction focussed around meeting customer requirements. But then again - don't lose sight of that while getting on with the business of delivery.




Next, don't necessarily follow the steps above verbatim. You're almost certainly going to have to maintain a flexible footing, responding to the particular business needs you're facing. I'll offer this isn't a bad starting point however.



[If you want more detail on product or work breakdown structures see any number of other sources elsewhere. I can't add anything to the existing breadth of coverage.]


Step one above isn't something I'm going to dwell on too much at this point. Somewhere in the project mandate, brief, charter, PID, business case you'd better make sure there's a crystal clear vision of what the customer wants. If not, you'll need to lift whichever drains you have to in order to get that unequivocal vision of what is to be produced. 


I can think of one or two exceptions, but mostly the (PBS) should pretty much always come before the work breakdown structure (WBS). Define what you're going to do, then how you're going to do it. Scope definition can be a (very) big job in itself and if this is a self-contained stage in its own right, then you might have a WBS for which the output is a clear definition of scope (the PBS).


Be it PBS, WBS or any other type of work breakdown structure, the objective is 'compartmentalisation'.


The project plan is easily derived from the WBS. In fact, if you're using software to do your project planning (and you almost certainly are) then if you have the WBS, the project plan will almost write itself. The only substantive information you'll need to add are dependencies and lags (where applicable).


If you adopt this approach, i.e.WBS then the project plan, I'm convinced you'll rarely deviate. It has a number of advantages around scope definition, change control and taking some of the effort for the creation of the project plan away from the project planner. Conversely, I'm not convinced you can derive a complete WBS from the project plan, and developing the two in tandem is best avoided.


Finally, once you've got your project plan, you should be at the point where you can generate your resource plan. And, in fact, your project planning software will almost certainly do this for you.


There's quite a bit more ground to cover on this, specifically relating to 'progressive elaboration' to the appropriate level of detail. This will be the subject of future posts and will deal specifically with the WBS, the WBS dictionary, product descriptions and the generation of specific work packages. They'll be plenty of templates to get you started and save you time too.

















Tuesday, June 12, 2012

Quality is a risky business


In former posts I referred to something called the Quality Risk Assessment or QRA.

Before elaborating further, I have to cite this as the work of another author – Rex Black who is a luminary in the world of testing.

You can read about the QRA (and more besides) in Rex’s own words here*. Equally, you can buy this book.

I include a link here to a copy I’ve tucked away for safe keeping just in case – but hopefully the link above remains sound.

My interest in the QRA approach arose from the following observations

1.    I needed a systematic way of apportioning test resources to a potentially infinite task
2.    I’d made efforts with Failure Mode Effect Analysis (FMEA) but it was too resource intensive for my purposes
3.    I needed an additional offering for stakeholders so that they could see their concerns were being prioritised and addressed
4.    I wanted to maximise resources in the areas of greatest concern
5.    I wanted to do as much work up front to de-risk implementation and release activities.

It was while reading generally around the subject of testing that I came across the quality risk assessment and realised this was the tool for the job.

I include a screen shot here and a link to a specimen spread sheet here which you can help yourself to. I’ve hastily entered some specimen data for illustrative purposes.



The screen shot here only goes so far. I’ve got a few formulas to prioritise the risk categories, some charting (not sure it adds anything but certainly looks nice). The work sheet can undoubtedly be taken further and if anyone has any bright ideas, please make yourselves known. (Bubble chart of risks or a top 10 list of highest RPNs anyone?).

I’ve used data validation to constrain the severity, priority and likelihood fields to values of 1-5. I use the following definitions, but you can use what works for you.


Severity
Priority
Likelihood
1
Loss of data
Urgent
Very likely
2
Loss of functionality
Essential
Likely
3
Loss of functionality (with work around)
Valuable
Possible
4
Partial loss of functionality
Desirable
Unlikely
5
Cosmetic error
Discretionary
Very likely

Looking back at the conceptual model I proposed a while back, we can see that we’ve covered quite a bit of ground on requirements gathering (with plenty more to go), this post with the additional links should give you a solid insight into the application and use of a quality risk assessment.

I recommend having the QRA up your sleeve. If you need a tool which is widely applicable, prioritises resources and is comprehensible to a range of stakeholders, I contend there are few better tools.

Thursday, June 7, 2012

Fail less with project management

I can understand a certain cynicism towards project management and project managers. The oft quoted figures suggest that 70-80% of projects fail.

When conversations on this topic arise, I often recall the interesting observation of a former colleague. “All projects fail and all projects succeed. Just to varying extents”.

I’ve recently moved house. A house move has stakeholders, communications interfaces, regulatory compliance, requests for change, a deadline and more besides. So while not exactly a project, it’s quite a bit like a project.

The management of stakeholders, risk, communications and expectations was abysmal. Relationships were strained, costs were incurred, dates slipped and compromised had to made. In short, it was a mismanaged fiasco. But, at the end of it, all parties are comfortably installed in their new houses and the matter is quickly receding into the past tense.

At which point, it’s opportune to recall some admittedly slightly facetious words from the aviation industry. “Any landing you can walk away from is a good one”. As succinct and easily endorsed a critical success factor as I know of.

So are our expectations too high? Are we asking too much from projects? Should we adopt the perspective of our colleagues in aviation? My house move above was doubtless a failure by any yardstick of project management but needless to say a tick in the estate agent’s monthly figures.

Projects that I have visibility of mostly achieve their objectives, sometimes the scope might get whittled away a little, sometime deadlines slip and, often, costs rise. But then a forecast schedule isn’t a deadline and a cost estimate isn’t a budget is it? Project managers, their colleagues and PMOs will try and estimate, forecast and adapt to changing circumstances as best they can. If there’s a headwind, then they may burn a bit more fuel and take a bit longer, but so long as we get the aircraft back on the ground in the general vicinity of the intended destination, that is success by one yardstick at least.