Foreword
I started writing a book on the subject of engineering process but shelved it to make a living. Now, in an age of incompetent government, it has more relevance so I resurrected my notes and flavored them with this theme.
This post is intended for people who solve problems for a living. It focuses in spots on the specific field of product development and design engineering but the concepts are applicable to all fields of endeavor.
We are all engineers at heart because engineers solve problems. Electrical engineers, mechanical engineers, civil engineers, biomedical engineers and computer engineers solve problems of a technical nature. Everyone else solves problems of business, financial, health, security, political, spiritual and other sorts.
There are many courses of study regarding project management, project planning, project implementation, project leadership, team building, building relationships, negotiation, conflict resolution, scheduling, budgeting and so forth. However, there really isn’t any formal course of study of actual engineering processes and practices. There is one book on the subject but it has only a single chapter on process.
My sister Andy (who I miss very much) once remarked at the high degree of discipline that must be required to do the design engineering design work I did during my career. I thought about that for a moment and then told her that I thought this must also be true of the work she does: she was a college graduate just like me, she was asked to work on a constant stream of problems to earn her degree and she solves problems daily on her job using a bureaucracy that was heavily laden with documentation requirements.
I told her that if didn’t know she was a parole officer, I’d say her training and work profile were just like those of an engineer. Her tools were different, her methods were different, her problems were different but we both solved complicated problems for a living.
I’ll admit that the best engineers I’ve known are highly disciplined but I’d wager that this is true in most, if not all, fields.
The purpose of this post is to examine the most widely used process employed in the product development and design engineering community to create solutions to the world’s problems, needs and wants.
It should be recognized that there are many people of many disciplines that will benefit from the study of general problem solving techniques.
For example, our government could benefit from process and discipline. Government is an amalgam of players with differing agendas. The process they use is chaotic at best and destructive at worst. I see no discipline whatsoever outside of Robert’s Rules.
Projects
All but the most trivial problems can be thought of as projects since the word project implies planning. Engineering projects usually progress in discrete steps and invariably begin with a problem and a set of requirements that define the scope of the desired solution.
Individuals and companies tend to organize their projects in different ways but the successful ones tend to start with requirements and end with verification that the requirements have been met.
For example, suppose we’re going on vacation. We require travel, lodging, dining, entertainment plans, and so on. Most of us also have budgetary and timing constraints. We may also have some additional things to accomplish beforehand like taking care of subscription deliveries, mail deliveries, automotive maintenance and the like. In the end we’ll have memories, photographs and stories that our friends and families can use to judge the relative success of our vacation.
The Process
In engineering projects, after identifying the problem to be solved we start with the requirements.
In step one, we define the scope of the project in terms of what needs to be accomplished, how long it can take, how much it can cost, what resources are required and what benefit can be derived by having completed the project successfully. We also study the risks associated with the project.
In step two, we consider all conceivable alternatives that might be employed to meet the requirements laid down in the first step. We convert the requirements to something called a functional specification. In highly complex projects, the specification might be written in more than one functional piece, particularly if portions of the project are to be performed by an outside resource or subcontractor.
The functional specification drives the remainder of the project because it describes in precise, measurable terms what the solution must entail. The functional specification is reviewed to ensure that it embodies all of the requirements laid down in step one. While the specifications are essentially trade secrets, we share the overview with the intended customer(s) to ensure that the product will meet expectations.
In step three, we begin the process of developing the solution. The alternatives identified in step two are evaluated in detail. We develop models of the various solutions and use them to simulate behaviors. The various parts of the best solutions are documented for review by our peers and supervisors. The solution sets are refined by iteration of the design and review processes. The review process culminates in a set of detailed design information that conforms to all aspects of the functional specifications.
During this time, some aspects of the design might be identified that require additional resource like equipment, customized components, unique components that are not available off-the-shelf. In this step we also develop a template for the testing and verification activities required and that these actions will provide coverage for all requirements.
At the end of step 3, we have documentation suitable for a manufacturer to construct a first article (or prototype) for evaluation.
In step four, we build the first article (often more than one) of our solutions and verify that these models or prototypes meet the specifications and detailed design capabilities envisioned in steps two and three. We also make changes to our documentation to correct deficiencies discovered during the manufacture of the first article.
We integrate the various portions of the solution and verify that all of the components of the solution work together as expected. Finally, we update documentation of the integrated design and the methods that were employed to test them. During this part of the project, a formal test plan is developed by an objective third party. This plan uses the detailed design information and the functional specifications to verify compliance. We also develop training materials for the manufacturer and customer.
In step five, the formal test plan is executed. Ideally, this plan is developed with input from the “customer” in whose interest the project was initially undertaken. As in the third step, there might be some iteration as the solutions converge on the requirements and specifications.
It is important to note that the testing in steps 4 and 5 often consumes as much as 50-70% of the schedule. If your schedule doesn’t reflect this reality, rethink it.
Subsequent steps might be taken here to construct and evaluate pre-production copies of the solution to verify that the recipe (documentation and training) is correct and to have the solutions tested by actual “customers” under real-world conditions.
There might also be some steps taken to upgrade a solution because of obsolete components or to remove a solution from service because a better solution has been found. In my last design, a memory chip I used was updated by the manufacturer three times is the course of the three-year project duration.
The point is that all projects have discrete, definable stages associated with them. The remainder of this post will delve more deeply into the nuts and bolts of accomplishing them. The post will also touch on the notion of multiple, simultaneous projects since the plan for a single project that seemed possible may be viewed differently when scant resources and bottlenecks within an organization are taken into consideration.
When I worked at Lucent/Bell Labs, they called this the Gate Process. At another company it was called the Phase Review Process. Different names, same discipline.
I don’t know what sort of process was used to develop the Affordable Care Act or the website software to support it but I’d wager that there was no discipline; here’s where majority rule can cause problems.
Government often deviates from the national Specification in that it does things that are not required, raising costs all around. For example; huge government debt increases the cost of living just as personal debt does by way of monthly payments.
Requirements
Without a doubt, the requirements step is the most important part of a project. A missing requirement, a wrong requirement or an extra requirement can all have dramatic impact on the cost, duration and resource requirements of a project.
I did design engineering work for about 30 years with 17 different companies and of all of the things that I have seen cause projects to fail, this is, by far, number one.
As a product developer, nothing hurts worse that putting one’s heart and soul into a project only to have it stopped because the result would not meet the intended requirements or because there was a more obvious or better solution that was not foreseen or the product was developed for a non-existent market. This reality led me to become more of a gun-for-hire than a company man.
As an American citizen, I am concerned about the fate of future US engineering graduates since industry seems now to be involved in the wholesale export of engineering jobs to third world countries where engineering talent can be purchased for a fraction of the average US engineering wage. Engineering and innovation built this country. Fast Food and health care will not sustain it.
I will briefly get up on my soapbox and proclaim that if US corporate management were to insist on better requirements, the actual cost of engineering would be quite tolerable since the efforts of the engineers and the rest of the corporate resource pool would not be wasted on restarted, killed or useless projects.
I was once asked by a corporate big shot what I would change about his company. I told him I wished we built stuff that people would buy. He didn’t like it but it was a prescient statement since the next project was an all-in fiasco that nearly killed the company; it worked well enough but nobody wanted it leading to unemployment for 80% of the employees. Now I’ll get off of my soapbox.
Requirements are important but they are also difficult to get right. They require a great deal of up-front study and research, usually in a very narrow field of view. In the product development environment, the requirements almost always revolve around the need or want to do something faster, better or cheaper.
Examples
There are many different kinds of requirements categories and even more specific requirements within each one so I’ll list a few common categories and specifics.
- Cost
- Ease of use
- Environmental
- Temperature
- Humidity
- Altitude
- Safety
- Electrical
- Material
- Fire hazard
- Choking hazard
- Shock
- Explosion
- Shipping
- Size
- Weight
- Cost
Of course there are potentially thousands of categories and countless specifics but these are fairly common in any functional specification.
Even for a specific requirement, there might be some underlying requirements as well. As an example, take shipping cost. Shipping cost comprises not only the cost associated with the shipper (FedEx, UPS, etc) but also with the shipping packaging, warehousing and possible return of goods damaged during shipment. As a secondary example, the shipping packaging may need to be designed for maximum packing density in one of the containers used on container ships and trucking operations.
I have worked in many different fields from semiconductor fabrication equipment to consumer do-it-yourself gadgets to commercial and military communications equipment design. Each field tends to have its own set of constraints and the failure to consider any one of them is likely to have negative impact on the project as a whole.
Top-level product/project requirements are usually formulated by folks in the marketing group, often by assessing feedback from the sales and distribution arms of a business. These top-level requirements are then fleshed out by engineers into detailed requirements that are testable.
Requirements are usually subjected to the scrutiny of engineering architects. An architect is generally an engineer that has been around the development process long enough to have acquired broad knowledge in one or more of the disciplines needed to develop specific sorts of products. The architect reviews the requirements and then applies this knowledge to them to flesh them out to a form called a functional specification. I was an electronics hardware architect.
Common Requirements
As was noted above, there are many different kinds of requirements categories and even more specific requirements within each one. Here, we’ll briefly discuss the sorts of things that belong in a functional specification.
Cost Target
There is a tendency to forget that the purpose of this activity is to make money. Don’t ever forget this key fact.
Presumably, before any requirements-giver approaches an architect regarding a functional specification, some serious thought has been given to the notion of cost. The cost target is a critical requirement for without it, there is a sort of unlimited freedom given to the designer.
The cost target is a tricky number and each company tends to view it in a different way. Some will say that it is just a “bag of parts” cost (the engineer’s preference). Other will say that it is the cost of buying the parts and assembling them (nearly impossible to estimate). Still others will include testing costs, tooling costs and even amortized development cost (this is management’s preference but even harder to estimate accurately).
However it is calculated, it forms one of the primary constraints of the development process.
Sometimes it is a great simplifier.
Consider the requirement for a 500 HP, gasoline-powered internal combustion engine with California emissions that must cost less than $500 (including parts and assembly labor only). The smallest amount of research (in this case, less than 10 minutes on the Internet) will show that a conventional 4-cylinder engine with about 100 HP costs an automaker somewhere between $600 and $700.
Project done.
Sometimes cost must be balanced against risk. A brute-force design might be more costly than an efficient one but efficiency often entails more risk of failure.
Environmental Conditions
It is also important to specify the environmental conditions a product must undergo. These environmental conditions should be specific regarding the differences between shipping and handling conditions and in-use conditions.
Here, the designers are interested in the simple things like temperature and humidity but they may also be interested in vibration, mechanical shock, altitude/barometric pressure, salt spray, corrosive gases, explosive environments and so on.
I once worked on a project involving communications with lasers between buildings. We had a specification for both the frequency and amplitude of building sway.
The important thing to consider is that most of the worst-case conditions can occur simultaneously or in the order that wreaks the most havoc.
Mechanical Interfaces
Virtually every product has some sort of mechanical interface.
Many of these are standard interfaces for things like kitchen appliances since they must fit correctly into a large number of kitchens that will require replacement appliances at some point.
Other mechanical interfaces are standardized for the benefit of the designer. These are things like screw sizes, clearance-hole sizes, automotive wheel sizes and so on.
Some mechanical interfaces are of the custom, one-of-a-kind variety. For example, let’s take the Space Shuttle cargo bay. For a shuttle mission, the payload must fit in the cargo bay (about 60’ x 15 feet in diameter) and it must be maneuverable by the the shuttle manipulator arm (in a zero-G environment). This payload would have dozens, if not hundreds of mechanical interface requirements.
Electrical Interfaces
Many of today’s products have an electrical interface to a power supply mains, a battery, a solar panel or something else.
Power supplies are different all around the world in terms of voltage, frequency, power and the plug that is used to make the connection.
Communications systems have many variations in this regard also. Even something as ordinary as a telephone has a variety of styles in wide use; ground-start, loop-start and fives types of E&M interfaces.
Battery connections are also wide-ranging from consumer styles like AA, AAA, C, D and the “transistor radio” or 9V battery to the heavy-duty batteries used on motorcycles, cars, trucks and boats.
Human Interfaces
This is an area that is nearly always interesting. Everyone likes to get into the act here because it is an area where even the most technically illiterate among us can make a contribution.
On the low-end we have things like manuals and assembly instructions. I say low-end not to trivialize but to categorize. To be sure, poorly written manuals and assembly instructions have probably been the cause of more damaged and returned products than can possibly be imagined. I saw a VCR with the manual provided on a tape!
Next up on the scale are items like light-emitting diodes (LEDs), beepers, buzzers, vibrators and audio feedback (remember the “fasten your safety-belt” messages in cars from the late 80’s and early 90’s?). As a designer, I personally avoid discussions on such items but I definitely want to know what the experts decide upon in the end.
At the top of today’s user interface food-chain is the graphical user interface or GUI (pronounced ‘gooey’). On some products, this is the most complicated, expensive and time consuming aspect of the development process. I once worked on a project where millions were spent on a GUI but it was too complex for anyone without an engineering degree to operate; I have a degree but it was difficult for me too!
Very often, the underlying technology has been designed, tested and ready to ship before the experts settle on the requirements of the user interface. Truthfully, it is best to fully specify this sort of interface at the beginning because thinking about how this works forces the requirements-givers to fully consider the interrelationships of the various technical aspects of the product. In general, only the most technically sophisticated products have this kind of human interface.
Size & Weight
While these may sound simple, they are not.
The size of a product has impact in the fabricator’s shop, in the development lab, in the test labs, in the environmental testing chambers, on the construction of the shipping materials, on the cost to transport and warehouse the product and, ultimately, on the customer’s available space.
The weight of a product has impact on many of the same things but it also encompasses the notion of being able to move it around (I love my 42” TV but I dread having to move it).
Weight may also have a cost tradeoff. A product constructed of aluminum might weigh less that one made of steel (aluminum weighs about one third as much as steel) but it costs about twice as much. Iit may also require more in the way of a support structure since it is not quite as strong as steel.
Tolerances
This is another tricky aspect of writing a specification. Many of the individual requirements in a specification have some boundaries or tolerances placed upon them.
In a specification, tolerances are generally specified on one side only. For example, an automobile engine might be specified with a minimum amount of horsepower or a maximum amount of fuel consumption.
An internet router might be specified to handle a minimum number of packets per second. Virtually all products will be specified to meet a maximum cost target.
The trick with tolerances is to specify the conditions under which a given specification must be met. For example, the minimum horsepower of an engine might be specified at a specific engine RPM or the maximum power consumption of a refrigerator might be specified at the highest ambient temperature. It is easy to get involved in a game of specsmanship if the tolerances are not fully specified.
It is difficult to envision the worst-case scenarios for a product but these are the cases in which the tolerances matter most. In other words, sometimes the requirements tend to have conflicting boundaries and it is up to the specification, not the designer, to resolve the conflict.
Others
Once again, I could go on and on with this discussion.
We have things like color (to me, a motorcycle must be either red or black), shape (engineers love old Volvos because of the boxy shape), speed, displacement, MIPS, megabytes, gigahertz, packets/second, bits/second and so on.
A good specification will attempt to describe as much as is known about the things that comprise a product as possible. The more that is specified up front, the less likely there are to be any surprises down the road.
Requirements-givers must sometimes think that engineers are mind-readers. So often has it happened that halfway through the design or integration step, someone will ask how such-and-such a feature was implemented and the designer will say that this “feature” wasn’t in the functional specification.
The person asking the question is appalled that the designer did not “anticipate” this requirement and the designer is appalled that such an important feature (one that will certainly force a redesign) was not incorporated into the functional specification.
This is trouble.
Non-Requirements
As I’ve said, there is a tendency to be lazy, under-informed or both at this stage. This tends to produce inexact requirements and functional specifications that call for far more than is most-likely required. Here, we’ll briefly discuss the sorts of things that do not belong in a functional specification.
The Wannabe
There is a tendency to put “like-to-have”, “think-about”, and other sorts of un-testable items in a functional specification.
These items should be weeded out since they can unwittingly constrain the design process. For example, if the requirement is stated for an inexpensive automobile but that it would be nice to have a large engine and four-wheel drive, the designers may miss the inexpensive part by trying to incorporate a V8 engine and twin transaxles.
If the requirements-giver doesn’t know what the product must do, then one of two things must happen: find out or stop the project.
The God-Box
There is also a tendency to list all such features for a given product that have ever been conceived: the “God-box”. Managers and investors should be wary of such requirements since they show that the requirements-givers are simply covering their behinds instead of really understanding the customers’ requirements in detail. This kind of requirement leads to horrendous waste of design and other resources
Implementation Specifics
A functional specification is intended to spell out what the product must do, not how it will be done. The how is the domain of the designer, not the specifier.
Fluff
There is a tendency by amateur specification writers to include a lot of useless information that I call “fluff”. This is generally information about the customer, typical customer applications for the new product or information about competitive products. While this information generally has a place, it does not belong in a functional specification.
Writing Good Requirements
When writing requirements, use verbs like shall and must. Avoid weasel words like should, may and can as these words imply optional behavior.
Make sure that requirements are singular; do not use the words or or and to create complex requirements.
As with ordinary writing, don’t use jargon if it is possible to avoid doing so.
Make sure requirements are unambiguous.
Make sure requirements are testable.
Make sure requirements are complete.
The Constitution
The word may appears all too frequently in the US Constitution and several amendments although most uses are innocuously related to the future scale of the Union. The evil ones concern suspension of habeas corpus and recess appointments.
However, the most abused clause of the Constitution is the opening of Article 1, Section 8:
The Congress shall have Power To lay and collect Taxes, Duties, Imposts and Excises, to pay the Debts and provide for the common Defence and general Welfare of the United States; but all Duties, Imposts and Excises shall be uniform throughout the United States;
The key problems are ambiguity and complexity.
Social Security, like Obamacare, was deemed constitutional under this clause (taxation is constitutional, apparently for any stupid thing we choose).
Medicare, Medicaid and welfare have never been challenged in the supreme court, presumably because they would receive similar treatment.
If conservatives ever want get rid of this stuff, the power to tax for these purposes must be curtailed by amendment. It should be easy since the word welfare only occurs twice in the Federalist Papers concerning taxation (papers 30-36) and neither reference is of the FDR or LBJ variety. The Federalist was the argument in favor of the Constitution over the Articles of Confederacy.
The founders enumerated the things for which federal taxes could be used and social programs were not in the list. The rest of Article 1, Section 8 reads as follows;
To borrow Money on the credit of the United States;
To regulate Commerce with foreign Nations, and among the several States, and with the Indian Tribes;
To establish an uniform Rule of Naturalization, and uniform Laws on the subject of Bankruptcies throughout the United States;
To coin Money, regulate the Value thereof, and of foreign Coin, and fix the Standard of Weights and Measures;
To provide for the Punishment of counterfeiting the Securities and current Coin of the United States;
To establish Post Offices and post Roads;
To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries;
To constitute Tribunals inferior to the supreme Court;
To define and punish Piracies and Felonies committed on the high Seas, and Offences against the Law of Nations;
To declare War, grant Letters of Marque and Reprisal, and make Rules concerning Captures on Land and Water;
To raise and support Armies, but no Appropriation of Money to that Use shall be for a longer Term than two Years;
To provide and maintain a Navy;
To make Rules for the Government and Regulation of the land and naval Forces;
To provide for calling forth the Militia to execute the Laws of the Union, suppress Insurrections and repel Invasions;
To provide for organizing, arming, and disciplining, the Militia, and for governing such Part of them as may be employed in the Service of the United States, reserving to the States respectively, the Appointment of the Officers, and the Authority of training the Militia according to the discipline prescribed by Congress;
To exercise exclusive Legislation in all Cases whatsoever, over such District (not exceeding ten Miles square) as may, by Cession of particular States, and the Acceptance of Congress, become the Seat of the Government of the United States, and to exercise like Authority over all Places purchased by the Consent of the Legislature of the State in which the Same shall be, for the Erection of Forts, Magazines, Arsenals, dock-Yards, and other needful Buildings;--And
To make all Laws which shall be necessary and proper for carrying into Execution the foregoing Powers, and all other Powers vested by this Constitution in the Government of the United States, or in any Department or Officer thereof.
No Social Security, no Obamacare, no Medicare, no Medicaid and no Welfare. Nothing even remotely close.
These are charities and are outside the proper scope of government yet they represent more than 80% of the cost of federal government and more than half of state government.
Architecture & Specifications
The purpose of a functional specification is to clearly state what a product must do.
The goal of the engineering architect is to apply all applicable resources and knowledge to the requirements definition so as to produce a functional specification. This task is usually accomplished by decomposing the requirements into functional elements and then studying the detailed requirements of each of these in a process referred to as partitioning.
A engineering architect is somewhat similar to the classic architect since the classic architect ordinarily partitions a home or other structure into functional areas like kitchens, bathrooms, bedrooms and so on. The engineering architect will instead partition the requirement for say, a low-cost personal computer, into functional areas like keyboards, monitors, central processors, disk drives, input/output devices, and so on to include software and/or firmware.
Once the top-level partition is done, the secondary partition begins in which something like software might be further partitioned into elements like word processing, spreadsheets, web browsing, file management and so forth. The architect does not design any of these things at this point. The only task is to identify the specific and testable specifications brought on by the stated requirement for a computer.
Once the partitioning is decided, the means by which the various elements cooperate to achieve the goal must also be specified; a bag containing a keyboard, mouse, disk drives and diskettes will not meet the requirement of being a low-cost personal computer.
The means by which the user of the computer gets the computer to compute must also be specified. The man-machine interface is very complex and also, sometimes, very personal. This is why it took so long for personal computers to become prevalent; the original user interface to most computers was a combination of keystrokes that had little to do with ordinary language and only scientists and engineers were motivated enough to use them. It took many years for computers to become the ubiquitous tools they are today.
If all of this sounds complicated, it’s because it is. This is why many companies try to find ways to circumvent this process and it is also a primary reason why so many projects and companies fail. Any shortcut taken here almost certainly leads to failure or iteration. Failure is bad but iteration can lead to failure when the cost of iteration exceeds the potential rewards of undertaking the project in the first place. This is the primary problem with government-run projects; failure causes government growth instead of extinction.
Since all projects are different, it is nearly impossible to come up with a one-size-fits-all template for a functional specification. However, most decent word-processing software has a means to write a basic outline in which all paragraphs are numbered and in which sub-paragraphs are also numbered. This software will also allow new paragraphs to be added while the software automatically renumbers all of the other paragraphs.
This feature has exceptional value in this process since nearly every requirement has sub-requirements and most sub-requirements also have sub-requirements. I can only tell you that when I first laid my hands on such software (DOS-based XYwrite in 1988), my task was made much easier. Now, if they could only make that software more reliable…
Congress
Our congress has a Senate and the architect function falls on its members.
Sadly, the professional experience of this body is not congruent with the architect requirement; less than 10% of members have useful experience.
Documentation
One extremely important thing is to write everything down so that you and others may review it. This includes specifications, source code, engineering drawings, test plans and parts lists.
After documenting the work, the next important thing is to be able to change it as more is learned. This includes a way to keep track of the changes that have been made and why they were made.
Documentation requires archiving; we used to use filing cabinets and microfiche but there is also plenty of software available for keeping an archive of older documents; use it.
Most companies have an Engineering Change Process and although it is fairly uniformly hated, it is absolutely necessary. This subject deserves treatment on its own but the idea is to release engineering documentation from an archive for manufacturing usage and provide a means to update it in a manner that minimizes chaos.
Engineering Change Process
Once we create all of the documentation needed to manufacture our products, the process of maintaining it begins.
It requires maintenance for any number of reasons:
- Bug fixes
- Component obsolescence
- Product enhancement
- Cost reduction
- Manufacturability
- Second-sourcing of components
- Testability
- Clerical errors
There are (arguably) two types of changes;
- Changes to the form, fit or function of the sub-assembly or product.
- Changes that affect none of the above.
Generally, a change to form, fit or function requires a part number change to make the revised part uniquely identifiable for both inventory and customer purposes.
A change that does not affect form, fit or function just has the revision letter of the part changed; from ‘A’ to ‘B’, for example.
I’ve always had a hard time imagining a change that doesn’t affect form, fit or function. More to the point, why would you do it? Documentation changes aren’t free so why waste money and resource for a useless change?
The only semi-valid reasons I’ve seen are to avoid regulatory costs or part requalification.
Products used in the telecom industry use CLEI codes but each part number requires a new CLEI code at a cost of about $5,000 each in 1999. Changing a part number becomes prohibitive.
For military products, a part number change might require the part to have to be requalified for sale and use...also prohibitive but arguably illegal.
Both cases lead to shenanigans with the definition of form, fit or function.
All changes lead to the question of material disposition; what to do with the changed and unchanged parts.
- Use As Is - This disposition means that the original part meets requirements as well as it will after the change is incorporated.
- Rework - This disposition means that the original part does not meet requirements and that the change is needed to make it so.
- Scrap - This disposition means that the original part does not meet requirements but that the required change cannot be implemented by reworking it.
- Field Recall - This is usually reserved for problems that represent total organizational failure. This should be applied to most, if not all, government-run programs.
Every change order (or change notice in politically correct firms) also provides the gory details of changes to be made to engineering drawings (parts lists, schematics, assembly drawings, fabrication drawings, etc.).
In the past, there were hordes of people called draftsmen (or drafters for the politically correct) who would implement the actual drawing changes. By and large, those folks don’t exist any more; engineers now do that work themselves.
Change by Executive Fiat
The president has been making lots of changes to his signature law using this method. While it has the benefit of being efficient, it is arguably illegal. It should also be embarrassing that so many changes are needed to his most important piece of shit, er, legislation.
Document Releases
Some companies have a secondary process for releasing documents from engineering to the outside world of purchasing, manufacturing, assembly and test.
Released documents will exist at several levels during their lifetimes:
- Initial
- Prototyping
- Production
- Obsolete
Documents with Initial release status can be used for budgetary pricing purposes but no actual purchases can be made.
Documents with Prototype release status can be used to procure small quantities for first-article manufacture. This level may also be used (judiciously) to procure items with long lead times to prevent foreseeable production slips due to availability issues.
Documents with Production release status may be used for unlimited production with the following caveat: all new purchase orders let by the company must be accompanied by the latest documentation since changes happen regularly.
Components purchased off-the-shelf from outside vendors enjoy automatic Production release status but with the following caveat; any vendor parts added as second sources must be verified as suitable in all assemblies in which the original component was specified.
Congress
One thing our legislators do well is produce documents.
There are 6,699 bills and resolutions currently before the United States Congress. Of those, only about 5% will become law. They must be enacted before the end of the 2013-2015 session (the “113th Congress”). There are 703 bills on health...WTF!?
I humbly suggest we don’t need another 300 laws or the taxes that will come with them.
Schedules
Virtually all companies like to have schedules in place for each engineering project. That said, they rarely concatenate them into a “grand plan” schedule for the entire company. Further, they tend to pick and choose what they call a project.
Interestingly, most companies have a grand financial plan while lacking an overall game plan.
Go figure.
In general, a very large project is called a program. Smaller activities that, taken together, comprise the program are called, you guessed it: projects. Most of the other activities fall into neither category. It never ceases to amaze me that there are entire groups of professionals that toil without a well-conceived and documented plan.
Pick a group, other than engineering, and then ask to see the plan or the schedule for that group. Marketing, sales, finance and purchasing all tend to do what they do without the benefit of a plan or a schedule. Even most manufacturing operations tend to run in an ad hoc fashion since they are typically driven by a material requirements plan (MRP) which itself is driven by a forecast provided by a group without a plan.
Now, what is different between an engineering development project and a project to, let’s say, reduce the cost of testing a product in manufacturing? Both are begun to satisfy a need. Both require a clear statement of what is to be achieved. Both require resources. Both require a detailed plan of action. Both produce measurable results, good or bad.
Is it because engineers are stupid and need closer management? Is it because engineering projects are more or less important than other projects? Is it because engineering projects consume more resource than other projects (and so management tends to sit up and take more notice of them)?
These are all rhetorical questions since I have no clue why this tends to be the case. Of course, I’ve only worked at 17 different companies so my sample may be too small to be accurate...but I doubt that.
On the other hand, just about every engineering project relies on the efforts of every other group within a company. Further, a company trying to carry out many projects simultaneously will inevitably run into a conflict over resources both human and material.
Isn’t this enough reasoning to suggest that all projects large and small be treated the same way and that all such projects should be merged into a “grand plan” schedule of sorts? I would say yes but, clearly, most of those in management say no. They say it is too complex. They say it is too time consuming.
Of course it is!
The moral of this story is to be aware of the limitations of schedules and then to use meeting minutes to fill in the gaps. I’ll explain the notion of meeting minutes later.
Scheduling Rules of Thumb
I am including this section because schedules should be helpful to the project, not hurtful. This section is most important for the newcomer to engineering projects. I know this because I was once a newcomer and I tended to underestimate everything.
Scheduling is Guessing
The most important rule of scheduling is that, in the end, most (engineering) project schedules are guesses. This is true because, for most projects, the thing being scheduled has not been done before (or else you couldn’t make much money by doing it). Scheduling the unknown is quite difficult. This also goes for creativity, inventiveness and innovation.
Many Bad Estimates Yield a Good Estimate
To put it another way: the more detail you put in your schedule, the more likely it is to be close to reality since the overestimated tasks will tend to be cancelled out by the underestimated ones. Fortunately, most reasonably complex projects offer plenty of opportunity for detailed task lists. This is essentially making use of the law of averages.
Resource Conflicts
If your schedule relies on resources needed by other groups, be advised that you may not get them in a timely fashion.
Outside Groups
Estimates of your own work will typically be more accurate than estimates of work performed by others. Overestimate these tasks and make the owners defend themselves.
Punishment for Good Deeds
The downside to good estimates is that they often lead to finishing on time. Management will punish you for this because it makes everyone else look bad by comparison. They’ll call you a sandbagger or they’ll try to get you to shorten your schedule while there’s still uncertainty. Resist.
Meeting Minutes
As a project progresses, there will be meetings to discuss various aspects of it. Different people have found different ways of keeping track of the goings-on at these meetings. In many cases, each meeting is treated as a self-contained entity.
Most meetings are pointless when viewed out of the context of the project.
A meeting of more than three people is generally a waste of time.
I suggest that each meeting be treated as a means of capturing important information about the project as a whole and that the meeting minutes should be updated after each meeting and provide a sort of running history of the project from start to finish; the minutes also serve as a convenient to-do list.
People who suck at their jobs hate documenting that unfortunate fact but for the rest of us, its a useful tool. I always kept written minutes, primarily as a means of keeping stuff from slipping between the cracks and also to allow post mortem analysis of a project. I picked up this habit from my old boss, partner and friend Bill.
A meeting only needs a single attendee. Many times, something important will come up and it has to be written down so as not to be forgotten ( “slipped between the cracks”). Other times, an individual contributor on a project will come across something of interest to others but is unable to call a meeting in which to report the finding. The meeting minutes document allows each contributor to add to it as things are learned.
When the notion of “meeting minutes as project journal” is combined with an archiving scheme, a simple means of communicating project happenings is obtained. This is particularly beneficial to people that have an interest but are not directly involved with the project (like corporate management).
Here, the archiving scheme prevents more than one person at a time from having modification privileges and can typically be used to store the latest version of the document in a place where everyone may have read-only privileges.
Most archive software can be set up to deliver notifications when changes are made.
Format
The format is intended to serve several purposes:
- Maintain a list of attendees and meeting dates.
- Provide a place to describe the overall direction of the discussion.
- Provide an action register that allows for new items, open items and closed items as well as a means to assign the actions to a project member.
The action register is the key to the suggested meeting minutes format. Each item is numbered. Each item has a status (new, open or closed). Each item has an assignee, a target completion date and an actual completion date.
In general, the meeting minutes read like a history of the project from start to finish. Actions are generally listed in chronological order but they may not close in the same order. In most projects, there are lingering issues that take time to resolve. Some corporate managers complain that this format makes it hard to find and evaluate the open items. I suggest that if they were on top of the project, this would not be a problem. However, do what works best for you. Putting newer items at the top of the document is helpful to casual readers.
I suggest changing the background color of closed items to a grayish tone so as to make it easier to see which items are not closed. I further suggest that when a meeting takes place, the action register can serve as a meeting agenda of sorts since it is always desirable to close any open items before proceeding to the addition of new items.
Not all action items require action. Sometimes, they may just be used to identify something that has impact on the project but about which nothing can be done. For example, suppose that a project group has four members and two of them become unavailable for some unforeseen reason. This fact can be recorded in the minutes as a means to allow a sort of post-mortem evaluation of the project.
Assignees, dates, and actions are, in my view, a simpler means of project communication than detailed schedules and Gantt charts. In general, a company will have many projects going on at the same time. Each project has assigned resources and an agreed-upon schedule with no overarching corporate schedule; that’s why most schedules are obsolete the day after they’re created.
On one project, the meeting minutes document reached a length of more than 50 pages with hundreds of action items over three years. The project represented a mere 10% of a program.
The Current Administration
The president has been modifying the requirements and schedule for his signature legislation like mad. This is typical of poorly managed projects. This one, that set out to insure more people, actually led to the loss of insurance by a 5:1 ratio! Period.
Peer Review
The review process is a key element of architecture and specifications. Both a requirements review and a management review are necessary during this step.
Not even an architect can know everything so it is necessary to solicit the views of experts in all disciplines within the company before moving from the architectural stage to the detailed design stage.
A well-conceived specification will undergo many revisions during the architectural stage and perhaps a few during subsequent stages of the development process. That said, it should be recognized that specification changes are the cheapest in the early stages. A specification change in the subsequent stages of the development cycle becomes geometrically more expensive, sometimes catastrophically.
In general, late changes are made to remove requirements on poorly managed projects to keep them on schedule/budget.
Once the specifications have been developed, it usually customary to produce a budget estimate, a schedule estimate and a resource estimate (people, materials and equipment). If the specifications are well-conceived and the schedule contains sufficient detail (in English), the estimates should easily be within 20% of the actual figures.
I’ve seen schedules with lots of details fail because the items contain jargon that cannot be understood by anyone but the author. Peer review should eliminate this. Eschew obfuscation.
In general, a complex project comprises four roughly equal portions: architecture, detailed design, prototyping/integration and requirements testing. For projects of lesser complexity, the architecture stage tends to be smaller in time and resources than the other three.
The end of peer review usually causes a management review cycle to evaluate the likelihood of success. Sometimes this results in a go/no-go decision and sometimes it results in taking a step back to the requirements.
In the end, all projects revolve around the magic triangle of development cost, development time and product features. In general, any two of these three items can be optimized but rarely or never all three; this is why features get cut at the end of poorly managed projects.
Engineers will do well to remember this since management will tend to forget it. Do the hardest stuff first.
The point here is that all members of a project group (marketer, architect, designer, tester, assembler, fabricator, contractor and even the customer) to work together to properly evaluate the requirements.
For each scheduled item, assign a probability of success as a percentage. Then multiply them all to get a probability for the whole thing. The result should ideally be 100% but never is for something worthwhile.
For example, if a project has 100 tasks, each with a 95% probability of success (budget- and schedule-wise), the overall probability is 0.95^100 = 0.59%, not 95%. It’s amazing how few people get this basic bit of math
If it’s not 100%, the result multiplied by the project cost is essentially the project risk given that deadlines, schedules and budgets are serious. You really need a probability close to 100%.
Obamacare Peer Review
The president’s party didn’t like the review it got from its peers in the other party; the republicans uniformly hated it.
So they made Obamacare law without a single vote from their peers.
