Review: The Software Project Manager's Handbook

The Software Project Manager's Handbook by Dwayne Phillips

My rating: 4 of 5 stars



This is a worthwhile read for software managers if only for it overview of various approaches; waterfall, evolutionary, etc. The author likes a rigid, richly documented approach with complete change management. I am sure most would balk at the corporate resources to support such rigid even bureaucratic, software development and the author admits few reach this level and it can take years to reach fro m nothing. The author is a fan of complete standards, like CMM, IEEE ones and ones from the U.S. military. A final “cookbook” chapter and the appendices detail application to sample projects.

(Bold emphasis mine, italics emphasis is the author’s)

• "Visibility and communication are more important than [choice of technology]"
o “No activity of software development can afford to be invisible.”
• "[Handle] maintenance projects so that no one feels like a second-class citizen"
• One of my favorites: "Choose the best people, keep the team small, minimize distractions, train them, meet together as a team regularly, know them, and set an example"
• Cherry-picked from 1.3.2 Best Practices “a best practices list compiled from the best practices lists of many well-known authors:
o Reviews, inspections, and walkthroughs
o Binary quality decision gates
o Milestones
o Visibility of plans and progress
o Defect tracking
o Testing early and often
o Fewer, better people
o Opposition of featuritis and creeping requirements
o Documentation for everything
 “’vagueness is one of the most common defects in software… [and] the reason for our frequent failures.’”
 “…must be able to trace every requirement to its origin.”
o Change management
o Reusable items
o Project tracking
o Users - understanding them
o Buy in and ownership of the project by all participants
o Requirements
 “…role playing, acting out scenarios, and prototyping user interfaces, are actually visibility techniques aimed at requirements gathering and analysis.”
 Functionality/Performance/Design constraints/Attributes/Interface (p. 112)
• “Avoid having team members work in isolation”
• “Keep…notes of everything you learn”
• “use standards judiciously”
o “Standards have paid off repeatedly.”
o “When standards are dismissed, products are incomplete, everything becomes subjective”
o “If it is a bad construct not mentioned in the programming guideline, change the guideline.”
o “Standards are frameworks that let creative people solve their problems. Without a framework to guide and channel your efforts, ‘creativity becomes meaningless chaos”
• “You cannot build a more difficult product without increasing capability”
• Metrics (to me, for project progress and product measurables)
o “…don’t even hint at measuring individuals for either reward or punishment. Instead focus on process and teamwork.”
• Shared vision. Each member knows where the team is going.
• Group Memory. …documents, papers, on-line information … permits more than one person to simultaneously focus on the collective idea.
• Use walls, actual physical walls, for large and interactive displays of project goals and progress (2.3.1)
• “People don’t always read well-written documents, but they will never read poorly written ones.”
o “Documentation…That’s not bureaucracy; it’s visibility.”
o “An excellent technique is having users write a user’s manual for the system they want.”
o KISS: “short sentences, active voice, and clear construction.”
o “the more complex th3e material, the simpler and more consistent the explanation.”
o Avoid ambiguity
o Make your description consistent
• CM “in place on day 1 of the project”
o IEEE Guide to Software Configuration Management 1042-1987
o “Change control is not change prevention”
• “Act small and early [Weinberg 1992]. Act to steer the project back to its planned course. Large actions usually overcorrect the project… Small actions do not correct enough, unless they are taken early when the difference between the planned and actual is small.”
o “Think ahead and act early and small.”
• “control = status + plan + corrective action”
• “helping the developer create a solution…is the goal of design”
• CRC cards (p. 104, fig. 5.15) seem to dovetail nicely with role-based design goals
• “If you don’t allow time for planning, the project will be behind schedule from day 1.”
o “Time boxing…breaks the project deliverables into periods of time… Developers will do as much as possible until the time runs out.”
o “If time is important, don’t buy time by adding people. Rather, cut features.”




View all my reviews