Can a group of software developers, located in Mexico, achieve CMMI® certification and set the standard for their larger U.S. parent company to follow? A software branch of Freescale Semiconductors Inc., located in Guadalajara, did exactly that. Developing the CMMI® processes and procedures that made business sense for a remote software group was tricky, but not as tricky as assuring that they aligned their practices with the parent company's processes and requirements. The months of work that led to this achievement were filled with high points-and big challenges. Jeff Fiebrich discusses the planning, budgeting, and implementation that contributed to their ultimately successful CMMI® certification. He addresses the collaboration between their parent company and the local government that was an essential part of this effort. And, most importantly, Jeff reveals the immediate impact of their certification on the entire company.

Project managers generally run a project based on the development methodology used by their company. If a product is developed in a traditional, more waterfall manner, project managers will slip into management techniques of heavy documentation, weekly status meetings and reports, and a “tell them what to do” mentality. On the other hand, if a product is being developed in an agile manner, then minimal documentation, daily stand-up meetings, and team-based direction will be more the norm. Brian Watson describes how his organization has incorporated many agile management techniques into all projects regardless of methodology required by the client or sponsor. They have successfully adapted their internal agile methodologies for clients that demand waterfall or spiral project reporting. The client sees the facade of a waterfall project, while the project is managed in an agile manner behind the scenes.

Performance measurements have now become a mainstream management practice in many, often large, development organizations. Equally important to establishing strategic goals and objectives is identifying an appropriate set of measures to provide quantitative evidence that those goals and objectives are being achieved. David Garmus describes a project performance baseline that can be implemented throughout your organization or at the department level across multiple projects. These measurements must be matched to the business needs of stakeholders, not to the technical aspects of the project and process. For increased learning, measurements must be compared among projects, departments, divisions, or the entire organization. While quantitative measures are preferred, qualitative measures can also be very useful.

Organizations have traditionally relied on project postmortems to assess the performance of product development teams. The irony is that "postmortem" literally means "after death," implying a discussion of project failures. These reviews, held at the end-either the completion or cancellation-of a project, often do not create a safe environment for team members to express their opinions. Postmortems rarely result in fundamental improvements in the development process as "lessons learned" sessions quickly become "lessons forgotten." And because they come at the end of the project, they have no chance to positively impact the current project. John Terzakis introduces the concept of retrospectives to address these problems and contrasts these two review methods.