10 factors 2: scope

2.    Scope. Define scope well. Get your sponsor approval for scope changes, making sure the sponsor understands any schedule, budget or other impact to the project.

In most projects what will be done can be ambiguous. The scope should remove that ambiguity; particularly by saying what will not be done that might be expected to be part of the project.

This can occur at interfaces with other activities (e.g. activities of suppliers, customers, the sponsor and other projects within the current program or portfolio).

Interfaces are a special problem because the boundary is where your project's expenditure should stop, or clarity created as to the process whereby the boundary can be crossed.

Change and configuration need to be pointedly managed to contain scope and ensure that the investment will produce the business results sought. Relax on your first change request from the sponsor's bright eyed young star, and you may have changed from the high road to the low road. You will wear it and not him or her.

Rules and processes enforced by the PM for change acceptance and budget and delivery effect need  to be set. Additionally the effect on overall outturn performance and high value requirements needs to be advised to the sponsor: does he want  THIS project, or some other project that will do some other thing?

1. Avoid multi-tasking

Yes and no.

Sure, don't try to work on a number of independent tasks at the one time, you'll end up with inefficiencies of time and effort for all, resulting in poorer performance that obtained by concentrating on a task until it comes to a stable stage (when you can leave it with minimal inefficiency upon return to it).

However, a PM, like any manager, hops from issue to crisis to ceremony ALLTHETIME. That's what management is.

The 'secret' is to organise this torrent of calls on your time with an end in view; not just the project as a whole, but on current delivery chains: actions that must be taken and completed to maintain the tempo of the project.

Value for money

Particularly on government project, I often hear the phrase 'value for money'. From time to time I've asked how it is measured. Often I get long vague replies, revealing that the answer from that person is 'I don't know'.

I think that there are three approaches to assessing value for money:

1. market comparison: for a similar service or product, what would a commercial organisation expect the market to offer for the service or product? Market comparison was something I used in the heady days of 'private financing' of public infrastructure.

2. opportunity cost-benefit: before I spend $n to achieve a certain result (service, product or capability), what other benefits could I obtain for spending that amount on something else. In some cases the answer would be a market comparison type answer, but it also would help the spender assess if the plan represented a good use of money.

3. capability for cost: somewhat like a QFD assessment, what capability am I getting for the cost? Particularly, am I paying for capability that I do not need and therefore paying too much? What then should I be paying for the capability I want? The question is answered by item 1 or 2 above.

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!

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

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

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.