This is a method I developed to address issues with new product development. I have since used it heavily, and it has yielded good results. It can also be used to quickly understand a new organization or product line. This is especially handy if you have to move between organizations and products.
Have you heard any of these truisms?
If You Meet the Schedule, You Will Meet the Budget. It is the Marching Army That Kills You.
Protect the Money. You Can Get More Time, But Not More Money. When the Money's Gone, It's Over.
Take The Time You Need to Make it Great. They Will Forget That You Missed a Deadline or Budget, but a Poorly Performing Product Will be Remembered Forever.
If I Can Get The Right People, Co-Locate Them, and They Are Left Alone, We Will Be Successful.
There Is Nothing More Important on a Job Than a Good Spec.
If the End Product is Too Expensive, the Business Plan is Broken, and the Effort is Wasted.
Process Yields Success. Any True Process Yields Reusable Products and Can Be Steadily Improved.
Which of these is the most important? Actually, any of them may be, depending upon the circumstances. When it comes time to make a decision, how do you know what is important? How do you communicate this to others? This article describes a method I developed to address this.
This method will help you in two ways:
Any professional, especially a designer, has to decide how to spend their time on a task - where to park their brain today. This article will help you develop a ordering of priorities that you can use to make decisions on how to spend your time on a job.
When planning a job, there are techniques to sacrifice one priority at the expense of another. When push comes to shove, how do you decide what to do, and how far to go in each area?
This method will not only allow you to do this, but to communicate your vision to others, and where to take corrective action based on feedback or results.
In an Engineering Development Environment, Priorities May Be Described As the Order and/or Weighting of Following Characteristics:
Click on any of the below to get a verbose definition, and methods to emphasize performance of that characteristic.
Schedule - How Rapidly Decisions are Made and Products Are Produced
Specification - Completeness of Specification and Verification
Technical Performance - To What Extent the Specification Parameters are Augmented/Expanded/Exceeded
Non Recurring Cost - Total Cost of Development
Recurring Cost - The Total Cost of a Lot Of Deliverables, Divided by the Number of Deliverables
Resource Constraints - How Available are People, Equipment, Sites
Process - Completeness and Adherence to Published Procedures
This method provides a consistent context in which to make decisions related to the program, the design, and the manufacturing process.
Given a fixed amount of effort, a designer must decide what to do when forced to decide between approaches. If I find a transistor for $0.60, should I keep looking for another cheaper one? is it worthwhile figuring out how to make the operating voltage range wider? Do I do a worst case analysis, or is testing a few points ok? Should I bring in a heavy hitter to make sure we haven't overlooked something?
As a Project Manager, do I design for recurring cost, or is it a dependent variable? If I see an opportunity to improve the performance with more engineering or schedule, do I take it? When do I cut things off due to budget, schedule, etc.?
If you know the hierarchy of priorities, you can be more decisive in making decisions like these, and communicate them to the staff and others. Everyone has this hierarchy in their head, or they are in their bosses office every day, asking what to do next (bad). Projects will suffer if you have some designers emphasizing one characteristic, and others another. You can use this to put everyone on the same page (or try to - see next paragraph). This method allows you to communicate what is important, and let the designers do their thing.
Some designers or functional managers may have a very fixed opinion on the "correct" hierarchy, and will disagree with differences developed specifically for a project. This is especially true when a group has experience in one product area, and is venturing into another. The exercise in creating this hierarchy can be difficult. In general though, most people I have worked with understand that these are the rules of engagement, and will work to them as their abilities allow. And projects that undergo this process are much more focused and end up more desirable to a user community that shares the values of the ordering. This also works very well for proposals, especially if the priorities of your customer do not match the base priority ordering of your organization.
Some facts about about setting priorities:
Each Organization is Different -
Typically, it is set up to handle an agreed upon ordering and weighting, which has been set by the culture
There will likely be historic clashes based on these priorities. You may not be able to fix them, but you should act knowing they are there.
Each Project is Different
Project Priorities are Set by the Priorities of Our Customer, Our Management, and Ourselves
The closer they match our customers priorities, the better – but they won’t necessarily match exactly.
Priorities May Change As Conditions or Understanding of the Program Changes
For instance, if addressing Schedule concerns gets the schedule under control, often the project is changed to introduce more Resource Constraints
Even if you know nothing about spacecraft product development, note how the chart below can help you quickly understand what is important.
Custom Spacecraft Component
So based on this chart, whenever tested, Specification and Process win. That is where the engineers will park their brains.
Below is a practical example of how this can be used: How many slides should I do for a review? What should be on them?
For a 45 minute review adhering to the above priorities, the slide quantity and order would be:
Process = 3 slides
Specification = 3 slides
Performance = 2 slides
Non Recuring = 1 slide
Schedule = 1 slide
Resources and Recurring = 1 slide
Click here to see more examples from actual product analyses.
In this system, the Quality of your design is defined by how closely the end product matches the order and weighting of the priorities. In the example above, adherence to Process is your highest priority. So your quality organization would be centered on following the Process, and not review recurring costs or resources very much.
For historical reasons, formal Quality Organizations typically only monitor Specification or Process, so it is generally accepted that this defines the Quality of a product design. But the other characteristics have their own quality monitoring organizations, and their own concepts of quality.
Below is a typical quality reporting setup for a standard over the counter product. Yours may vary. How much effort is expended by each monitoring activity will tell you something about how much your organization values that characteristic.
These groups provide an independent assessment on how you are doing on each characteristic. You can analyze your organization by looking at the strength and maturity of each of these monitoring functions. If the priority is important, it will have an active quality organization. No effort dedicated to monitoring one of these? It is probably not important - or it is a recurring execution problem that is not being addressed.
If you are doing a bespoke contract, then the customer will most likely delegate monitoring of these characteristics to your Quality department, Project Engineering, or to Program Management. For a design to spec project, the table will typically look more like this:
A company that makes commercial cost competitive products may monitor Recurring Cost and Technical performance tightly, but not be that concerned about Process and Specification. In that case, a conventional Quality organization will be very small if it exists at all. Attention to cost and limit testing will be extensive.
In all but the smallest companies, the monitoring of important characteristics will be very structured and supported by infrastructure. Look for it.
You can find more about the breakout of the responsibilities above in this article on Project Management Responsibilities. This will give you an idea who to ask.
During our development cycles, the procurement time of materials was a serious pacing item. As complete development schedules shrunk to less than a year, some components specified on the very first day of award were holding up shipments for months after the design was completed. I met with procurement to see if we could come up with something to address the problem.
They agreed that their Schedule performance was very bad, and wanted to improve it. So I began to run down my priority list to see what we could do.
Process?
No, that couldn't be changed. They were buying military components with fixed quality standards, and they couldn't sacrifice anything there. It is what it is.
Resource Constraints? Could we bring in some more people?
No, they were an overhead department, with a fixed number of people. As long as our sales were about the same, they could not change their personnel number or mix. Purchasing Personnel required a lot of training due to our Enterprise system, and scaling was out of the question, even if the budget was authorized.
Non Recurring costs? Could we pay more to get expedited delivery?
No, individuals were graded on the overall cost of the components they buy. They would always trade away schedule to get a better component cost.
Recurring costs?
No, for the same reason as above.
Specification? Were we specifying too tightly? To many quality requirements? Boilerplate we didn't need?
Perhaps. Maybe they could send out more surveys, and get vendors more self certifying. But this would take manpower they didn't have. Where would the money come from to rewrite the specs? And that is an engineering job.
Technical Performance?
Not really applicable. The parts they buy are for one application only. Stocking more capable parts (like faster processors or memory) to have them available off the shelf would be possible, but these would cost more than the exact components, and involve other financial penalties, so Just-In-Time is what is performed.
It became clear why their Schedule performance was so bad. Every decision sacrificed schedule rather than any other characteristic. At every turn, in every decision, the only thing that could give was schedule. Is it any wonder their schedule performance was so poor? In fact, since no action was ever taken due to schedule concerns, were schedule requirements for this organization even meaningful?
Result: While our programs were being graded harshly on poor delivery schedule performance based on component availability, procurement was being graded on other factors (resource constraints, process, recurring costs). Schedule had fallen off of their priority list. So as a company our efforts to meet schedule failed, even as procurement met their goals.
Could the schedule be improved in the above example without modifying the other priorities? In the long run, perhaps. But in the short run, as long as everything else was more important, schedule performance was a dependent variable. You get what you get.
What was brought out in this example was that actual changes had to occur in some of the other areas if our overall schedule performance was to be improved. Working harder wouldn't do it. Changes were implemented.
Click here to see more examples from actual product analyses.
Priorities of your organization can be determined by noting:
Which Characteristic Is Typically Sacrificed to Improve the Quality of Another Characteristic
What Characteristic Is Most Examined
Which Characteristic Has the Most Corrective Action Applied
What Is the Perception of Final Acceptable Quality of Each Characteristic
You can do some detective work yourself.
Are the weekly labor runs made available, and is feedback required? Monthly? At all?
Are projects held up if the requirements documents are not clear or complete?
Does a poor schedule projection lead to new people being made available?
Is the projected recurring cost part of a regular review?
Do features just turn up or get axed suddenly during development?
Do projects wait if the right people are not available?
From an organizational point of view, this is best hammered out in a meeting with all the relevant stakeholders. After a brief presentation, the stakeholders will grasp the concept quickly, and the ordering and weighting will gravitate to a logical conclusion. If there is a strong figurehead, s/he may want to order and weight the priorities, and hold an individual meeting to get feedback. Also, this meeting may evolve into where you are going, not where you are.
It is important to do this in a meeting forum, in that many of these are cross departmental. A lot of good info is exchanged in getting to the bottom of what the emphasis of the organization should be. This part of it is pretty easy. Everyone in your organization probably knows this priority ordering.
There is also objective evidence of hierarchy. There are three basic levels of quality that are typically applied to these characteristics:
Zero Quality. No specific monitoring or reporting method is in use (as in the Spacecraft Recurring Cost example above).
Periodic Monitoring and Reporting performed by the Project Manager (for example, using MSProject to project schedule performance)
Periodic Monitoring and Reporting performed by a separate, dedicated organization. Reports are provided to the Project Manager, or reported independently.
For example, on high volume, design to cost products, expected final product cost would usually be reported using #3 above. Operations would tell us where we were. On development programs, engineering labor cost would be reported using #3. On our Space programs, final recurring product cost was zero quality, because it was typically less than 10% of the overall program cost.
A basic chart showing the results of this analysis can be very helpful to understand your organization. Of course, organizations can be very complex in these matters, but this will get you started.
Determining your built-in organizational hierarchy is important, in that you may discover that you have customers, current or potential, who have different weighting. This is where the fun begins, in that an excellent opportunity may be a mismatch for your current weighting. This is also important if your are looking to branch into new markets with a technology or capability. See the Examples for a situation where our organization did not match an opportunity that looked good at the start.
Once the job is awarded, whether internal or external, a meeting should be held to order and weight the priorities. In this meeting are the Project Manager, Sales or other customer representatives, and other stakeholders in the outcome of the project. Once the hierarchy is hammered out, it should be presented in the kickoff, and at the periodic reviews as a reminder, or to notify the stakeholders of any directed change to it. With a 30 minute training session, most designers will get the point quickly, and will be able to make their own decisions based on the requirements.
As a project manager, at monthly reviews, I presented our progress in the order of priorities as a reminder. If NRE was #1, that was the first thing I covered, and in depth, with several slides. Sometimes this was schedule, sometimes Recurring cost, sometimes Requirements. The next priorities followed, depending on the order. The last two went on the same slide, and most times we didn't even talk about them.
Another powerful feature of this method is that if the priorities of a program have to change, there is a mechanism to communicate this clearly. If Schedule is a problem, and everyone works on fixing it, solutions to the problems may make it no longer a problem. I have found that changes of a few positions up or down one every month is about right. Since this is strategic, and meant to enable the designers. I don't recommend frequent updates.
Click on the links below to get more information on the definition of each characteristic, and on how to emphasize any of these on your project.
For practical information on how to beat a schedule or budget, click here.
To learn about dirty tricks, click here.