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.
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.
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.
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