I read the article Product Beats the Process and felt compelled to respond
Product Beats Process
The author, Jeff Morris Jr. is right, the populous or customers at large probably do not care about how we arrived at the product. They do not care about the process. They do not care about the creative problem solving that went into bringing the product to life. They do not care about specific Jira or defect report tickets. They do not care about long hours, personality clashes, and design trade off curves. However, I disagree when the author says they only care about how it feels in their hands and nothing else. This disagreement is not based upon some statistical analysis so, perhaps he is correct. It is however, based upon my personal priorities and experience, and I find it difficult to believe that I am a singularity.
What matters is that we build products that make customers smile and realize something … Continue reading
If we have developed a product that is useful to our clients, our production volumes will grow allowing us to improve our product cost and pricing structures. Additionally, besides the volume purchase of material cost improvements, we will work with our manufacturing line, improving those processes and subsequent first pass yields thereby reducing the associated rework costs. We may choose to steadily drive our price down also to increase the number of consumers benefiting (as well as our company). It is possible to both reduce the sale price of the product AND improve the profit. This situation is unlikely to last for long as other potential suppliers see our success and want to follow our lead with their own offering.
We will see further coverage or refinements in our product delivery methods. We can see securing other contracts for the product with more customers over time, adding to those we have already acquired so we see the amount of the … Continue reading
A contingency in project management is a reaction plan to an untoward event; in short, we plan ahead for the failure of a given task. In order for a trigger to “fire,” we must set a threshold value that activates the trigger; otherwise, the trigger should never fire.
Thresholds can be set based on financial, schedule, and quality anomalies. For example, if our project is running more than a pre-decided percent of the budget at a specific milestone, we would expect to trigger corrective action up to and including executive involvement in the project. Budgetary deviations are bad enough, but it not uncommon for projects to run into scheduling issues. We want the schedule triggers to fire as early as possible for the following reasons:
Immediate corrective action Inform the customer, even if internal Bring in upper management to see if barriers need to be removed
Unfortunately, quality issues and their associated triggers are often unfired until late in the … Continue reading
by Kim H Pries
When we are engaged in prototype development during the early to late middle phases of our new product delivery process, we usually purchase components through maintenance, repairs, and operation (MRO) purchasing. This type of purchasing is managed on an as-needed basis, and often, is not automated. We purchase the parts we need in relatively small quantities because we are not yet in production. At this point in our process, this approach is reasonable and effective. The part cost is high but we are not at risk of having any parts we need to throw away.
As we move through the process, however, we reach a point where we begin to transition from prototypes to sellable products. For these products, we most commonly use manufacturing resource planning (MRP) purchasing, which is nearly always automated. As developers, we have seen huge discontinuities in delivery when shifting from MRO to MRP purchasing. MRP purchasing has some different characteristics:
• … Continue reading