The Wary Engineer’s Notebook – Part 3

This is third installment of “The Wary Engineer’s Notebook”. In this episode we take a look at those joyous and stimulating events known as “Reviews”.

Just remember that this is all intended to be humorous in a satirical, tongue-in-cheek way, so please don’t get spun up thinking I’m trying to insult you or your dress code. I wouldn’t dream of it. Honest.

If you’re not sure what this is all about then please go back and read Part 1 first.


Reviews are a class of meeting with a semblance of formal structure, and, ostensibly, an actual purpose. Either, or both, of these characteristics may be lacking. In engineering it is common to first have a proposal review. This where the customer or end users will get to decide if this is really what they want (assuming they even have a clue as to what they really want–many don’t). Then comes the requirements review, the preliminary design review, the critical design review and so on. At some point either the reviews end and the the final product gets pushed out the door, or everyone just gives up, calls it a loss and then start calling their lawyers.

Proposal Review

The proposal review is probably the most important of the review meetings, since it is here where the audience (the customer, usually) will probably be paying attention to what you are saying. This is because it is here where the customer will see pretty pictures for the first time, find out how much it is going to cost them to have those pretty pictures converted into something real, and how soon they can start to play with it. The proposal document itself may even actually be read by someone, at least the summary and the section with the dollar amounts. Beware, you will be held to what is presented during this review. No matter how much things change due to flip-flopping customer whims and desirements, lack of requirements, lack of resources or a hyper-active project manager or marketing suit who wants to give the customer the moon without once bothering to ask you what it will really take to accomplish what they’ve promised. It’s your butt that’s on the line when the cost goes up or the schedule slips.

Requirements Review

If you manage to get one of these, consider yourself lucky. The typical pattern seems to be that someone (probably you, although it should ideally be the customer) writes the requirements. If you end up doing the requirements then be prepared to ask, and ask again, and maybe even ask yet again, for a review that will probably never happen[1]. If it does happen, then you can most likely expect the following:

People show up for the review and look slightly baffled or just bored. No one has bothered to read your preliminary draft of the requirements up to this point, but now they’re going to sit around and try to pick them apart as if they has spent the last week going over the design and the requirements in detail[2]. This review is typically a total waste of time, since most of the meeting time will be taken up giving the review board members tutorials on things they should have already read up on from the draft requirements you sent out and the proposal documentation before coming to the review. But they won’t, so just be prepared to repeat yourself multiple times.

Preliminary Design Review (PDR)

The PDR is where you get to tell a bunch of half-asleep people what you think you’re going to do, if you can get the resources and personnel you really need to do it.[3] They’re probably not going to listen, and it’s doubtful that you’ll get what you need, so it’s largely a waste of time for you. All you really have to do is show some pretty pictures, tell them what they expect to hear based on what’s in the proposal, and then pronounce that it’s all good and you’ll make it happen. They’ll most likely understand that much. Oh, and they will typically remember enough of your presentation to hold you to it, but you still won’t get the resources you’ve requested.

Critical Design Review (CDR)

The CDR is like the PDR, except that by now you’re expected to have at least done some work to prove the claims made during the PDR. But, as with the PDR, the review board will most likely be half-asleep or still groggy from waking up, and most of what you say will go in one ear and out the other. Just show them some more pretty pictures, make your futile case for funding and resources yet again, and get prepared to spend a considerable chunk of your life doing 80-hour weeks and attending “Useful” meetings. Unless it really does all go South, in which case you’ll find yourself attending a lot of “Unproductive” meetings and polishing up your resume.

Risk Reduction Review

These usually happen late in the project, sometimes right before final delivery. Someone has their panties in a bunch over the number of problem reports you’ve filed because they didn’t bother to try to understand your requirements and the fact that you didn’t have the resources and people necessary to do the job right at the requirements creation phase.

These types of reviews typically occur when someone happens to wake up, look at the problem report count (and usually not bother to look at the problems themselves), and then suddenly decide to get excited about it and try to find yet another reason to justify their job.[4]



[1] Think I’m making this up? I wish it were so. I once asked repeatedly for an end user to review the requirements that pertained directly to them, but they never did. When it came down to the eleventh hour they suddenly started hopping up and down about how I hadn’t done what they wanted. Too bad. It was too late to change it and it was deployed as written, and they had to learn how to work around it. If they’d bothered to review the requirements when I asked them to they would have gotten what they wanted.

[2] Once again, I’m not making this up. On one major project this seemed to be the standard procedure. I ended up spending most of the requirements review meeting time going over the basic concepts and definitions, and then answering loads of questions that could have been resolved if people had bothered to read the material I had sent out a week earlier. I learned later that I wasn’t unique; everyone on the various teams involved with the project went through the same silliness.

[3] If I had a dollar right now for every time I’ve watched people nod off in design review meetings I could buy myself a really nice time in Las Vegas.

[4] I wish I could say that I’ve never experienced this, but, sadly, I have. My initial reaction was to be insulted, of course, since we had been diligent about using the problem tracking system and then knocking the problems down (usually with detailed resolution descriptions and even some nice charts and graphics). Apparently no one read them. They also didn’t bother to look at the entry count versus the resolved count (which near the end of the project were identical). I later learned from other people within the customer’s organization that vendors get singled out for this type of treatment, whereas in-house projects got a lot more slack. I also learned that “sweeping it under the rug” was a not uncommon way to deal with the “little” bugs, rather than document them.


0 Responses to “The Wary Engineer’s Notebook – Part 3”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Follow Crankycode on

Little Buddy

An awesome little friend

Jordi the Sheltie passed away in 2008 at the ripe old age of 14. He was the most awesome dog I've ever known.


%d bloggers like this: