Sunday, March 3, 2013

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