Note
When I worked in the Kodak Research Laboratories, I had a friend named John who designed new black-and-white films. John began every new project by doing . . . nothing (apparently). I would find him sitting in his office, reading technical reports or research notebooks about similar projects or staring into space. John was learning and thinking and planning before he began performing expensive, time-consuming experiments. By taking the time to study previous experience, John was able to conduct well-designed experiments that efficiently led to high-quality products.
Software projects can derail in many ways. You can avoid making many common mistakes if you study the many books and articles available on software engineering and project management, as well as the lessons your own teams have learned on previous projects. Project initiation is the right time for the astute project manager to learn how to better navigate the project management minefield. Sure, you’re very busy when you’re launching a new project, and taking the time to study existing bodies of knowledge doesn’t seem like real work. However, "doing nothing" while you examine the lessons of the past is a high-yield investment in the future (Boddie 1995). An overconfident project manager, in contrast, will rely solely on personal experience, memories, and the team members’ intelligence and experience to weather any crisis and master any challenge. Hubris, arrogance, and cockiness aren’t a solid foundation for project success.
People have been developing software for more than 50 years. During that time, a number of software development and management techniques have emerged as strong contributors to project success. These are known as best practices. It behooves all project managers and practitioners to become familiar with the established best practices in their domain. Selectively applying appropriate industry and local best practices is a way to benefit from the lessons learned on thousands of previous projects.
Note
Mindlessly following an approach that someone dubbed a "best practice" without considering whether it applies to the context, culture, technology, size, and nature of your project and organization.
Some people don’t care for the term best practices, protesting that it implies a global or absolute standard of excellence. Certainly, practices are context-dependent. Few techniques can be stated universally to be superior in every situation. In fact, I prefer the term good practices to best practices. Nonetheless, there are patterns of practices and techniques that consistently give better results than do others, when thoughtfully applied in appropriate situations. One set of criteria used to select best practices is the following (Fogle, Loulis, and Neuendorf 2001):
Existence (the practice has actually been used; it’s not just a theoretical concept)
Importance (the evaluators of the practice consider it to be significant)
Effectiveness (the practice yields better results than alternative practices)
Tangible benefit (an organization that uses this practice achieves meaningful benefits)
Innovation (the practice might make use of innovative approaches, such as automation of previously manual steps)
High value perceived by users (the practitioners feel the practice works well for them)
Some best practices are collected by industry gurus and consultants who examine many projects for patterns that correlate with success and failure. One such group was called the Airlie Council. In the mid-1990s, the Airlie Council identified nine key best practices for software engineering and software management (Brown 1996). A later report expanded this to 16 best practices (Brown 1999). Six of these 16 practices apply directly to software project management:
Adopt a program risk management process.
Estimate empirically cost and schedule.
Use metrics to manage.
Track earned value.
Track defects against quality targets.
Treat people as the most important resource.
Other collections of best practices come from authors who glean and synthesize insights from the vast body of software engineering literature. One such author is Steve McConnell, whose classic book Rapid Development describes 35 software best practices (1996). McConnell presents the potential benefits from each practice, the effects on project schedule and risk, improvement in progress visibility, and the chances of both initial and long-term success. He also describes how to apply each best practice and the risks associated with each one. Nearly one-third of these 35 practices pertain to project management, in the two categories shown in Table 14-1. Similarly, Verner and Evanco (2005) identified numerous project management practices that are correlated with more successful projects. The single best project management predictor of project success was whether the project manager had a clear vision of the project.
Table 14-1. Some Best Practices for Project Management (McConnell 1996)
Name | Description |
|---|---|
Life Cycle Practices | |
Evolutionary delivery | A life cycle model that delivers small increments of functionality at frequent intervals |
Life cycle model selection | Choosing an appropriate sequence of activities for your project |
Spiral life cycle model | An iterative life cycle model that emphasizes reducing risk early in the project |
Staged delivery | An iterative life cycle model that delivers a product through multiple partial releases |
Timebox development | A strategy of adjusting scope to achieve a useful deliverable on a fixed schedule |
Planning and Tracking Practices | |
Measurement | Collecting and analyzing project data to assist with tracking, decision making, and future planning |
Miniature milestones | Decomposing a body of work into small pieces that can be estimated and tracked easily |
Principled negotiation | A negotiation strategy that focuses on achieving win-win outcomes |
Theory-W management | A project management approach that strives to achieve all stakeholders’ win conditions |
Top 10 risks list | A dynamic list of the most significant risks that pose a threat to project success |
Consultant Capers Jones described numerous best practices based on assessments performed on hundreds of development organizations (Jones 2000). Jones identified different sets of practices as being particularly effective for different types of projects: information systems, outsourced development, hardware-controlling systems, commercial products, military software, and end user software applications. The methods and tools classified as being best practices generally were correlated with productivity and quality results in the top 5 percent of the projects studied. A practice had to be observed in at least 10 companies and 50 software projects before it could be deemed a "best practice."
Note
Assuming that your project (or team, or product, or organization, or whatever) "is different" so none of the learnings from other projects apply to your situation. All projects have their unique aspects, but there are enough commonalities that the project manager ignores the vast body of previous experience at his peril.