From the Yellow Notepad: Project Management - Effective Project Management As promised before, here are some more notes from the classes that I’ve taken as part of my soon-to-be-completed Master of Software Engineering degree. This time: (software) project management. Most of this information comes from Effective Project Management by Robert K. Wysocki.

FYI, this was one of the few classes where most of my in-class notes weren’t about the course material at all but were reflections about how we do project management where I work. Once I discovered that I was a project manager, I realized that I had best become better at doing it. Funny how obvious that seems in retrospect.


Project = “A sequence of unique, complex, and connected activities having one goal or purpose and that must be completed by a specific time, within budget, and according to specification.” (Wysocki, 4)

Program = A collection of projects with multiple goals.

Most “interesting” software projects involve some degree of unclear requirements or unknown solution. These projects should ALWAYS use an adaptive/agile or iterative approach.

  • Examples: Evolutionary waterfall (for low risk/easy projects), SCRUM, Rational-Unified Process (RUP), Dynamic Systems Development Method.
  • These methods separate high-level and detailed planning. Each must be done, but the detailed planning is not done all “up-front.”
  • (These are not iterative approaches: Pure Waterfall, Rapid/Parallel Development, Staged Delivery.)

Continuous quality managment and process quality improvements appear as keys to successful projects.

What every project should have . . . to some extent or another

Linear/waterfall, iterative/agile/adaptive, and extreme project management techniques all have the same phases, they just appear in different ways. They are:

  • Define the project: Take the problem, proposed solution, and objectives and make a project charter and scope document
  • Develop detailed plan(s) — preferably iteratively and just-in-time
  • Launch the plan(s)
  • Monitor and control project progress: Reporting, change control, problem escalation, revising plans
  • Close out the project — Acceptance, installation, party! Seriously, you must party.

Risk Management

The major responsibility of the project manager is to manage risk in the project.

  • Identify risks:
    • Quality and performance with respect to technology
    • Resource allocation
    • Planning process
    • Organizational support
    • Changing legal and regulatory requirements/availability
    • Suppliers and contractors
  • Assess risks:
    • Separate risk, magnitude, and probability
    • Exposure = Probability of loss times cost of loss
    • Consider using a risk matrix (high-medium-low cost v. high-medium-low probability) to track exposure
    • Consider whether solution costs more than the loss
    • Assess risks at each project phase/iteration
  • Respond to risks:
    • Accept — Do nothing
    • Avoid — Don’t do that part of the project
    • Contingency planning — Reframe the plan to deal with risk
    • Mitigate — Reduce the probability and/or the magnitude of loss
    • Transfer — Outsource the risky part to someone more capable of handling it
  • Monitor and control risks:
    • Make a risk log.
    • Review risks at status meetings.
    • Add triggers to risks so that countermeasures are taken at the appropriate time.

Project estimation

The average worker efficiency in IT is 50-65%. That’s the amount of time actually devoted to project work. That doesn’t include ad hoc interruptions, which takes another 33% of so of the workday. And there’s a lot of variation in duration for the same task, since everyone works at different capacities. So . . . It’s best to think in terms of task size and not the time that it takes to complete a particular time.

Methods for estimating task size:

  • Similarity to other activities already done — Usually a very good predictor
  • Historical data — Usually very objective and concrete
  • Expert advice — Be weary of using just this
  • Delphi technique — Iterative planning poker. Result is the average of the third round (or consensus)
  • Three point technique — E = (Optimistic + 4*Most Likely + Pessimistic) / 6 for however you define those three terms
  • Wide-band Delphi — Delphi technique with three point computation instead of a simple average

You can (and should) determine duration from the effort values and from that cost.

Project task management

Having a work breakdown structure (WBS) does not mean that the project must be managed like a waterfall, with all of the tasks defined to a fine precision before implementation can start (though some tools make this more likely).

Parts of the WBS can (and should) be high-level at the start. The plan gets more detailed with each iteration. Instead, treat a WBS as a represention of the functional/modular breakdown of the system. It’s useful for visually thinking about the project, designing the architecture, planning and estimating, and reporting status.

The network diagram is more useful in actually planning the project than a Gantt Chart, which is good because Gantt Charts suck. Then network diagram contains sequencing information, and you can use it to find the critical path of tasks that define the full project duration.

Random thoughts

This stuff — plus copious amounts of Hindi and Arabic scribbling — filled the spaces between my notes from reading Wysocki.

  • If I had a time machine and could redo parts of a project, when would I go to add more value or lower costs?
  • Lucky + smug = ?
  • Consider keeping a historical journal for estimation: size of project, time, resources, technology.
  • Engineers are creative, problem-solving people. Rule-following is not a creative act and implies a solved problem. If software engineers are going to do project management, the project management techniques must not get in the way of actually solving the project’s problems or it just won’t happen.
  • I am the very model of a modern major general.
  • How well does agile planning and development scale? Can you do critical path analysis with it? Is it even worth trying to do that?
  • Measure quality, productivity, maintenance work v. feature work, time to market. Measure when starting, when passing milestones, when encountering defects.
  • I like postage stamps.
  • Iterative development should have deliverables that can actually be met at the end of each iteration. The iterations should be tied to deliverables. Milestones shouldn’t just be mile markers; that’s what a calendar is for.
  • Do risk management at every stage of the project.
  • Use a pull system for features with insertion for bugs and technical support assistance. Translate “do interruptions now” to “do next.” Finish up what’s in progress if it’s worth doing.
  • Product != Project != Program != Product
This entry was posted in From the Yellow Notepad, Life Lessons, Software Engineering. Bookmark the permalink.

4 Responses to From the Yellow Notepad: Project Management

  1. Lisa says:

    lucky + smug = drama llama

  2. Bob Migrow says:

    Your point about the WBS is correct. The only thing is that sometimes there needs to be more than one WBS for one and the same project. Different team members need to slice projects in different ways. Unfortunately this will hardly be possible with old-school tools, like MS Project. Do you agree? I recently found a blog post about this fact. The author proposes an interesting solution – his own pm tool. I’m in the ptesting process right now and what I see is really impressive.

  3. Jeff Mather says:

    Bob: I agree that you’re going to need more than one WBS, whether it’s going to be a master WBS with multiple sub-WBS or a WBS that evolves through time. I’m more inclined to believe that the latter is more realistic unless you’re working on a project with very few unknown aspects, well understood goals and technology and little risk.

    I’ll have to check out the article about Wrike. I’ll reserve all judgement until later.

    Though I didn’t mention it in the article, I’m leaning in the direction of not actually requiring any work breakdown structures for a project. Don’t get me wrong, I’m in favor of requirements analysis, functional design, and architectural design. But I’m gradually becoming a convert of agile and lean methods involving iterative project analysis, just-in-time design, work queues (e.g., kanban), and structuring projects around iterations where you’re always close to shipping.

    I haven’t used many projects with “true” agile management, but I’ve had better success than when I tried to use a WBS.

  4. PM Hut says:

    Hi Jeff,

    I would like to republish the above post on PM Hut (with slight edits). Please use the “contact us” form on the PM Hut site if you’re interested. Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>