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?)

Equine allegories

First, please excuse the title  - a cunning attempt at promoting my blog. Anyone (and I mean anyone) who Googles "Equine allegories" is sure to be directed straight here. A winning strategy I think you'll agree.

Now, for those of you not in 'my manor' as it were, there's been a bit of a scandal of late with beef not being beef. Suffice it to say, jokes about Red Rum Steak abound. 

I think this has got some fascinating insights for anyone in the business of change.

Let's talk about quality assurance and product acceptance first. Projects are comfortable in a landscape of customer / supplier. Other approaches exist. I've always adopted a stance that the supplier is accountable for quality assurance. Equally, the customer never divests themselves of the onus for due diligence corresponding to product acceptance. It is too risky to rely wholly upon the supplier's quality assurance.

Now, risk. I've never been comfortable about the whole 'transferral' of risk thing. Mainly, because I don't think you can transfer risk predictably and reliably. I'm minded of a supplier who was responsible for building the new Wembley Stadium and F.A cup finals which were held in Cardiff (Wales) for 2 (3?) years due to delays in construction. And similarly here, while the supermarkets in Britain can point the finger at their suppliers, the fact they've not done their own testing isn't going to sit well with their customers. Particularly when they've almost certainly profited from the whole fiasco..

From a consumer point of view, it seems to me that the consumer demands choice at the lowest  price. Now hold on a minute there, because actually, I don't.. But, it's the line spouted by the business's involved in grocery retail so there may be a grain of truth in it. So, if we only make a purchasing decision predicated upon cost, then we're likely to get a supplying decision predicated wholly around cost with all the consequences it brings.

You'd think governance would play the part of fair, honest and effective broker in all this. I wouldn't. Basel II, Sarbanes Oxley and FSA couldn't avert the biggest banking crisis of a generation. You can try all the tricks in the book to minimise risk, maximise value and ensure the right decisions are made by the right people to the right criteria at the right time. But, if greed, gain and guile are the prevailing cultural themes within an organisation, it won't matter.

But, there is an up. Discovering that stuff has gone wrong today makes you better off than you were yesterday. You can start the job of corrective action, you can learn some lessons and strengthen whatever is needed to prevent re-occurrence. 

Finally, there's something else to take away from all of this. We can read and write all the books we like. Develop the discipline of project management in new and exciting directions. Effective and sound judgement however is something ephemeral, acquired slowly and lost quickly. 

Requirements part 5 - a very useful spreadsheet

I think there might actually have been one or two more posts on requirements than 5. No matter the end of the tunnel is in sight.

I've written quite a bit about what not to do with requirements and conversely some useful salves for common problems. What I haven't done (until today) is state clearly my approach to managing requirements (and more besides) or provide the tool to get the job done.

To date, we've talked about MoSCoW analysis (yuk!), pair-wise comparison, cost of compliance / non-compliance, KANO analysis and quite a bit more besides. We've never talked about UML or a bunch of other stuff, but ultimately (as you'll see) that might not matter too much.

Consider the illustration below - a veritable soup of inputs relating to requirements. Equally, a customisable and completely transparent score card that can be constructed and agreed by stakeholders early in the process.

What we're starting to get towards here is an approach to requirements prioritisation and management that can be highly customised to suit any situation. 

Get the stakeholder buy-in right, get the score card right and the rest will follow.

In the example below, I've used the following scoring elements - you however can use what you like.

• MoSCow - exactly what it says on the tin. MoSCow does have its place albeit do remain cognisant of the limitations previously discussed.
• Kano - see last post. A quick and easy way of assessing non-monetary value
• Contribution to the business plan - if it doesn't contribute, should you be doing it?
• Compliance - do we have to have this to meet regulatory requirements?
• Senior stakeholder flag - if the the budget holder wants it in taupe, then let's have that right out in the open from the get go.

Your score card might incorporate the elements illustrated above or be something complete different. You might have specific organisational imperatives which mean you incorporate none of the elements above - fine. The approach is no less valid.

So - you've got a score card - what next? Excel that's what. What you're seeing below is the scorecard above incorporated into Excel.

It's not too busy a spreadsheet but it has got a couple of tricks up its sleeve.

First, the fields are 'constrained' and aligned with the scorecard.

And, we've got a a simple but long formula to do the scoring calculation. Note the red highlight. We don't put the scoring in the formula itself - we use a lookup to a table elsewhere. This is important and we'll discuss this more later.

=IF(C2="Must have",Lookups!$B$1,(IF(C2="Should have",Lookups!$B$2,(IF(C2="Could have",Lookups!$B$3,(IF(C2="Won't have",Lookups!$B$4)))))))+IF(D2="Dis-satisfier",Lookups!$D$1,(IF(D2="Satisfier",Lookups!$D$2,(IF(D2="Delighter",Lookups!$D$3)))))+IF(E2="Key",Lookups!$F$1,(IF(E2="Required",Lookups!$F$2,(IF(E2="Aligned",Lookups!$F$3)))))+IF(F2="Yes",Lookups!$H$1,(IF(F2="No",Lookups!$H$2)))+(IF(G2="Yes",Lookups!$J$1,(IF(G2="No",Lookups!$J$2))))

I've uploaded the spread sheet here and you can play to your heart's content.

Some things to bear in mind.

1. You aren't constrained to 'sum' the scores. Multiplication has its place particularly as it opens up using a zero to effective nullify a requirement
2. You aren't constrained to using this just for requirements - the same approach works very well for (say) assigning a risk rating to server moves in a data centre migration
3. I've used significantly larger spreads sheets both in terms of the number of criteria used and the scores which correspond to those criteria. Undoubtedly there's a limit but I haven't found it. If you do (and good luck with that) you can always split the formula in two and sum the output.
4. Don't limit yourself to linear scoring - in point of fact, you're going to need to justify very carefully the use of linear scoring (i.e 1,2,3,4,5,6 as opposed to 1,3,8,20). Most things (I think) will benefit from a non-linear scoring approach.
5. Make sure you get your criteria right from the get go, the scoring only needs to be 'about' right as we re-tune that later on.
6. Weighting - don't think you can't apply a specific weighting to one or more elements on the scorecard - in point of fact this is just another way of playing with the scoring but don't rule it out.
7. If you're smart enough you can probably use a custom list in SharePoint to do this.

Finally, getting the scoring in the scorecard right from the get go is tough. So tough in fact that I discourage you from trying. Stakeholders can get a bit cagey too as, while they see the merit in the approach, they tend to be less certain about getting tied down by a scorecard that they (quite understandably) can't appreciate the fullest implications of at the outset.

Fine tuning the scoring is the subject of the next post.

Requirements part 4 - Kano Analysis

One of the things that I always keep in my mind when assessing and prioritising requirements is the cost of fulfilling the requirement relative to the cost of not fulfilling the requirement. I tend to think of this as the cost of compliance versus the cost of non-compliance.

Cost is an important dimension to incorporate into the overall requirements management effort, stakeholder engagement activities and so on and so forth. The application of this sort of approach is broad. I've recently been working with a client to work out which of their 'extensive' software library they wish to retain and which they can afford to withdraw. 

It isn't quite the case that there's a one to one relationship between a software application and a set of requirements. But there is often a 'service' comprising of one or more applications (and possibly more besides) which together fulfil a set of business requirements.

With all of this said, costs of compliance / non-compliance, serve as a useful entry point to start a conversation about 'what's in, and what's out'. It's quite useful too to bring any written business objectives into the equation as well.

But, as I say above, the cost argument is an important dimension, it isn't the whole story.

It can be difficult to sell a decision based wholly on cost (even if the decision is actually wholly cost based). This can be particularly trying when the end-user is divorced from the costs. So, we can bring something else into the equation which can help namely, Kano Analysis.

Kano analysis nicely skewers the fact that there are some very different types of requirements as far as stakeholder perception goes.

1. If you walk into a room and turn the light on, and it comes on you're only ever going to be so happy. On the other hand, if the light doesn't come on you will be dis-satisfied.
2. If you walk into a room and the temperature is too cold, but you can adjust the temperature with a thermostat, you'll probably be satisfied.
3. If you walk into a room and there's coffee and biscuits laid out for you, you'll probably be delighted.

Kano analysis is intended to give you a structured approach to identifying which category your requirements fall into with your stakeholders. It has the added bonus of being very quick and easy.

See the illustration below. All we need to know is the answer to two questions - the answers need to represent a consensus of the stakeholders. Workshops can be used to elicit the information and you could do something useful in a room of people with sticky labels (I'm all for getting decisions made at the coal face)

With these two questions answered we can map a requirement to one of the following categories. In practice, you don't tend to get any of the combinations marked null. It does happen an usually it's because there's a lack of consensus or clarity.

We can usefully articulate the requirements as follows. I haven't bent my meagre brain to it yet, but I can see a useful bubble chart in Excel mapping out the requirements - do let me know if you beat me to it.

And, in the event that ultimately all decision making is cost led, you can engage and communicate with stakeholders to manage expectations (and sometimes fallout) from commercial decisions that have implications for them. It's all good, useful information.

We've got two last bits to cover off and then I think that'll be an opportune point to take a break from requirements.

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.

Management, governance and a partridge in a pear tree

I do read quite a few other blogs and there must be something about the year end that elicits a desire in bloggers to report on what they did well during the past year, what they won't do in  the next year, emerging trends and must haves for the ensuing 12 months. You get the picture. I'm not so sure I have much to add to the existing canon but it has spurred me to be just a shade more speculative that is the norm.

I include some points below which might be worthy of a moment's consideration in terms of positive change to the overall landscape of project management

1. Project Complexity Modelling. For clarity, this is an approach to modelling how complex a project is and there is some coverage of this topic in the (former) OGC's Portfolio, Programme and Project Offices – P3O literature here. However, it's subjective, qualitative and not (in my experience) used. I'd like to see something quantitative, something that was capable of analysing a network diagram and, ideally something that allowed you to manipulate a project's plan or scope to influence (reduce) any given project's complexity.
2. Getting change practitioners a seat on the board. CEO, COO, CFO, CIO, C3PO? (you heard it hear first). My view is that a business's ability to undertake change effectively and efficiently leads to a significant overall competitive advantage. Supplement this with 'poor governance' being an oft cited cause of project failure and isn't it time the business of change took its seat at the top table?
3. Configuration management (bit of a misnomer this one). I like to think of myself as a generalist PM, an aspiring 'project manager's project manager' if you will. I do acknowledge however that a lot of my thinking comes from 15 or so years working in assorted I.T. environments. In any I.T. environment, configuration management (the management of your configured items) is a cornerstone of a well managed I.T. estate. Get this right and you have the opportunity to get most other elements right too. Get this wrong, and this opportunity will elude you. In very succinct summary, the CMDB (configuration management database) should in most cases facilitate an answer to the question "what should I worry about if I change this specific item". It provides a map (of varying quality and granularity) of what is joined up to what. There probably is something similar in the world of project management - the portfolio view, the PMO, the integrated programme and project management tool-sets - call them what you will. There's never been one when I've needed it.

And I think three things will do nicely. Three's a good number in management - military organisations the world over have known this for quite a while hence, there are three sections in a troop, three troops in a company, three companies (or thereabouts) in battalion an so on.

And that's not a bad hopping off point for the next point. Ask five people in a room what management is and you'll get six different answers. I always come back to the point that if something isn't being planned, controlled and directed, then it isn't managed. And furthermore, that things that are managed are predictable, sustainable and controllable. I think most of this relates pretty well to points 1 to 3 above.

(Incidentally, if you ask five people in a room what governance is, you'll get 3 answers, 2 questions and a partridge in a pear tree - but that's a topic for another day).

So after all I might have something to add to the overall cannon of project management rhetorical introspection. A bit more management in 2013 would just do nicely.

Forecasting part deux

Vicissitudinous. Now that isn't a word you'll hear everyday, let alone everyday in the field of project management. But is should be and if it wasn't such a challenge in terms of spelling and pronunciation, my feeling is that it would be a good deal more used than it is. In short - prone to adverse change.

As is my habit, in my last post I talked at some length about the shortcomings of the Pert weighted average. I'll try and suggest one or two improvements.

First however, a simple suggestion that quite apart from any estimating technique will help immediately with the accuracy of your plans and the forecasting effort.

Keep your tasks short in duration / work - never longer than week, ideally to a maximum of 2-3 days. Decompose your tasks to a level that can be undertaken by one person.

Sounds obvious doesn't it? I have however lost count of the number of project plans in which a few vague words (usually something like "Re-provision host environments" or some such hides 300 man days of work and a 60 day duration. And when, as surely you must, you enquire as to the specifics of the host environments and quite what their 're-provisioning' entails you'll often be greeted by a wall of jargon or a dismissive wave of the hand which suggests if you don't know already, you shouldn't be asking. 

Keep digging. How long does it take to change a tyre? Actually, I'm not certain - but I know the following questions are easier to answer.

1. How long does it take to remove the spare from the boot?
2. How long does it take to jack up the car?
3. How long does it take to unscrew the wheel nuts?
4. How long does it take to find the locking wheel nut adapter? Ah-ha - you say you don't know where the locking wheel nut adapter is? Well, that's very interesting isn't it...

So you get the picture, decomposing the task through what is sometimes call 'progressive elaboration' is time well spent. Estimating shorter smaller tasks is easier and it tends to throw out details that might otherwise get overlooked.

I don't think I want to get too side-tracked here but I will take the opportunity to address a concern. The drive towards productivity very often means that planning phases are curtailed both in terms of duration and the degree of rigour that is sponsored / supported. Equally, there's often the (somewhat incredible) imperative to spend money quickly (usually this is about allocated budgets and financial drivers). In short, the PM is busy trying to create product breakdown structures, product descriptions and plans that actually reflect the work to be done, and the project sponsor / board is saying - get on with it. Remarkable.

I'll spend some time on how to address this particular concern at a later date, but right now (for all you project sponsors who don't support detailed and structured planning) I offer the following. For your project to be any kind of success you will need to address the following.

1. You will need to identify all requirements
2. You will need to elaborate the work to deliver the requirements
3. You will need to identify and broker the resources to do the work
4. You will need to do the work to deliver the requirements
5. You will need to undertake such quality assurance work as is necessary to find defects in products being delivered.
6. You will need to fix any defects you find.
7. You will need to pay for items 1 - 6 above

Accepting (as I hope you will) that 1 - 7 are somewhat inevitable, you can do all that at the end of a project if you so choose. It's a darn site more expensive that way and tends to get up the noses of your stakeholders something rotten. Okedoke - I concede that I've wandered a little off my intended track here - but surely worth it for the word vicissitudinous alone!