PM training

How to train non-project staff in project management?

I have access to short courses sponsored by my employer that could be used, but from what I've seen of them they are what I call 'lock-step' or recipe courses. A collection of 'do this then that' courses rather than invitations to think through projects.

One course that I did like, also a short course, is the one at Stanford University. Looks good, but pricey!

I would steer away from courses aimed at a qualification: Prince2 and PMBoK (so called) as they train to the qualification; again, not for thinking about projects.

Frustrating.

Of the longer courses I think I'd lead towards Adelaide Universities' masters degree. It seems to be pitched at an appropriate conceptual level, but that's for longer courses.

What do I want in a course?

1. The business context of projects: the financial and competitive environment and how projects arise and are handled in organisations.
2. Projects as systems that respond over time to their own evolution effecting resources, information, capability (both the input capability and the performance capability sought).
3. Structure of projects: getting to details of the WBS as the central driver, and working back through dependency relationships. This would touch on the low level tools of scheduling, tracking (earned value), delivery methodologies and handling risk. I'd be loath to handle 'risk' as a separate category as risk should be incorporated in the project plan through offsetting activities, and scheduling adjusted for delay risk on a probabilistic basis, or at least using Goldratt's buffer system.

Project principles

I like the approach that Adam on Projects takes to project management. I've placed his blog in my list on the RHS of my blogsite.

He has five principles to guide project work. I might discuss them at some time.

His diagrammatic representation of them is below.

What is PM?

From time to time I put my mind to the characterisation of project management. What, I ask myself, is it? This usually occurs when I consider approaches to training staff to think about projects, rather than simply learn a few techniques absent a theoretical structure that will orient them in the practice.

Is a project a choice reduction machine, a transformation machine, or as Koskela puts it a means of managing flow. Flow I like, as long as the flow includes information, its creation and management.

My starting point is the people who form the project: at the start they constitute a 'community of intent'. What's special about that, you ask. The special thing is that it is free agents coming together form different perspectives to contribute to an outcome. All management is about this, I suppose, but in project land, the community is for action that will take an organisation from a dissonant  relationship with its business environment to one in equilibrium. The dissonance might be a problem, a deficiency or an opportunity. The dissonance provides impetus for action by bringing the business to a a more stable relationship to its environment that produces the sought benefits.

Equilibrium doesn't mean smooth sailing, but that a point of dissonance has been dealt with: a new product, capability or investment available that deals with an opportunity or deficiency in the previous relationship with the environment.

Not yet a theory, of course, but that's how I think about it. Without a theory we have merely a collection of techniques with no home. We need the home.

BTW, list of Koskela's papers.

Something lost...something found

The Pretenders' song Hymn to Her was mentioned at a recent Economic Society of Australia symposium that I attended on Cost-Benefit Analysis. It was cited as a quintessential economics song: opportunity cost sprang to mind. But to my mind it is more of a PM song (well, its even more than that: one of the great ballads of the 80s): "something is lost--something is found"...day in day out for busy PMs!

Old time

Sorting out my library recently I bumped into a little known classic in project management: Modern Project Management by Claude Burrill and Leon Ellsworth.

Flipping through the pages I was a little surprised to see that the sound principles that this pair laid down over 35 years ago still have made little headway in project management.

For example, they wrote about probabilistic risk estimating; most people are naive about this and plan their projects absent of any realistic incorporation of either schedule risk or budget risk. So, of course, too many project slide over one or both to the surprise of the project team and the anguish of the investor.

The corollary of this is that most people embark on a project with a risk management 'ceremony'. They have a chat about risks (no fault mode analysis, no dependency risk analysis based on the project WBS, if there is one) involving making a cute matrix of coloured cells that pretend to represent risk appraisal. Of course, it does not.

For your risk management edification, a useful post on an analytic approach that can provide useful case study input to considering risk.

Just don't do it

Don't do what?

Why, use PowerPoint of course.

This evening I was at a formal inauguration of an academic scholarship in honour of a deceased professor of the school (professor means head of department, not just lecturer, as in the USA).

We had PowerPoint for some images related to him and his work...about three I think. During a speech the computer decided time was up and switched itself off. The image projectors declared that there was 'no signal' and joined the sleep circus.

The technical man ran down, woke up the computer, that woke up the projectors, and of course, he had to restart PowerPoint in edit mode, switch to show mode and flick through to the right slide. Pathetic.

Lessons  (or 'learnings', as we like to say today)?

1. turn off the power saving features of computers before the presentation
2. make sure the projectors don't go to sleep
3. save the  PowerPoint in 'show' mode so you don't look like a dork when you start or re-start it, frigging around with the mouse to turn to a slide show (F5 does it better, by the way)
4. convert the PowerPoint to a video (Quicktime?) and just run it in a loop.

This was at a university with 'technology' in its name...unbelievable!

Guiding Principles 8: Time management

Encourage project managers (PMs) to value time—both stakeholders’ and their own—when making project execution decisions and managing meetings.

Worth mentioning, but I’ve not come across any competent project manager who doesn’t move at an intense pace: tightly run meetings, concise communications, and clear advice.

This topic is often discussed as 'time management', but do we manage time? No. Time passes. What we manage is delivery or project performance (distinct from technical performance, or how the project object does its job).

Good delivery management comes from good information management. And if there is a primary element of project management, it is managing the flow of information to keep abreast of the state of the project, its dependencies and interfaces.

The communication system that moves information through the project team and documents the movement of information makes time management efficient and effective. Without it information is unreliable and its value to the project drops, imperiling the project outturn value.