From the Yellow Notepad: 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.

Basics

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.

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)

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

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.

4 Responses to From the Yellow Notepad: Project Management

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.

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.

Pigeonholed…

Medical disclaimer…

I am not a doctor and do not have any medical training. Your diabetes may vary. You should always check with your health care team before making any changes to your diabetes self-management or exercise regimen.