Category Archives: Project Management
An assignment a few years ago required some very specialized design work. We provided a detailed report with many specific recommendations, many of which were ignored. When we politely pointed this out to the client, we were told, “Just because we pay you for advice, that doesn’t mean we’ll follow it.”(1)
Fair enough. Managers sometimes have to make difficult tradeoffs, with technical advice being only one of many parameters that must be considered. Consultants should therefore not be offended when a manager decides to assign a lower priority to their recommendations — we don’t see the big picture; the manager does.
In another example, a colleague of mine — arguably one of the top experts for guiding the preparation of winning proposals for military contracts — arrived to head up a hot time-sensitive proposal effort, only to spend two days sitting in a waiting room. Whether the client was suddenly engaged in an emergency task or whether they were being woefully inefficient doesn’t matter; this was the client’s prerogative, and nothing to get upset about. (My colleague was paid handsomely for sitting.)
Bottom line: although consultants should expect to be treated with professionalism and respect, they should not expect to be given any special privileges or accommodations, and they certainly should never demand such treatment. We are there to do a job with minimal hand-holding, not to be treated like visiting royalty, and our egos should be accordingly prepared.(2)
Note 1: In this example, the subsequent eruption of significant technical problems indicated that ignoring our advice was not a wise decision.
Note 2: For example, a consultant should not assume that an office will be provided, or even a desk. Be prepared to grab a table in the cafeteria, or to use the desk of someone who’s on vacation.
“Sounds good,” I cautiously replied. “Send me a list of problems you’ve solved and I’ll consider it.”
It may sound like fun to be paid to solve problems, but the client is not at all interested in paying us to have fun. They are interested in paying us to solve problems, quickly. Usually these problems have been expensively festering, and the client’s design team is fatigued and understaffed. Bringing in a qualified outsider at such times makes sense, since a fresh perspective — unclouded by burnout (and sometimes politics) — can do wonders. In my own experience, oftentimes the solution to a stubborn problem is literally within an inch or two on the schematic of where the team has previously tread, missed only because of the disruptive pressures and distractions that major problems generate.
Therefore, if you want to be a consultant that helps quickly solve a challenging technical problem, there are three qualities that you must be able to offer your client:
1. You must be experienced — with a successful track record — in solving technical problems under high-stress conditions.
2. You must be organized and methodical. The client has already had enough of hit-or-miss scrambling, and is looking for a calm disciplined approach. This means that you will have requested all relevant data on the problem and be ready to provide productive input on day one. (If you are a shoot-from-the-hip type of person, your tenure will last about 24 hours or less.)
3. You must be diplomatic and willing to work closely with the client’s team, simply because you need them as much as they need you. Hotshots or other big ego types will get nowhere fast.
Note: On hundreds of projects I have found the great majority of customers to be highly professional and a pleasure to work with. This post addresses the few exceptions that are encountered from time to time. -EW
Several years ago I was hired by an electronics firm to determine the root cause of a circuit problem that was holding up production. I spoke to the young engineer who had created the design, analyzed his circuit, reviewed the test data, and concluded that he had made a design error. (For what it’s worth, most of my troubleshooting investigations have determined that the root cause of circuit problems is insufficient design margin, which is why I always recommend that every circuit be validated with a good WCA.) I provided a solution and that was that. Or so I thought.
I later received a tip from a colleague that the young engineer I had worked with had generated a memo that stated that my conclusions were wrong, and that he had found the “true cause” of the problem. Apparently the engineer felt threatened by the fact that he had designed a circuit with a problem that he could not identify, and decided to lie about the facts behind my back. Based on the tip, I provided a follow-up memo that corrected his inaccuracies. This caused the young engineer some serious embarrassment, but I think he earned it.
I felt bad nonetheless, because the first rule of a consultant is, in my opinion, to be sure that the client’s team perceives you as non-threatening. The consultant is not there to act superior, or to gloat, or to point out the perceived faults of the team. (Hint: such consultants create more damage than they’re worth; fire them.) The consultant’s job is simply to lend a hand.
Furthermore, there is no reason for the consultant to feel superior. Yes, the consultant must have design expertise and problem-solving skills, but more valuable is the fact that the consultant provides an outside and objective viewpoint, unpolluted by the daily hassles (sometimes political) that impede the team. In many cases the team is very close to finding the problem, but they are unable to do so because they are behind schedule, overworked, tired, and distracted by the varied and hectic demands of the typical engineering workplace. This is why it makes good sense to hire a consultant: it’s just not possible for a team to be completely objective about their own efforts, particularly when they’re under a lot of pressure.
Yet, despite the tactful and low-key assistance of a modest consultant, there will still be those cases where the defensiveness of some individuals cannot be disarmed. Untruthful memos, passive-aggressive unhelpfulness, “I thought of it before the consultant did” posturing, and other immature behavior will sometimes be encountered. If you want to be a consultant, then you will need to deal with such unpleasantness forthrightly but tactfully. It’s just part of the job.
-from The Onion, “Study Finds Working at Work Improves Productivity“
Let’s face it. A lot of us are highly skilled at finding ways to avoid boring assignments, regardless of how essential they may be. Precious time is grossly wasted on web surfing, daydreaming, coffee breaks, and wanton socializing.
Sure, we make exceptions. We’ll work our ass off into the evening and weekends for the really challenging assignments, the ones worthy of our talents. Okay, so maybe we haven’t developed a lot of talent, not yet, but someday we’ll have it, and we want those assignments now, as a prepaid reward in advance of that fine day.
And if we’ve been assigned a project management role, maybe the reason we can’t nail our butts down at our desks for more than ten minutes to do some real work is simply because we’re lazy and undisciplined, preferring to walk around sipping coffee and barking orders, while we avoid the detailed planning required for proper staffing, the establishment of priorities, and the creation of realistic budgets and schedules.
Because they make us uncomfortable, we also avoid personnel issues and just let them fester. Judging makes us uncomfortable, too. We don’t want anyone to not like us, so every year we give everybody on the team the same generic review and the same average raise, not realizing that this makes everyone not like us, rather than just the underperformers.
So, instead of really managing, we host lots of useless meetings and scurry around out on the floor, butting in and injecting our naive and meager knowledge as we futilely flail at putting out the latest fire, never realizing that those fires are ignited as a result of ignoring staffing and budgets and schedules and priorities and personnel issues.
And then we wonder why our new products are late, costly, unimpressive, and unreliable.
Your clients hire you for your expertise, not to agree with them. If their design approach is clearly flawed, tell them. Better to be unpopular, or even lose your assignment, than to help kill the client’s company.
Corollary: Clients hire you for your advice, but that doesn’t mean they have to agree with you. If your recommendations are ignored or overruled, as long as you’ve provided your best advice based on the data the client provided, your task is complete. Just smile, deposit your fee, and move on.
“The Perfect People,” posted earlier on my ne-walker blog site, received some good response, so I thought I would post a link to it here; I think a lot of engineers will relate. (I also had a recent encounter with one of these types.)
There’s a lot of talk about project collaboration, such as creating designs in the Cloud, where everyone interacts with everyone else all the time. Like all new fads, however, project managers should be wary, because fads have a way of turning dark and raining on your assumptions.
Yes, collaboration is essential for optimizing the implementation of new ideas, but great new ideas and technical breakthroughs are not created by groups, they are created by solitary individuals, noodling things out on their own.
Why not set aside a small block of time each day for your brightest, where they — quietly and without interruption — can nurture their creative passions?