What Does a Great Product Development Group Look Like?

Introduction

YouTube videos of this article are at:

https://youtu.be/rvnlV-DLnjc (part 1) & https://youtu.be/wB21f1da6PQ (part 2)

Since 1989 we have been traveling the globe looking at great, and sometimes challenged, organizations. From an engineering and management perspective, here are some common “great” things we see.

As you read them, contrast with your organization and determine where you would like your group to be.

 

Deadlines, budget and project status

• Goals are established, clearly defined, and communicated to the organization. These are usually related to deadlines, budget and quality (e.g., defects or customer satisfaction). One group even had a profit goal as their primary measure!
• When data becomes useless or abused, the measurement system is refined.
• Project team members determine what they can accomplish based on historical estimation data, and this is constructively negotiated with management, marketing and customers. People have the time to do the work, and they know that unnecessary padding will be ferreted out.
• Everyone assesses risk. Risks are prioritized and communicated to management at least monthly. Management focuses on risks, not crises. Crises are rare.
• Communication is amazing. The Project Manager (PM) determines what information people need to know and when. All stakeholders are kept abreast of progress, issues and risks. The phrase, “No one told me,” is rarely heard.
• Teams that have dependencies on other teams develop integration points that are managed by Integrated Product Teams. These cross-functional teams are identified on the master schedule. Cross-team issues are worked proactively.
• Project teams track their status every one to four weeks and report data to the PM. He or she addresses the issues and takes care of the team. Team members think their PM is amazing. Sticky issues are addressed early.
• Projects typically meet deadlines within 5-15% of the original budget, unless there is an agreed-upon change or delay. This level of predictability allows the organization to deliver when expected, receive revenue on time, and avoid penalties.

Engineering

• It doesn’t really matter what life cycle is used in the beginning. Mature teams that started with Agile add practices to address requirements elicitation, design, test and advanced project management. Waterfall teams add in prototypes, risk mitigation and incremental delivery to obtain early feedback. The life cycle is matured to fit the goals of the group.
• Customers and end users are actively engaged in product definition, both for speculative and customized products.
• Requirements are elicited from the customers and real end users. The team helps the customer determine what they want to do with the product.
• Requirements are prioritized, and the team decides when in the project to address ambiguities.
• Requirements are written down, thoroughly reviewed with the larger project team, and baselined.
• Questions, ambiguities and issues are managed, and all stakeholders are involved when there are changes to requirements.
• High-risk requirements are analyzed and prototyped to determine feasibility and the best approach.
• Design is performed in iterations, and lightweight and clear design information is captured in an organized and central location. Designs are reviewed for errors and are updated as changes occur and the team learns more.
• Early versions of components, and groups of components, are tested to determine their correctness. Anything with a high risk is worked on early to minimize surprise and allow time for recovery.
• Components are integrated in the order that finds the most defects first. Integration is carefully thought out to maximize team efficiency.
• Interfaces are carefully designed, defined, communicated and managed when they change. Dependent teams know how they impact each other.

Quality and rework

• Peer reviews are done throughout the project to quickly find defects that can be found. There is no throwing stuff over a wall to see if anyone notices the quality problems.
• Metrics are analyzed to determine quality, such as: the components that have the most defects, trends in the type of defects found, and an objective picture of the current status of quality.
• Final tests are executed to show that the system actually works with the customer’s data and situation. If the real-life situation is unavailable (e.g., heart attack, war, drowning), simulation data are used.
• The amount of rework and bug-fixing is typically between 5 and 10 percent of the project staff assigned. This compares with a typical amount of between 40 and 90 percent in organizations that are more challenged.
• If quality standards and frameworks are used (such as Scrum, PMBOK, CMMI and ISO), they are integrated together with a view that reflects how the teams want to work.

The correct versions of documents and code can be located quickly without guesswork

• Documents and code are labeled, versioned and stored in well-defined locations. When the test group wants version 6.2 of an application, they can find 6.2 in a few minutes. When developers want to find version 5.9, they can find it and know what changed without guessing.
• When managers want to find version 1.0a of the contract, it can be located. If they find 1.1, the history log shows what changed. No guesswork and wasted time.
• Customers are always sent the correct versions of deliverables.

Suppliers are selected on their merits, and performance and risks are monitored to minimize surprise

• Criteria are used to select suppliers.
• Agreements are established based on the complexity of the work.
• Statusing occurs to determine supplier problems before it is too late.
• Deliverables are accepted based on acceptance criteria.

The organization learns from its mistakes and has a systematic way to collect, prioritize and distribute lessons and new skills

• Good ideas are collected and shared across the organization.
• Cumbersome and non-value-added practices are identified and fixed.
• Existing skills are provided to new people, and new skills are provided to existing people.

Management (as perceived by the staff)

• People think all levels of management are on their side, generous with money, and creative in seeking new business and opportunities.

Your conclusion

How does your organization compare? What would you like to do differently?

Looks unachievable? It’s not, you can do this. For further ideas and complimentary discussion, contact us.

[Forward this article to your boss! Subject: Here’s a cool tip for you] Quick Link