Product Development Processes

Product development processes are tightly coupled to those of project management. What are the fundamentals of a product development process? Will a product development process get me to market faster or slow me down? Will it cost more than fast and loose ad hoc methods? How formal does a product development process have to be? Does it have to be written down to be effective? Are there standards or guidelines to help me? Software product development seems to be an especially difficult discipline -- is there any special help for software development processes?

• Our new QA and Beta Test Manager Job Descriptions show the true breadth of these roles done right, and can help you engage and deploy these team members effectively throughout the project.
• The Sooner you Start, the Later you Finish ... according to this article on one aspect of the philosophy and methods known as Critical Chain Project Management (CCPM). CCPM has some very interesting paradigms that may contradict some approaches to project management that we may take for granted - for instance, focusing on managing to eliminate project bottlenecks, rather than on hitting near-term milestones and managing task completion. This site has a number of comprehensive tutorial articles on topics such as Critical Chain and Risk Management, as well as a set of CCPM Frequently Asked Questions.
• If you want more on CCPM and TOC from the father of it all, see Avraham Goldratt's site at http://www.goldratt.com/, especially his articles page, which includes a number of case studies on how CCPM has been applied in different industries; and a new white paper explaining TOC Project Management.
• For a front-lines look at some techniques for implementing better PM in a company, and improving product development practices, see our interview with Neil Love titled Career Highlights and Favorite Techniques - Improving Project Management and Increasing Its Perceived Value. In the interview Neil provides examples from his various PM-related roles for coaching executives on how to add value to projects; helping groups see what aspects of their processes should be tackled first and getting them to do it; helping cross-functional groups work together better to improve project outcomes; and more.
• The Software Release Life Cycle Overview describes a Software Release Life Cycle (SRLC) targeted for software-heavy development environments, either pure software development or product development with a large software contribution.
• Introduction to Software Release Trains provide an alternative release schedule for organizations that need more predictable, efficient release management.
• There is a wealth of resources for establishing and improving a software development process at the Software Engineering Institute web site. See the site's Management Practices area for process improvement help. Also check out their extensive documentation in the Publications area. Much of it can be downloaded on-line.
• If your project is risky, uncertain or otherwise messy, and you aren't sure how to plan it according to traditional techniques, check out our template on using Spiral/Iterative Project Phase Approach. It provides an example from an actual project of how to use such a model, along with time-boxing, to plan and execute a project. The spiral model is a risk-oriented lifecycle model that breaks a project up into mini-projects. Time-boxing refers to a technique for setting interim and end-date goals and developing features in priority order until each deadline is reached. Together these approaches provide a way to execute a project in an orderly manner in spite of high risk or uncertainty. Our template shows in detail how a team planned and executed a software development project using these techniques.
• We've heard growing interest lately about rapid software development techniques, and specifically the RUP (Rational Unified Process) methodology. If you've been looking for info too, here are a few interesting links.
  • The Rational Edge provides a good overview of RUP key philosophies in The Spirit of the RUP.
  • Making RUG Agile, originally presented at OOPSLA 2002, is a case study with a list of artifacts (documents) created by the project.
• This excerpt from a company's "Development Process Quick Reference" shows a format and content examples for helping your team use your project management or product development process. Often those processes, housed in a "big binder", can overwhelm teams, and end up not getting used at all (especially if your teams have to execute projects of different sizes and types, and what works for one is overkill or inappropriate for others.) The Quick Reference format provides the team with a small-page-count "workbook" for deciding what standard deliverables and activities their new project should do. It also provides a format for "FastTrack" sheets that give the team the "formula" for specific types of projects.
• Determine if an idea is worth enough to the company to commission a product development project using this Opportunity Screening Worksheet. The management team at your organization can use this worksheet to evaluate a number of factors in determining if a new product development project should be undertaken and identify the important issues in making that decision. The worksheet is written for analyzing a specific product idea - with respect to the market, the company's capability, potential market risks, return to the company, etc. With some deletion of items and minor modifications, the worksheet can be used for a benefits analysis for projects other than product development projects.
• Our booklist contains a number of excellent references on product development processes.
• Check out our list of project deliverables templates -- they're listed by phases of a typical project and can provide valuable time-saving material for each step of your product development project.
• Our Know-How on Implementing Project Management has resources and answers to burning questions on this subject-- many items pertain not only to implementing project management techniques, but specifically improving your organization's product development processes.
• The following files define recommended deliverables for the first 4 phases of a Software Release Life Cycle, focused on planning a major software release composed of multiple projects. The guidelines provide a one-to-two page detailed definition of each deliverable in the phase, defining Purpose, Audience, Prerequisites, Driver (who should drive or take responsibility for this deliverable getting done), and a detailed checklist of "recommended accomplishments" - what the deliverable should contain. These phases provide an upfront process that ensures all sources of requirements are considered, while helping cut through the clutter of all the things that COULD be included in a software release, to ensure the release focuses on important features and projects, AND is humanly possible to complete in the alotted time!
    Phase 1: Preliminary Requirements Gathering
    Phase 2: Scope Definition
    Phase 3: Planning and Negotiation
    Phase 4: Release Plan Refinement
• Software Release Life Cycle Phase 8: Internal Testing defines testing and review activities to run a software release through its final paces internally before being exposed to an external customer.
• Software Release Life Cycle Phase 9: External Testing defines testing and review activities to exercise a software release in a "real world" environment at one or more customers.
• Software Release Life Cycle Phase 10: Delivery covers the final close out phase of a software release project. Includes some final quality activities that make sure the release and derivative products are manufacture-able and replicate-able and includes a process improvement deliverable on Lessons Learned.
• Our Leadership and the Project Lifecycle template provides a table showing the evolution of leadership responsibilities during the different phases of a project. This table can be used as a guide for selecting people with the right leadership and management attributes to lead projects, and it can be used to educate new project managers on how their role is influenced by the activities of each project phase.
• Our Localization Guidelines help project managers and project teams adapt a product built for release within the U.S. or North America to other international marketplaces. The costs and effort involved in localization and later sustaining of all the localized products can be prohibitive. ROI must be carefully considered and localization efforts planned thoroughly. This document provides good background for selecting a localization vendor, organizing the project, setting up a localization team, and planning the scope and activities of a localization effort.