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.

Good things come in threes...

There are certain topics that I've historically given a wide berth to. Project governance is one of them. It's too easy a target, too contentious and every one has an opinion on the matter. Here's mine.

One of the things that's constrained having any sort of consistent dialogue / vehicle / entry point (delete as appropriate) via which governance is (or ever could be) dealt with in projects (and programmes) is the lack of a unified consensus.

Well, you ask, what does that mean? Good question. If you asked 10 project managers what do they understand to be implicit in the term project governance you will (I hazard) elicit a variance in the responses that is extremely difficult to unify. You could even swim into less certain waters still by asking "What are the hallmarks of a well governed project by comparison to a poorly governed project". Could anyone be confident of any kind of spontaneous consensus?

The splenetic Steve Jenner (who will I hope overlook any referencing of his words in deference to my describing him as splenetic) offered that "...governance is the job of defining what decisions are made, by whom, when and to what criteria...". I remember feeling a sense of overwhelming gratitude to Steve for having (I felt) pinned the tail onto the donkey quite so precisely, succinctly and without apparent contentiousness.

But then, you've also got corporate governance, IT governance, data governance and quite a bit more besides.

...and that's just the different areas of governance. There are different approaches to governance such as collaborative or multi-stakeholder. And then of course there's applying both the required area of governance (say Project Governance) to (say) an IT Project in (for instance) a multi-organisational project. Oh, and just in case that wasn't enough - how about meta-governance - the governing of governance. (I do yearn for a bit of this now and again mind you).

Incidentally - just in case you were about to yawn and look for your entertainment elsewhere since this wasn't a terribly interesting topic, consider for a minute a project in which the wrong decisions are made, by the wrong people, at the wrong time and to the wrong criteria. Does this sound a bit more engaging now?

Like any project manager faced with unmanageable levels of complexity I revert to the mental state of a 3 year old, effect a brief but meaningful inner tantrum and cling to the mantra - surely there is a simple way of ensuring that tomorrow is better than today.

...and of course, there is.

Simple step one to improving governance today

Documented process is an enabler (dependency?) for improving governance. So, in the very simple situation below we have an input, a decision and two possible outcomes. We have a decision point, some inputs (criteria) and presumably a forum or framework in which that decision will be made. Sounds a bit like we're half-way to something Steve Jenner might just suffer to include under the heading of governance.

Simple step two to improving governance today

Create a register of all the formal documentation to be produced during the course of your project / programme. Include information about who is going to produce it, who is going to review it, who is going to sign if off and who is going to own it going forward. And, any schedule information for when this documentation will be created. Publish this register to appropriate stakeholders (and in many instances this will simply be all of them).

This resource, at a glance, allows a range of stakeholders to discern what documentation is to be produced (and what documentation isn't), by whom, when and who is (and isn't) involved in review and sign-off.

Simple step three to improving governance today

Create and publish a product breakdown structure (PBS). Derive from this appropriately detailed product descriptions and keep these someplace useful (say a product dictionary - a.k.a. an Excel worksheet. This is very much the same carry on for step two (which applies specifically to documentation) but in this case we're looking at specific project deliverables (which may or may not be documents).

This resource, at a glance, allows a range of stakeholders to discern what products are to be produced (and what products aren't), by whom, when and who is (and isn't) involved in review and sign-off.

And that will do won't it? No expensive management consultants. No particular undue stresses and strains. Not even a requirement for the oversight of assurance satsumas mandarins - just a bit of practical elbow grease.





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.

Forecasting - part four

Ironically in my first post on forecasting I cited the following points which I would aim to cover.

1. Parametric or reference class forecasting
2. Guessing, uncertainty and pragmatism
3. Never mind 6 Sigma - 1 will do you quite nicely
4. The PM's job in fighting for exactitude and rigour in the planning process
5. Some helpful language and strategies to challenge sub-standard practice
6. Some real life scenarios and tools consistent with other articles in this blog that I hope will add a bit of value

And here we are on the fourth post on the topic and I think I still have pretty much the lot still to get through. Something relevant to the topic of forecasting in their somewhere methinks.

Let's hustle on a bit. 

Parametric or reference case forecasting is simply the process of using historical events to inform forecasting. Let's go back to our example of changing a car tyre. I discussed some useful stratagems on getting to a more accurate forecast, but ultimately you can't beat having changed a tyre yesterday to inform a useful forecast on how long it might take today.

Guessing? Don't do it. If you don't know how long something is going to take, set a duration on your project plan and commit to using a schedule performance index to track progress and assign more (or less resources as appropriate). Or, some other similarly pragmatic approach.

Standard deviation isn't something we've talked about before and I think it would be worth keeping this back for a specific post. (That's the point on 6 Sigma / 1 Sigma above). What I think I will do for the remainder of this post is focus on point 5 above.

There are undoubtedly a great many opportunities for the activity of forecasting to fail. I'm going to describe a few ways that (I've seen) project delivery deviate wildly from the forecast and then highlight some stratagems to help avoid it doing so.

Shoddy project planning - I don't know how many more project plans I'm going to have to work with that comprise 1000+ lines, rely wholly on duration based (rather than effort based) planning and (to top it all) incorporate 50%+ of hard coded dates.

I don't have the knowledge, capacity or inclination to write at any length on the topic of project planning and good practice using MS Project (or other). However, allow me to suggest that the inputs to creating a project plan include the following;

• Experienced planners who understand critical path analysis, activity on node / on arrow techniques
• Knowledgeable staff who have either been through a structured programme of learning or other activity necessary to equip them with the knowledge needed

And some general useful pointers while we're on the topic

1. The near term should be at a far greater level of detail than than the mid- or long term
2. Decompose tasks to an 'appropriate' level of detail
3. You don't have to, but project plans comprising tasks which track back to product break down structures and product descriptions tend to have a much firmer foundation
4. Supplement your forecasting with appropriate controls so that if you're wandering off schedule, your have good information early
5. Make sure public holidays and staff leave are configured within your resource planning
6. Agree up front what the resource capacity is (70%-90% - typically 80%). Never 100%.
7. Practice rigorous change control. You may (or may not) be able absorb additional tasks of less than 0.25 days effort. Make sure you have a mechanism to manage anything that exceeds what you can comfortably accommodate.
8. Building (clandestine) budget contingency into business cases and budget forecasts is wrong (and can be fraudulent). However, I'm pragmatically fairly well disposed to building in a degree of flexibility / contingency into forecast schedules. You'll be able to cope with a greater degree of unforeseen events and I've yet to find a client who complains when you bring something in a bit early. You'll also be able to give the client an answer other than no when he asks if you can bring something in a bit quicker.

Supplier management issues certainly figure highly in my short list of frustrations most likely to unhinge a project plan. You're embarked upon a project and chances are, so is your supplier with all the vicissitudes to which projects in general or prone. Some points intended to enhance stability follow.

1. Don't blur the lines between dependencies. If you have a dependency for which the supplier is responsible, don't start to re-plan and re-forecast (unless absolutely necessary) when the supplier starts to slip. That's a recipe from a problem shared is a problem doubled.
2. Make sure your contract and commercials with the supplier are appropriate
3. Make sure you have the appropriate written and agreed documentation to support the supplier's statement of work and scope of supply. 
4. Verify your supplier has instated 'good practice'.

Governance or lack thereof. Get the right decision made, at the right time to the right criteria. Incidentally, it's worth mentioning IT Governance in here - this is distinct to the typical corporate and project governance insofar as it's principal objectives are maximising value and minimising risk. Technical design assurance, testing, change management and a solid approach to service transition all comprise elements of good IT governance.

A little more yet to cover on this topic generally. If I'm feeling suitably whimsical, I may relay at some future point my thoughts on the role of analogue computing to forecasting in project management (another first for PMfizz surely?)

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.

More on forecasting

Before going on too much further let's discuss a couple of real world scenarios that apply to any project plan.

You're relatively new on site, new to this particular project, or perhaps new to project management. Nothing wrong with any of those by the way.

You're of the opinion that as a project manager you should be able to tell the client where he's going to be in 3 months time (reasonable). The client is applying pressure for a project plan so he knows what the next 12 months looks like and there is a requirement to commence resource planning as soon as possible. A common enough set of circumstances. 

We can approach project planning in any number of ways, but I'm going to make a useful distinction between two approaches. In doing this I'm going to mis-use a couple of terms - who knows maybe it will catch-on and then it'll be correct use.

We can adopt a 'top-down' planning approach where we define the duration (say 12 months) and then attempt to undertake delivery of the project's scope in this time. Or, we can adopt a 'bottom-up' approach in which we define the PBS and WBS (I discuss these in previous posts), elaborate the work and resources required to deliver the work and let our project planning software tell us when the work will be finished.

For me, the imperatives that serve project sponsors and project management are conflicting, difficult to reconcile and are a re-current source of tension. It should be as simple as enshrining the approach in the PID, mandate or other documentation, but in my experience it isn't.

Let's look a bit more at the various advantages and disadvantages of the two approaches.

In theory at least, I'm all for top-down project planning. Sponsors define the durations (and I might add the scope and budget) and authorise (compel)  the delivery of the project's scope within a that duration. All sounds terribly straight-forward doesn't it? But then, I am of course reminded of the words of Commander C. Theo Vogelsang, USN “… in its relationship to strategy, logistics assumes the character of a dynamic force, without which the strategic conception is simply a paper plan.”. I don't think anyone has ever put it better than Commander Vogelsang.

A positive zoo of wise pragmatism on the subject of logistics from military theatres can be found here.

So, while we like top-down planning, we now recognise that it's not the be all and end all. 

So - let's have a look at bottom-up. We have a scope, that we're going to elaborate into a product breakdown structure, create a work-breakdown structure that will deliver the product breakdown structure and commence delivery. Well, no, you're not. You probably won't have a detailed project scope at the outset of a project, you won't have any funding to commit resources to the work necessary to deliver the WBS and PBS, let alone enter into the commercial contracts potentially required to deliver the actual work. In fact, you won't even get past funding approval.

Some readers may be falling back on a bit of real world experience at this point and envisioning that we commence project start-up with the top-down plan and successively work towards a bottom up plan and in reality that is not uncommon. However, this too has its problems as funding and cost expenditure profiles are often aligned to the top-down plan, and don't necessarily adapt well to that schedule being destabilised by something as annoying as a plan that actually reflects the work that needs to be done and the duration that it will take.

Recognising that I'm beginning to drone on interminably here, I'd better quick bring the end of this post into view.

Consider the following illustration. Hopefully this is broadly self explanatory. The only note I'll add is that (particularly in my field of technical infrastructure, there will always be an unalterable volume of work required to get a job done. Short term variances arise in the identified or forecast volume of work due to imperfections in diligence and discovery at the start and blunders during the work's execution. Below I refer to this unalterable volume of work as 'K'. 

In an ideal world, Kt is about the same as Kb which is about the same as K. in reality you never know K until you've finished your project. However, deciding on how important it is to know Kt or Kb accurately, or the acceptable variance between these and K should be decisions made with full disclosure at the outset of the project start-up. Needless to say - any decision should be data driven and the criteria that might inform this decision might include; cost, criticality, complexity and risk.

I think there's a few more interesting observations to be made for the illustration above - but I'm not going to elaborate that too much. What does it mean for your project's in your organisation?

More yet to come on forecasting.

Ubiquitous constraints (and what to do about them)

For the record, when I say constraint I mean some circumstance or factor which limits an activity, benefit or the overall success of part or all of a project. (I do like to cast my net wide with these things!)

I personally think they're a bit under-nourished in the general scheme of things. I'm not at all certain that within most projects there's a consensus on what a constraint is. There's often little or no effort to record or track constraints.

I think most projects face constraints in various forms, but there are three in particular which are almost omnipresent.

Before I go too much further, I suggest that unless you're intimately acquainted with Eliyahu M. Goldratt's theory of constraints, there's no better time than now to hop on over to Wikipedia and brush up on what I think is some pretty smart thinking about the way the world works.

All the way back in 1984, Mr. Goldratt was putting pen to paper and publishing material that included the following:

Types of (internal) constraints

• Equipment: The way equipment is currently used limits the ability of the system to produce more salable goods/services.
• People: Lack of skilled people limits the system. Mental models held by people can cause behaviour that becomes a constraint.
• Policy: A written or unwritten policy prevents the system from making more.

*Source - Wikipedia

I don't have too many unbreakable golden rules but I do take the time to reflect on these three constraints roughly speaking at the following junctures.

1. Spend approval
2. Project start-up and initiation and every subsequent stage boundary
3. All discussions relating to project change

Equipment

The effective delivery of change can be hindered by simply not having the tools for the job.

Whether this is heaving lifting machinery, the right widgets, collaborative toolsets for the project team or specialist software tools it matters not.

How to defend against deficiencies in equipment? Good planning principally. Not altogether intuitively, a detailed product description can often identify the particular equipment requirements for the delivery of a product.

The PMO too (if you have one) should be a source of lessons learned, historical data, policies and standards of its own that illuminate requirements for equipment.

Lastly, subject matter expertise is often the differentiator between getting things right the first time or slowly learning the right way through time and patience.

Your approach (as ever) should be proportionate and informed by risk.

Policy

I've seen a few of ways in which absence of policy can seriously undermine project success.

1. The output of a project isn't used due to a lack of policy
2. Resources cannot be brokered for a project due to lack of sponsorship
3. Lack of stakeholder engagement (because no one's telling them any different)

I think this is my personal favourite having been caught on all three counts at one time or another.

The really simple answer (really far too simple) is simply get a clearer than clear project mandate. I've yet to see one. The less simple and less effective answer is wrap your project's mandate up in a terms of reference (PID probably, charter or brief maybe) and get that approved, authorised and sponsored.

If you're still worried, add it to the issues log - this won't help ever so much potentially, but you will have done your job as a project manager to the degree possible.

There's a bit of an addendum to this as well. There's (certainly in the UK public sector) an increasing drive toward the management and realisation of benefits (at last!). This can help the mandate / policy quagmire as all of a sudden, staff outside the project team are likely to be accountable for the delivery of benefits and this might get you an entry point to a discussion about policy / mandate or lack thereof.


People

You could spend a lot of time discussing the various human fallibilities that can constrain a project's success. I think there are pretty much three principal headings.

• Management
• Culture
• Availability

Consider the following to assist with the management of staff assigned to projects.

Responsibility assignment matrixes are (I think) very important in most projects. Projects are temporary, unique and time-bound (aren't they?). Thus, it is not reasonable to require a team to know what is expected of them unless they're told. And, in my sometimes prescriptive and process orientated world, telling people anything important should be documented, versioned and recorded.

I like the RACI chart - there are others.

Use a skills inventory. A skills inventory is a system or tool that identifies the skills and skill levels required to deliver your project, programme, specific work packages or products. It may also specify the individuals who possess those skills. Skills inventories are most effective if they are aligned with a particular programme.

I don't think it will often be within the scope of project manager's accountabilities to influence or manage cultural change within a project or programme team. I think this is one of those situations where if the culture isn't (for instance) delivery focussed, then you'll need to adopt a suitably appropriate posture to ensure the project's objectives are still attainable.

As far as availability is concerned, I cite the following.

1. Planning is criticial, as is estimating and forecasting. If estimating and forecasting is to be worthwhile, it must be based on historical data. One of the jobs of resource planning must be to specify what is actually going to be required in terms of resource burn.
2. Sponsorship from resource brokers (see policy above). This should be two fold. First, to release the resources for the period specified at the time specified. Secondly, to deliver (as far as possilbe) the scope of work agreed to schedule, cost and quality.
3. Manage change and issues so that deviations from what is agreed is predicatable, sustainable and planned.

On another occasion, I'll upload a RACI template and skills inventory tracker to the resources page.

Something a bit fishy...

Well it's no good beating about the bush with this one. I've produced a double headed Ishikawa diagram for the purposes of illustrating causal factors corresponding to the influence and repositioning of stakeholders. I think it's fair to say no one's done that before.

So what's the point?

First, if you need to get some background on Ishikawa / fishbone diagrams, pop along to Wikipedia. They are worth having some background information on whether or not you're a convert to my eccentric approach to presentation above.

When writing my post some weeks back "Influence - a pragmatic and effective approach" I recall a sense that I hadn't quite nailed the visuals. Sometime later I had to generate a communication management strategy for a project and, when re-visiting the topic with fresh perspective, I came up with the approach above.

So, with the combined knowledge supplied by Wikipedia and my initial post, I hope you can at least intuitively grasp what I'm trying to do here. 

But why? And more to the point, why include something like this in a communication management strategy?

Well first, I think this is a good workshop approach to elicit input. You're not always going to have enough back story on a client site to generate one of these yourself, but you can provide the footpath and fill in the information as (hopefully) the client supplies it. You can also record that input and articulate it in a way that makes sense.

Incorporating it into the communications management strategy (or other similar document) has the benefit that all communications undertaken under the aegis of the project have the opportunity to be informed by themes that should assist that overall stakeholder engagement effort. Better yet, it should do that whether or not you're there to review and edit prospective communications yourself. Generate one of these Ishikawa diagrams, provide a supporting narrative in the communications policy and hopefully, you'll see helpful references and positive themes sewn throughout the project communications effort.
*Per my previous article - the credit for the better part of the approach to stakeholder influence goes to these guys.

Projects? Like poker? Surely you jest...?

If you've been around a project life-cycle a few times, you've probably stood on the periphery of some passable projects, some not so good projects, the odd biblical disaster and possibly, just possibly a success story or two.

I've often reflected on the various circumstances corresponding to success and failure and have (as doubtless we all do) a few thoughts on the matter. 

However, let's look elsewhere for inspiration other than our own personal project hurt lockers for a moment.

How do Google and Apple manage such consistent successes? What are their project manage approaches that so consistently deliver commercial success in amongst the most high risk, cut throat fields imaginable?

Well here's the thing - Google and Apple fail just as much (if not a good deal more) than us mere mortals.

So the distinction is certainly not simply one of success or failure.

I'm not going to prattle on too much at this juncture as most of this is done to death elsewhere in great detail. I can't help however draw a distinction between projects and poker however. Namely, when you lose, try and lose a little. When you win, try and win a lot.

You don't read a lot in the project management blogosphere about Prince 2 - admittedly, it can be a dryish cornerstone of what must seem to PMI / PMBOK advocates to be a project management oddity. I would even have a modicum of sympathy for the view that it is a project management methodology with no project management due to its conspicuous (and quite deliberate omission) of earned value management or anything resembling it. 

But, I will break the trend a little in the context of this post (possibly a web first to encompass poker and Prince 2 within a single blog post).

I had to put pen to paper in a professional setting recently and wrote the following. 

"Teams seeking to undertake projects via Prince 2 are challenged by constraints which often diminish the effectiveness of the Prince 2 methodology and consequently the overall success of their projects. These constraints relate to people, processes and systems. Specifically, the efforts to recruit appropriate staff, acquire Prince 2 knowledge, develop and implement appropriate policies and the subsequent execution of the Prince 2 methodology is exceptionally demanding."

And, I know what I'm talking about here having assembled a the odd 180 line responsibility assignment matrix for the purposes of administering the full suite of Prince 2 processes. And, yes, just in case you were in any doubt, that's 180 activities that that need to be undertaken in a fully compliant (admittedly non-tailored) Prince 2 compliant project that are quite independent of actually delivering anything. I'll upload this matrix to the resources page accompanying this blog in due course.

But, I remain a fan albeit with one or two provisos. Consider the following.

1. Continued business justification
2. Learn from experience
3. Defined roles and responsibilities
4. Manage by stages
5. Manage by exception
6. Focus on products

Not too shabby a list of tenets for the project manager to abide by is it? Well those six points are 6 of the 7 Prince 2 principles. The seventh is "Tailor to suit the project environment" which goes some way to palliating the 180 line items in the responsibility assignment matrix.

Just in case some of you were sitting there scratching around a long ago Prince 2 practitioner course thinking you really don't recall anything about 7 principles (and seven additional themes for that matter) you're probably right. I'm not sure what preceded Prince 2 2005, but in 2009 the framework was overhauled with the imaginative re-branding of "Prince 2 2009". I judge it to be substantially improved.

And what's all this got to do with Apple and Google? Well, whatever those folks are doing with their project management methodologies I'm pretty sure it will incorporate the 6 principles above. I shall resist the urge to conclude that Apple and Google are Prince 2 houses but I am guessing they don't rely much on full-houses either.

Making life easier (and a bit of process stuff)

Projects generally have a lot of 'interconnectedness'. And please - I don't just mean railway projects.

Processs are rarely 'stand-alone'. The outputs from one process are, more often than not, the inputs fir something else. (So help me) you'll start to hear the words ecosystem and (abandon hope all who enter) 'synergy'.

In an ideal (and possible mythical world) you have ERP, CRM and EPM tools into which all your various risks, issues etc are included. But, from time to time, the enterprising PM may find themselves without these tools and forced to fall back on more prosaic mechanisms (by which I mean Excel).

I've provided a spread sheet here. I call it ACRID (derived from Assumptions, Constraints, Risks, Issues and Dependencies). You'll also come across the term RAID (minus the constraints), and you'll probably not often come across a CORDIAL log which (of course) contains the lessons learned log. Any attempt to include a quality log is headed for the rocks.

We don't want to make life too hard for ourselves and, of course, we'll want to keep an eye on the whole process ecosystem angle so we're not duplicating effort left, right and centre.

I include here a template for a highlight report. I like highlight reports as I know of no better way to bridge the divide between the poets (for whom business transformation is a mere pen stroke) and the plumbers who lie awake all night worrying about it. I take some license but there's a sliding scale in there somewhere.

So, back to the whole inputs and outputs thing. If you take a look at the highlight report template (which is aligned with Prince 2) you'll notice there's quite a bit on work packages and products. Check back to previous posts and you'll have all all you need to cut and paste into the highlight report.

In fact I'll paste in the contents page from the highlight report template and append it with where you derive the content from each section from.

1. This reporting period

Not much going on in here

1.1 Work Packages

...Or here

1.1.1 Pending authorisation

If you need them, you'll have been writing them and you'll know which ones are outstanding authorisation

1.1.2 Completed in this period

From the project plan, paste in relevant sections of WBS

1.2 Products completed in this period

From the project plan, paste in relevant sections of WBS

1.3 Products planned but not started

From the project plan, paste in relevant sections of WBS

1.4 Corrective actions taken during the period

Issue log or other sources as appropriate

2 Next reporting period

Not much going on in here

2.1 Work Packages

...Or here

2.1.1 To be authorised

From the project plan, paste in relevant sections of WBS

 2.1.2 To be completed in the next period

From the project plan, paste in relevant sections of WBS

2.2 Products to be completed in the next period

From the project plan, paste in relevant sections of WBS

2.3 Corrective actions to be completed in the next period

Could be anything - use your judgement to include what you feel is appropriate

3 Product and stage tolerance status

SPI / CPI figures as appropriate (this will have to wait for another day for detailed coverage).

4 Requests for change

From the ACRID log so long as you raise all your changes as issues

5 Key Risks

From the ACRID log

6 Issues

From the ACRID log

7 Lessons Report

From the ACRID log

***************************************
Some points to bear in mind.

1. Truncate (i.e. hide a few columns) on the product descriptions, WBS elements, risks etc as you'll not fit them all on a single landscape A4 and the detail is probably more than your audience will want
2. I'll cover off a bit on the cost performance index (CPI) and schedule performance index (SPI) another day.
3. Corrective action could mean almost anything - include what you think is appropriate
4. Some stakeholders will want detailed information about resource burn, budget status or other detailed information not included above - this is a good sign and shows that the sponsor is 'on board' and giving the project focus.

And, to wrap up the topic of the highlight report I conlude with the following key points which I hope will impress upon you the benefit of producing it, even if your stakeholders are sanguine on the topic.

• It is an excellent tool of communication to all stakeholders, both to relay issues and status concerns but also to keep all parties abreast of progress. It is a principal tool by which the project manager can relay, escalate and communicate issues and anxieties which require board / sponsor input.
• I find it amongst the best ways of structuring a project board meeting, particularly for stakeholders less experienced in sitting on project boards
• If (like me) you keep all your WBS elements, product descriptions and logs up to date, with practice, you can produce one of these in about 20 minutes.