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.

Top tip #2 - Resource modelling in MS Project

One of the more important (and somewhat intractable) questions in project management is "How long could it take...?". Intractable because in the absence of a data driven answer, one or other existing 'compelling' dates is summoned out of air and a general preference articulated to complete the work in question by that date. Around 24 hours later (sometimes considerably less) that preference will assume the weight and authority of a board sponsored deadline.

If you're to dodge this bullet, there is a requirement for some preparation. First, you'll need to anticipate the question and the forum in which it will arise. Ideally, you control this. Next you'll want some sort of high level process or plan. The following is the sort of thing you should be able knock up in about 2 seconds and the only real requirement is for a fag packet to record it on. If you don't have the information needed to define the work to this level of detail - stay late until you do. I've included an optimistic forecast (in green), a pessimistic forecast (in red) and a median forecast in (orange).

Now in fairness, if you've got a requirement for a very large multi-hundred line project plan - that's not the sort of thing you can assemble in about the time it takes to drink a cup of tea. However, don't despair - you will nevertheless be able to apply the technique of resource modelling which I'll explain in a short-while. 

Where this technique really comes into its own is for activities which comprise a cyclical process which you'll negotiate dozens, hundred or even thousands of times. This could be migrating applications, migrating services between data centers or a large volume procurement type activity. Or anything for which there is a defined process. Typical project stuff, not quite all the same and not all different - but the sort of bread and butter activity that, as a professional change practitioner, you'll be comfortable with. And what you're really asking MS Project to do is use a set amount of resource optimally - something which would be extremely challenging to do via other means

Our process above has four steps roughly defined with some outline forecasting on work and duration. It translates to 4 lines in a project plan and it hopefully isn't to difficult to see how we got from the illustration above to the the outline plan below. I've set out the three different scenarios (optimistic, median and pessimistic) in green orange and red respectively.

I've made sure I've included both the work and the duration and you can see in the excerpt below I've assigned some resources (called optimistic, median and pessimistic).

Now, for reasons which are are better explained here you'll want to change the MS Project default from fixed units to fixed duration for this sort of modelling. But there is one little gotcha. When manipulating a project plan with the setting of 'fixed units', in theory MS Project shouldn't change the work or the duration when allocating resources. But actually - it does change the work on the first allocation of resources. When this happens you'll just want to pull it back to the original values. For the purpose of this activity - you'll only have to do this once for the 12 tasks shown below.

So - you might be thinking this seems like quite a bit of faff of no obvious gain. Bear with me and take a look at the next excerpt.

What I've done is created 10 process cycles under each forecast (optimistic, median and pessimistic). If I wanted to I could create 20 or 200 quite easily (and very quickly just cutting an pasting). MS Project very handily uses 'relative' (similar to Excel) predecessors and you don't need to jiggle these - it's cut and paste to your heart's content and in practical terms your limitation first and foremost is going to be your computer's capacity to level resources on project plans of many hundreds of lines .

Now, you have fair degree of flexibility in what you do next. You can plan for 2 resources or say 8 resources. (Just bump up the Max Units of the resource to 200% or 800% for instance). You can (if you must) put in constraints to that each process cycle must finish sequentially but as far as possible let MS Project do it's job of using the resources to the best possible degree. 

And, what I usually present to stakeholders is something that looks a bit like this. This is simply the timeline in MS Project with the appropriate summary tasks added to it. 

If I'm asked - I'll also supply the very first bit of network diagramming too. 

Note that one of the things I've done is tied in the time-lines with resourcing right from the get go. That's crucial as it starts to set in place the expectation (and dependency) that if I don't get the resources - I won't hit the dates.

What I'll do in a future post is put forward some fairly re-usable approaches using Excel and SharePoint for how you can prop up a workflow and have it generate rudimentary dashboards in real time to record and track the actual work being done.

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.





This is not a post about critical chain project management

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

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

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

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

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

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

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

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

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

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

People are objects with attributes too.

Statements like "...soft skills are an essential and often overlooked aspect of project management..." and "...the importance of getting the right people for your project team cannot be understated..." are the sorts of thing that make me want to swear off the canon of generalist project management literature for good.

Not, you understand, because it's not true. But, because it's self evident and this sort of nonsense makes the job of project management look like the job of professionalising common sense.

I was addressed by a senior member of public sector management some years ago who offered (and I paraphrase here) that "... in the 1990's we hired people for their skills, in the 2000's we hired people for their knowledge and in the 2010's we'll hire people for their behaviour." I hope this worked out okay for those people adopting such an approach.

Quite how you hire someone (or even assess someone in interview objectively) on the basis their behaviour I'm unsure. For all I know, it might not even be lawful.

I do remember thinking at the time that I would continue to hire people on the basis of their talents, track record and ability. I offer it's served me satisfactorily in almost all instances. And, as often as not, supremely well.

Whatever organisational hiring framework you're faced with (challenged by...?), you can adopt and overlay the following approach to determine what you need and help you go and get it.

Someone may offer something supplemental to this appraisal but for the purposes of employment I seek to assess initially what I need someone to know, what I need someone to do and what I need someone to be. Hence the term, "know, do, be framework".

For, let us say, a prospective defect co-ordinator we might define the following know do be framework. I've made the file accessible here if anyone's interested.

So we've taken something somewhat nebulous and intangible, put some structure around it and quantified it. This is I hope well understood to be my general preference for most things. I don't know about you, but I'm already feeling a lot happier about my ability to define and articulate what it is I want.

If you're lucky, you'll be solely responsible for the hiring and you can now formulate some interview questions (or other assessment) via which you can assess a candidates alignment with the know, do, be framework.

Even if you're simply a passive invitee to an interview you can assess a candidate's suitability against your identified criteria and express your preferences accordingly. 

One other point worth noting. You can reverse engineer most job descriptions with this approach. Pick out the key requirements and define some key points in line with what you know, what you are, and what you do that support those requirements. This can be very helpful if you're filling an application form (who still uses those?) but can perhaps more usefully equip you with some very strong responses to likely interview questions.

WBS - Second Foundation

A previous post (WBS as foundation) is far and away the most read post on my blog. So (and with a passing reference to Mr. Azimov) I'm following up with some additional practical tips that I use on more or less a daily basis.

For what a WBS is, how to construct one, what its ideally applied to and its limitations see my previous post.

So we still use the hierarchical structure previously described and I tend to use the SmartArt feature in Excel to generate and maintain the WBS structures. I tend to keep things fairly segmented - one worksheet per WBS and one WBS per work stream.

Please, please note - there are some big powerful tools out there for generating and maintaining WBSs. SmartArt works for me because as often as not I'm in a position to decompose stuff to a level that suits me. It may not work for you.

What I do next is create a product dictionary on a separate worksheet. I'll include a sample spreadsheet in a little while so you'll see the whole shooting match in action. There's a reason we put all the products on one sheet and you'll see that in the template I supply.

I cite a few points worth consideration.

1. In my last post I talked about the constant K - and idealised abstraction of the total amount of work required to deliver your project assuming no waste. This is relevant to our discussion here as K1 is the volume of work not identified during planning and due diligence. If you can't include it at the outset of a project, include the work as you discover it within the WBS and product dictionary - there's all sort of good reasons why.
2. The product dictionary is a fantastic way of tracking all your discrete components of work, who's doing it, the status of the work and a host of other stuff to
3. The work breakdown structure and the product dictionary comprise a very good record of the work done, work in progress and work yet to be started.
4. The product dictionary forces a degree of rigour into the definition of work that is issued to members of the project team
5. If you do define the WBS and product descriptions up front, the project plan will pretty much write itself. I succeed in winning this argument about 50% of the time and that 50% is always a better oiled and tuned project than the other 50%.
6. Both the WBS and product descriptions can form a very useful foundation to reporting and communication (what's done, what remains to be done and so on).

So there's a lot to recommend these two products and we can still extract a bit more smartness from the approach. See my work book here. I've included two different WBSs, each of which applies to a different work stream. We've got a product dictionary with a number of products assigned to three different people. There's a bit of filtering applied which means we can (for instance) pull all the products assigned to a given individual. And there's a bit of conditional formatting which means the individual line items change colour depending on their status which makes keeping an eye on things that little bit easier.

You could configure conditional formatting to change the colour (say) for items that are 7 days before their due date or for items that are due or overdue. But, that's really something I tend to rely on my project plan for.

You'll notice a lot of duplication in the sheet. In the instance here this is because this is a specimen created solely for you delectation and delight. However, it does highlight a particularly useful element of working in this fashion which is within any product dictionary there is a great deal of duplication. The Quality Criteria are generally re-usable for various products as are the resources and acceptance method. In short, these build nice and quickly, particularly where there's a bit of existing policy, process and procedure which can be referenced.

Lastly - something useful in Excel is the paste special 'transpose' function which means I can take any row, paste special and transpose into the 'product description' sheet as shown and I've a readily communicable summary of the product description to do with as I wish. If the product description looked familiar - it's a standard Prince 2 product.

And that is really about all there is to it.

Late for a very important date - again?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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.