Wednesday, November 25, 2015

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?

Thursday, November 5, 2015

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.

Wednesday, November 4, 2015

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.