Webinars

Successful software projects are built on a foundation of well-understood requirements. However, many development organizations get caught in traps that prevent them from effectively collecting, documenting, or managing their requirements. This presentation describes ten typical requirements problems that can sabotage your project. Several symptoms that indicate you might be getting caught in each trap are described, along with suggestions for avoiding or escaping from the trap. The requirements traps discussed are:

• Confusion about what a requirement is
• Inadequate customer involvement
• Vague and ambiguous requirements
• Unprioritized requirements
• Building functionality no one uses
• Analysis paralysis
• Scope creep
• Inadequate requirements change process
• Insufficient change impact analysis
• Inadequate requirements version control

(back to top)

Even well-planned software process improvement initiatives can be derailed by one of the many risks that threaten such programs. This presentation describes ten common traps that can undermine a software process improvement program. The symptoms of each trap are described, along with several suggested strategies for preventing and dealing with the trap. By staying alert to the threat of these process improvement killers, those involved with leading the change effort can head them off at the pass before they bring your software process improvement program to a screeching halt. The risk areas described include: 

(back to top)

Know your enemy! Risk management has become recognized as a critical success factor in software projects. This presentation provides an overview of software risk management. Risk management is the process of identifying, addressing, and controlling potential problems before they threaten the success of a software project. The benefits of managing risks formally are described, along with five ways that organizations may choose to respond to their risks. The fundamental components of software risk management are outlined:

• Risk assessment (identification, analysis, and prioritization)
• Risk avoidance
• Risk control (risk management planning, resolution, and monitoring)

Many common types of risks that threaten the success of different kinds of projects are summarized. These risk areas include project dependencies, requirements, management, lack of knowledge, technology factors, and others. A simple form for documenting risks and planning mitigation approaches is presented, and a practice session gives attendees an opportunity to try using the form. The session concludes with several recommendations for how to begin implementing risk management on any software project. The longer tutorial includes additional material, a description of the Software Engineering Institute’s taxonomy of risks, descriptions of two risk management case studies, and more practice time.

(back to top)

Managing software projects is difficult under the best circumstances. Unfortunately, many new project managers receive virtually no training for the job. Sometimes you have to rely on survival tips from people who have already done their tour of duty in the project management trenches. Here are 21 such tips for success, which I’ve learned from both well-managed and challenged projects. They include 4 suggestions for laying the foundation for project success, 6 for planning the work, 7 for estimating the project, 3 for tracking your progress, and 1 tip for learning for the future. Keep these tips in mind as guidelines for success on your next project, recognizing that they aren’t silver bullets for your project management problems.

Peer reviews are as much a social interaction as a technical practice. Asking your colleagues to point out errors in your work is a learned -- not instinctive -- behavior. This presentation describes some of the cultural and interpersonal aspects of peer reviews and inspections that must be considered when trying to install a review program in an organization. The idea of "egoless programming" is described as it relates to reviews. Suggestions are provided for how a reviewer should present issues to the author in a nonjudgmental way. Some aspects of management attitudes and behaviors are discussed, including ten signs of management commitment to peer reviews. A case study illustrates the risks of managers using defect counts from inspections to evaluate individual authors. Several reasons why people do not perform reviews and ways to overcome them are explored, including factors related to lack of knowledge, cultural barriers, and simple resistance to change. Some of the benefits that people performing different project roles can enjoy from a successful peer review program are itemized. The presentation also addresses some aspects of holding reviews that involve participants from different cultures.

(back to top)

It seems that everyone who wishes to make a mark in the software world feels the need to invent a new model or methodology. Such models provide useful frameworks for structuring our thinking and practices in various subdomains of software development and management. I contend that we don't need any more new, improved models for software engineering at the moment. Instead, we need a majority of developers to consistently and effectively apply the practices that we already know work! The problem is not inadequate models. The problems include:

• Inadequate education and awareness of industry best practices,
• Resistance to change based on NIH syndrome,
• The misguided notion that software is art and hence not amenable to discipline, and
• Lack of personal commitment to continually improve the ways we all work.

This presentation explains why, with some exceptions, I think we don't need any new models at the moment for software testing, risk management, inspection, design methodologies, process improvement, and metrics. Perhaps you'll agree. Perhaps not.

(back to top)