Tuesday, October 27, 2015

Percent complete

We've all been there: seen a report on project progress that tells that an activity, or even a whole project is n% complete. The use of the '%' of course, leds an air of calculation to the fable being peddled.

The only time I could think a percent complete would work is for some linear unit activity such as bricklaying. One could count the bricks, then work out the percent complete of the activity. But this all falls down as soon as the activity includes non-bricklaying work: cleaning the site afterwards, removing equipment, even scaffolding (now, that should be a separate activity). The estimate of progress becomes a bit of voodoo.

In a report of a major capital program that I prepared quarterly I used a different system. The two items we tracked were out-turn cost (end of project, all done and in use) and completion date (same: all done, in use). For each project in this multi $b program we tracked original approved date and cost, current approved date and cost and forecast completion date and cost.

This put each project team on the spot with clearly objective and checkable information. They were committed data!

It was reminiscent of an approach that I came across many years ago using Timeline for DOS project scheduling software.
They used a '0-100%' measure. If an activity was not finished it was recorded as not started. It was recorded as complete only when it was complete. Again. Clear rules, real information. Of course, to be useful the activites had to be quite short, and a real view of the whole project progress could still only come from something as rigorous as an earned value system.

Interesting story about Timeline. I had it at home on my old Amstrad 386 machine, and had just started working on a factory project for my firm. I don't know how the partners calculated their costs, but I put the project schedule into Timeline with all known labour costs. I took the report on project cost projection to the partner in charge who was more than surprised at the number I calculated...I don't think they had ever done that before!

Sunday, October 25, 2015

10 factors 1: requirements

1.    Requirements. Make sure that your customer defines their requirements in depth. You need to know exactly what must be delivered. Be specific, write them formally, and get them approved. This document will become one of the baselines upon which to measure your success.

There's far more to it than this. Your client/customer will have a strategic object for its project. It might not be clearly stated or even understood, but every project has to advance the organisation's mission, or it is squandering its resources.

So, first: how does this project advance the mission? What strategic role will it fill?

Then, requirements. But 'requirements' is not just a list of things. To fulfil its objective a project must produce a level of performance, and have trade-off rules because you will never have enough money to do everything you want.

When you are refining the requirements and trade-offs, also define acceptance criteria for the requirements. Be clear hear because these will drive cost or performance. Acceptance criteria too high: performance required too restrictive, then costs could sky rocket. Performance set too broadly and performance might not be adequate. Either way you have to know when you're done and what 'done' looks like (to borrow a phrase that Glen Alleman uses).

Get those set first, then you can talk about 'requirements' and start bringing resources to bear.

But all this needs to be done with people: the people who will use the project's output: sponsor/s, customer/s, users and other 'stakeholders' or interested groups (regulators?).

Friday, October 23, 2015

Project method

Project management 'methodologies' come and go; or more to the point, come and stay, competing for our attention.

In some places I use the Prince 2 method: which can become excessively cumbersome if the PM doesn't 'nimble-ise' it.

Some people regard PMBOK as a method. It is not. Its a list, a conspectus of project management, not always particularly helpful for the practicing manager.

I like the Project Success Method (not the snappiest name), but it nicely combines good theory, good practice and good teaming, all woven into a practical doable and very scalable approach to projects.

There are four basic components to it, using interactive team processes (reminiscent in my practice of using Value Management type workshops throughout the project, from commencement to progress reviews). The four components (1-4) then lead to the activating processes (5-7).
  1. Develop a project charter
  2. Define the work (using a work breakdown of whatever detail is useful)
  3. Set activity relationships in a precedence network, setting the critical path/s
  4. Prepare a schedule (time the activities on the basis of minimum cost per activity)
  5. Compress activities on the critical path on the basis of cost of compression vs money saved/expenditure avoided. Keep cycling through this until all beneficial compression has occurred. This forms the baseline schedule.
  6. Update the schedule on the basis of 'expected to complete' dates.
  7. Review the network, re calculate the critical path, check for end date against baseline end date, and compress on the critical path again if necessary. Or, re-work the network to shift the critical path.
My own contribution:

Where possible include risk probabilities and use reference class experience in estimates to give an (agreed) 85% probability on meeting the estimate (the particular level of probability depends on the circumstances, of course).

This can be elaborated up or down depending on the size of the project, the management overhead capacity and sophistication of analysis available (earned value).

Monday, October 5, 2015

5 surprises

In his Projects in Less Time blog Mark Woeppel has a useful post on the "5 Surprising Habits of Successful Project Managers".

Let's discuss.

The surprising 5 are:
  1. They avoid multi-tasking
  2. They communicate visually
  3. They collaborate intentionally
  4. They build a one team one goal approach
  5. They control the work in progress.
I'll discuss over the coming weeks.