# 4 - Product Development Process

Nearly every large company today has defined an internal product development process (PDP). This captures the methodology of product development, including the terminology, stages, milestones, schedules and lists of tasks and outputs. The intent of the PDP is to provide a framework that captures the wisdom of previous development efforts and provides standard processes and approaches (lessons learned from past development).
One of the principal advantage of a PDP is that it is a tool for reducing ambiguity by defining tasks and responsibilities. It is a good starting point for examining upstream and downstream influences and a good method to drive early ambiguity from the system.
Going back to the previous post, flexible projects are emergent, that is, they emerge during the project according to its needs. Guiding this emergence requires skill and experience with development processes to appreciate what is essential and what can be eliminated or modified under the circumstances. One way to enhance flexibility in processes without opening everything to an ad hoc style is to standardize processes in the lower layers and leave the upper layers open for creative adjustment and emergence. This means having standard, established ways of running a certain kind of test, preparing a drawing, procuring a prototype part, determining tolerances, and so forth. Then developers can combine these basic processes in creative ways.
Product development processes tend to be overly burden. Often, staff experts or process development teams create the process by focusing on the firm’s major projects and adding items that other projects conceivably might need. The result is overkill for all but the largest projects the company undertakes- a one size fits all approach. In my opinion, the roots of this problem are in natural human tendency toward security. Attending an all you can eat buffet, many of us eat more than we should because it all looks so « necessary ». We keep things in our attics that we might use « someday ». We travel with items in our suitcases that we never use. The penalties for such behaviors might not be severe, but in product development, excess baggage inhibits flexibility greatly.

As a result, the agile software community have found that the best approach for a flexible project is to start with a minimal process ans add items to it as you discover that you need them, what the agilist call a « barely sufficient product » or « Minimum Viable Product » (MVP).

Comments

Post a Comment

Popular posts from this blog

# 11 - Model-Based Systems Engineering (MBSE)

The best way to understand the MBSE approach is to begin by understanding the alternative: what modeling partitioners call the document-based approach to engineering (and what nonpractitioners call "the way we have always done things!"). With the document-based approach, engineers manually generate some subset of the following artifacts: concept of operations (ConOps) documents, requirements specifications, requirements traceability and verification matrices, interface definition documents, systems design specifications and speciality engineering analysis such as analyses of reliability, FMEA, etc. Document-based systems engineers produce these artifacts in a form of a disjoint set of text documents, spreadsheet, diagrams, presentations (and configuration-manage them in a disjoint set of repositories). The document-based approach is expensive. More precisely, it's more expensive than it needs to be; you incur a significant percentage of total life cycle cost maintaining t...
Read more

# 10 - Principles of Dynamic Work Design

Image
Consider a well-known example of work and organizational design, Toyota’s Andon cord. In the Toyota scheme, a worker noticing such an issue is supposed to pull what’s known as the Andon cord (or push a button) to stop the production line and fix the problem. While the management literature has correctly highlighted the importance of allowing employees to stop the line, what happens after the cord is pulled might be more important. When one operator on the factory floor is struggling to complete a task in the allotted time, and so hit a yellow button, causing an alarm to sound and a light to flash. Within seconds, the line’s supervisor arrived and assisted the operator in resolving the issue that was preventing him from following the prescribed process. In less than a minute, the operator, now able to hit his target, returned to his normal routine, and the supervisor went back to other activities. A visual of this process can be seen below: What, from a work design perspective, happened...
Read more

# 12 - MOEs, MOPs and TPMs

Let's start by defining these acronyms: - MOEs: Measures Of Effectiveness - MOPs: Measures Of Performance - TPMs: Technical Performance Mesures Following a recent discussion on this topic, I've come to realize that there is a lot of confusion around these concepts, so let's try to bring some clarification! MOEs, which are stated from the acquirer (customer/user) viewpoint, are the acquirer's key indicators of achiving the needs for performance, suitability and affordability across the life cycle. The MOEs are used to validate the system at each stage of the design process and provide insight into some of the more subjective qualities desired by the acquirer that are not, or can not, be captured by hard requirements. Many of the "ilities" are used in MOEs where, for example, it may be very difficult to generate a shall statement on operability, but operability nevertheless remains an important characteristic. MOPs measure attributes considered as important to e...
Read more