Friday, February 16, 2007

Project Controller: The Project Manager's Best Friend

Halleluyah! Finally, there's an article saying what I've been saying for years. With projects becoming more and more complex, and leadership and stakeholder management requiring more attention than project managers have time for, there's a need for another role to manage the "control" aspects of the project.

This article by Robert Wourms on Projects@Work details how organizations such as State Farm have had success doing just that. Bring on the Project Controller. As a member of the leadership team for PMI's new standards for program management and portfolio management, I witnessed first hand how valuable this role was, as it freed the program manager up to actually lead the program.

The article shows how the project controller's role can include tasks such as:

1) Educating the team on processes
2) Facilitating Planning and Control sessions
3) Developing the project schedule
4) Controlling progress
5) Tracking and analyzing costs
6) Managing Issues, Risks, and Changes
7) Documenting and delivering status information

So what's left for the project manager to do? Plenty. Supporting this, the article offers a valuable table outlining the role of the project manager vs. the program controller. Read on...

http://www.projectsatwork.com/content/Articles/221443.cfm

Labels: , , , , , , , , , , , ,

Sunday, February 11, 2007

Getting good at estimating

A couple of the current consulting engagements include good work estimation of project activities as a required end state. And it needs to be done quickly!
In one case there are a couple of high-profile projects with rigid completion dates. And the organisation has a history of fixed duration scheduling. In a balanced matrix project management environment where the functional managers have traditionally taken care of resource availability, the project managers are concerned with meeting dates. The top management is now concerned that there are sufficient fumctional resources to meet the project workload.
The other case is in a less advanced organisation. Top management wants to implement a project management regime that provides for cost and schedule management. In this weak matrix environment, there is no history of estimating either cost or schedule.

A quote I came across recently points up the dilemma:
"The trouble with using experience as a guide is that the final exam comes first and then the lesson" (Anonymous)

The challenge for an organisation is to have the lessons before the final exam. And that means starting to capture the experience. And the realisation that the capability cannot be built overnight.

There are many references as to how to 'do' estimating. The PMBOK is one obvious example and Simon Wallace at the EPM Book gives a very readable description. But we're still faced with the issue of getting to the point where estimating is an established part of the project management process. And that is not a quick transition.

So what's to do? The short answer is 'make a start'. Start creating estimates - using the techniques described in the literature. Start recording estimates. Start measuring actual effort. Start feeding back variance information into the estimating process. Start engaging other parts of the organisation in the importance of estimating. It won't happen overnight but the sooner you start, the sooner the client organisation will improve its project management capability.

Labels: , , , ,