Archive for January, 2010

PostHeaderIcon Process, People, Tools – In That Order

Project management is a blend of processes and procedures, the skills and knowledge of the project community, and tools for assisting with the application of process and knowledge. Good project management is when these three are properly tailored to the needs of the organization, its projects and their teams.

How It Goes Wrong

Corporate initiatives to improve project management sometimes fall short of their goals when these three elements are (a) incomplete, (b) not customized, and (c) treated in the wrong order. For example:

(a)    Training is conducted in process but no tools are provided for follow-up application
– a sure way to minimize training ROI

(b)   Training is conducted in processes that are too generic, too lightweight or too onerous
– very common, leaves PMs to figure it out for themselves

(c)   Project managers are given project management tools without prior training in process
– the “seduction of software”, usually results in poor quality information and plans that are plain wrong

It’s a repetitive scenario and goes some way to explaining the plethora of statistics on failed projects and generally poor project performance.

Right Focus, Right Sequence

The swiftest and most effective way to raise the bar of project management capability and performance is to ensure process, people and tools are treated in an integrated way with appropriate focus on each at the right time. Here’s how:

  1. Define a process that fits the organization’s projects and culture
    (proper tailoring is critical to ensure buy-in and long term success)
  2. Provide training in this process
    (we’re talking lifecycle here, not PMBOK knowledge areas)
  3. Follow-up immediately (even simultaneously) with hands-on tools training
    (custom templates and project management software)
  4. Then finally, ensure that support structures are in place
    e.g. a PMO and coaching, to embed the disciplines and practices for the long term.

Done right, it’s a recipe for sustained success.

PostHeaderIcon Completion Criteria Ensure Done Means Done

How do you know for sure when something is declared “Done”, that it really is? By defining completion criteria. These little nuggets are one of the single most important – yet frequently overlooked – aspects of project planning.

Completion criteria root out ambiguity (see The First Law). They align stakeholders, team members and the customer on the conditions for acceptance and validation of the project outputs. And they improve estimating quality by enhancing understanding of the desired work result.

Its a Binary Thing – “done” or “not done”

Completion criteria should be defined first for the project deliverables, which in doing so will actually help identify tasks for the WBS, and second for (ideally) each task in the WBS itself. Well-written criteria:

  • Are defined by the deliverable or task owner
  • Clearly state the characteristics and attributes of the output  – “what done looks like”
  • May include the measurement and validation requirement – e.g. “who reviews what”
  • Are defined in a binary way (i.e. totally unambiguous).

Can we really do this for every task? You decide – it’s a tradeoff between increased planning effort vs. increased risk. But consider that while this may initially seem onerous, the reality is that it does not take much more effort to write a statement or a couple of bullets specifying what ‘complete’ means (for example in the Notes field in Microsoft Project). Put in the context of the project overall, it’s a seriously small price to pay for dramatically increased clarity and reduced risk of misunderstandings.