Simple Never Is

    The notion that there are simple project management processes is just that "notional." There are straight forward processes. There are important and less important processes. There are processes more complex than others. But "simple" usually means simple results, simple understanding, simple results.
    I've talked about the Irreducible Program Controls elements in the past. Here's my current thoughts on the Irreducible Program and Project Management Principles:

• Capabilities Drive Requirements - capabilities are what business people measure success with. The underlying technology is interesting to technology people.
• Requirements are fulfilled by Work Packages - detailed schedules (or the lack of detailed schedules) are interesting to schedulers, planners, developers and engineers. But deliverables are interesting to business users.
• Work Packages Define Deliverables - without a clear and concise of what "done" looks like, all the detailed planning is worthless. Define "done" at the Work Package level. This could be a Scrum iteration if you are so inclined. But keep the planning details to the Work Package and deliverables level until forced to go deeper.
• The Performance Measurement Baseline (PMB) describes the sequence of work - putting the deliverables in the order of production is a good first step for planning and scheduling. Remember "the reason for 'time' is to keep everything from happening at once."
• Measure Physical Percent Complete First - effort and duration are not measures of progress.
• Perform only authorized work - doing work out of sequence simply creates more confusion.
• Use Earned Value (or some equivalent) to define progress - it doesn't have to be full blown 748 EV. But answering the question - "what did I get for the money I spent?" "How much money did we plan to spend to get this deliverable?" and "do I have enough time and money to complete this job?" are discussions around Earned Value.
• Adjust the estimates of future performance from past performance - Earned Value can tell you this. Velocity in agile does not. It is yesterday's weather, using level of effort labor spreads. Agile does speak to deliverables, but that's it only connection to Earned Value.
• Use Technical Performance Measures to pre-define "done" - TPMs are measures of product or service performance defined before the work starts, so you can recognize "done" when it arrives. These are NOT tests, they are capabilities and the fulfilled requirements that enable them.

These are principles, so remember ...

Principles that are established should be viewed as flexible, capable of adaptation to every need. It is the manager's job to know how to make use of them, which is a difficult art requiring intelligence, experience, decisiveness, and most important, a sense of proportion
- Henri Fayol, General & Industrial Management