What is a "project'?

I've read lots of definitions of 'project'; so have you, I'm sure, but I've never been content with them: mostly they are boring statements of the obvious, along the lines of 'a project is a temporary effort with a start and a finish that...'

Currently reading Shenhar's Reinventing Project Management, I came to my own take: the deployment of resources to profitably change an organisation's capability. The organisation might be the project sponsor, or a client.

The core of a project is that a change or opportunity (which arises inevitably from a change) in the (business) environment creates the ground for deployment of resources to stabilise the organisation's interaction with the environment-now-changed (or about to be changed) in line with the organisation's strategy or mission, which itself may be changed by the project.

Projects provide capability, operations use it.

Which one? #2

I've criticised the common weighted scoring method of evaluating proposals as a type of voodoo: a ceremony that appears to be attached to reality, but, in reality, is not. It is so unprotected against common cognitive biases and misaprehensions that it may as well be 'voodoo'.

What to do, then?

Rather than subjective scoring and thinking that this produces meaning, let alone numbers that are able to be manipulated mathematically, a system of ranking by measures of actual criteria achieved, then setting hurdles for a stage 1 evaluation against requirement domains is more likely to be accurate.

The Stage 1 evaluation grid looks like this:

 The 'hurdle' is the minimum rank that must be achieved to be satisfactory, or 'in consideration'. I've set that at least half the domains must jump the hurdle for the proposal to proceed to the next stage.

The ranks are achieved objectively; for instance, under 'compliance' the proposal might need to contain satisfactory information about: board overview, corporate governance systems, means of complying with WHS requirements, means of ensuring compliance with local government approval conditions, method of ensuring sound procurement of sub-contractors, how relevant board and executive committees are employed in respect of this project, how legal and procedural obligations under the contract are met: that's at total of 7 areas of interest (in reality there should be quite a few more specified). Count the satisfactory ones, and give a rating.

Proposal 'b' has a rating of 2: it meets less than 81% and more than 60% of requirements:  that is, 5 items are satisfactory. This is a binary choice, no 'grades'; an item is either in or out.

Stage 2

At stage 2 we get serious. It would be rare for any of the contenders to be over the hurdle in all domains, so we work with only those who meet the 'clearance count': the count of number of domains for further consideration. The degree of criticality of the domain for project success is reflected in the hurdle rating.

Further consideration should be a probabilistic evaluation of the value (expected value) that the owner would obtain from the proposal.

Let's say the proposal 'b' is set at $10m. In the domain of 'urgency' for example, we see that the contractor will deploy on site much later than expected, increasing the risk of an overrun by, say 10%. The owner will lose $10k per day. The effective loss is therefore $1k per day...and so on.

This approach will give calulated and examinable numbers related to value produced.

In 'soft' projects, a similar approach would apply, but the estimating environment and related calculations would need to be handled differently.

Which one? #1

If you have been involved in any large project procurements, I'm sure you've encountered the use of weighted scale ranking of proposals.

These attempt to bring objectivity to the evaluation of proposals while dealing with a large amount of diverse information in the proposal.

They usually end up in a matrix such as:

I've grabbed this from an evaluation of an IT system.

There are numerous problems with the approach:

In most cases the weights are arbitrary: unscaled, uncalibrated and without repeatable reference to the real world. There is also scale compression for low weighted scores vs high weighted, misleading scorers as to their scores. They are nothing like a rating for uni grades where a score is weighted by the proportion of the academic program that the course represents.

The score can be sensitive to low weight 'herding': a number of high scores on low weight factors can overwhelm a high score on a high weight factor, such as is illustrated below.

Factor 'value' for proposal 'b' scores '30' for 'value', presumably an important factor, but is the proposal with the lowest score for this factor. It is nevertheless catapulted to the highest score by high scores in some low weight factors.

One could argue that the weightings as  a whole deal with this in terms of the objective of the project, but without evidence that the problems of scaling, calibration and variability arising from arbitrary assignment, the vulnerability of the scheme to even inadvertent manipulation or outright error is unaddressed. I wonder how many procurements of large projects have gone off the rail due to this approach?

There are a few ways of overcoming this. I will address them in the next post on this topic.

10 factors 8: risks

8.    Risks. Risk management is a great proactive way to solve potential problems before they occur. Identify risks early in the project and continue to manage risks throughout the project.

Tim Lister is sort of famous for his statement that risk management is how grown-ups manage projects. What does this mean?

Let's consider a major project risk: the delivery team will not be capable of achieving the project outturn performance (performance of the completed project output). We manage this risk by bringing people with the appropriate skills and experience onto the team.

A major risk is that there will be cost and time over-runs. How do we manage those?

Using 'reference class forecasting' we assess the liklihood of failure along the dependency lines of particular work package items. We then time the  related activities, with suitable coordination buffers, to allow for risk; so an activity might be timed all going well to take 2 weeks. But we know all does not go well, based on history, so, to achieve a 95% probability of performance, the activity is  provided a period of 3 weeks to complete. The project accommodates the 15%  at risk in a buffer.

We do not do risk management by sitting in a circle dreaming up risks and allotting them 'probability of occurance and magnitude of damage' to do a sum to produce a 'risk rating'. That's bumbledom. The great icon of risk bumbledom is a 'risk matrix. Cox has dealt with these. Others have also commented.

10 factors 7: issues

7.    Issues. Jump on issues as soon as they are identified. Prioritize and resolve them before they impact on your project. Take pride in keeping issues to a minimum.

Minor matters that the PM and his or her team must deal with pop up ALL THE TIME on any active project of non-trivial scope.

People usually end up with an 'issues log' sitting in an Excel spreadsheet. I advise against this. Excel is far from bullet proof and using it for mission critical information is courts disaster, even if you have a rigorous nightly redundant back up plan.

Using a bug-tracking tool from our IT developer friends might be a solution, or a custom built Access database  could be suitable. You could, of course, go the whole way and build a project information management system in Access that ties issues, risks and actions to project elements, work items, contributors (suppliers, partners, owners, approvers, etc.) and deliverables.

Examples are: Meridian Systems and, at the simpler end,  Project Perfect.

Prominent issues need to be tracked in production meetings and quickly updated. However, issues are only part of it. Decision items need to be tracked as well. What decision is required when and from whom. "Issues" aside, decision delays can be worse than an unresolved question on a project.

10 factors 6: quality

6.    Quality. Understand the expectations of your customer in terms of quality and put a plan in place to meet their expectations.

To borrow from Kant, who taught that  existence is not a predicate, I argue that 'quality' is not a predicate of projects. The correct predicate is 'performance'.

A customer seeks a certain level of performance, and possibly needs the PM's assistance to develop acceptance criteria for the performance sought.

Quality, care of the 'TQM' fad and its relations of past years, is not a thing separate from performance. As soon as it is treated as an overlay on production management failure is being courted because it is an 'add on' not an inherent part of an activity to achieve a performance outcome.

I also wonder at the functional difference between 'plan to meet their expectations' and 'put a plan in place...' The former is a very popular piece of clumsy writing that usually adds nothing to the simple present tense of the verb.

5. Control the work in progress

The overall control system I use in practical terms is the production horizon: when will 'x' be finished, compared to when it needs to be finished.

A look ahead program will help discuss such questions and Earned Value Analysis will help tell you where you've been, but you need leading indicators of success as well.

Commitments is one such: have you committed dollars to agreed activities sufficient for their timely delivery (e.g. you've got the next sub-contractor signed with sufficient time for him to mobilise to start work in time.).