Charles Darwin
The Descent of Man (1871)

Ask most people why so many larger companies seem rife with incompetence and lassitude while smaller companies seem to remain focused and productive, and you’ll likely hear the incremental argument: more people and more process results in less efficiency. Perhaps someone will cite the Peter Principle or Dunning-Kruger. You may even hear a market-friendly variation on social Darwinism: while larger companies usually have the capital to survive their mistakes, smaller companies have little choice but to sink or swim, resulting in a marketplace that seems to be primarily populated by well-run small companies.

There may be a simpler solution that borrows from the second law of thermodynamics, which you’ll remember from elementary school states that, over time, any isolated, ordered system dissipates into a state of disorder. Or, put another way: given a healthy window of opportunity, any efficient but unmitigated process will break apart into lesser, unproductive components. Consider that in Canada as elsewhere, daily door-to-door postal delivery — an ordered process predating telephones and email — is caught in a death spiral of junk mail, labor disputes and declining profitability, and you’ll see that even the most prodigious system can eventually decline toward a state of uselessness.

This sort of entropic argument ought to impact large and small companies alike, but in fact there’s a critical difference: declining efficiency is infectious, and in larger companies this has a higher impact on productivity and attrition. Here’s why:

Let’s assume, for the sake of argument, that 10% of all employees within any given company are incompetent at an arbitrary point in time. I’m feeling charitable.

A small company with 10% incompetency might have a single incompetent employee. We all know that guy: he’s the asshole who shows up for work half an hour later than everyone else, keeps a basketball in his office, and never seems to have gotten that important email or meeting invite. In all likelihood, everyone knows this guy’s a liability, and his authority is moderated by increased awareness and oversight. Few people will abandon ship because of one dysfunctional employee. Call this the one-idiot problem.

Now imagine a company ten times larger: we have ten incompetent employees, and the perception of endemic incompetence is much higher, potentially leading to an erosion of capable employees. Incremental impact has started to become exponential. Further, there’s a reasonable chance that some of these incompetent employees work for each other, which strengthens their mutual positions in the company; anyone who’s built a tower out of dominoes understands the load balancing advantage of placing one domino atop two others. We’ve now created the three-idiot problem.

Since both of these above scenarios are static, we need to add time as a variable. Over time, attrition results in some employees leaving and new employees coming onboard. Recruiting is a difficult task, and it’s easy to hire an unqualified or incompetent employee if you don’t due a reasonable amount of due diligence: testing hard skills, assessing leadership potential, bringing different interviewers into the room. A capable interviewer who does everything by the book still runs a healthy risk of hiring an incompetent employee, but an incompetent hiring manager will almost certainly end up with an incompetent employee (both because of the inherent difficulty in hiring a competent employee and because of the likelihood that a competent — and savvy — candidate won’t accept a job from an incompetent hiring manager). Over time, therefore, incompetent employees will begin to outnumber competent employees.

Here’s how viral incompetence might infect a large organization over an arbitrary period of time:

(If you can’t see the above spreadsheet, try reloading the page or clicking here.)

For simplicity’s sake, we’ve limited impacting factors to attrition  and recruiting, but of course there are countless other mitigating factors that come into play once a company crosses that Rubicon from primarily competent to primarily incompetent.

Can a company step back from the brink? In principle, a senior enough manager with a mandate to clean house can contain an infection of incompetence through aggressively managed turnover, but tying off a tourniquet does little good if incompetence remains unchecked elsewhere in the organization. In practice, it’s almost impossible to dislodge incompetence once it’s entrenched in a company, so the trick is to move quickly and address the index case — Idiot Zero, if you will. Once the opportunity for preemptive measures has passed, it’s time to update your LinkedIn profile and start looking for somewhere new to hang your hat.

The book is no thriller: it details, misstep by misstep, the failures of both people and process in the aftermath of the 2003 American-led invasion of Iraq, with particular focus on the cronyism and ivory tower economics which would ultimately define  L. Paul Bremer’s viceroyship.

The similarities between partisan nation building and boardroom strategy are striking, from endemic underappreciation of resourcing needs, to failing to realign priorities with actual ground conditions, to marginalizing the very stakeholders who will eventually inherit responsibility for the long-term maintenance of a project. It’s hard to say which is most worrisome: what this says about project management as a profession, what this says about the checks and balances in our system of government, or what this says about our unwillingness to watch Matt Damon in a movie where he’s not required to run.

A well-reasoned Socratic argument is the project manager’s Remington flat-head; there are few problems which won’t yield to patient, reductive logic… but those that won’t are probably gummed up in ego, bias, fear and/or office politics, and will need to be resolved using less elegant means.

Fortunately or unfortunately, companies tend to be structured in such a way as to automatically resolve most disputes through rank: if your boss disagrees with you, you lose; if your staff disagrees with you, they lose.

Peer arguments are a problem. Whether it’s your counterpart in another department, or a particularly troublesome stakeholder who won’t follow process, it’s difficult to win concessions from someone who doesn’t listen to reason. These are the sorts of arguments that get arbitrated by your boss, or worse, by your boss’ boss, and if you’re lucky you’ll get an hour in a conference room to argue your case in front of your opponent.

I’ve lost a lot of these arguments over the years, and in the process I’ve learned some useful tactics for resolving peer disputes (usually as a result of having them used on me). I’ve also learned a few unsavory tactics which I’m sure Socrates wouldn’t endorse.

Here’s how to not lose a fight with a peer:

–

1. This ought to be self-evident, but it’s worth emphasizing: if at all possible, resolve the issue before walking into that conference room. Any argument which goes up the chain of command is an argument which calls into question your ability to problem-solve on your own, and this may well cost you money in your next performance review. So before booking that meeting, do two things: question whether you really believe your position to be correct, and if so, make every attempt to reason with your opponent face-to-face. (No long-winded emails with half a dozen people on the CC.)
2. If your opponent won’t relent, and won’t agree to disagree, a fight is probably inevitable. Before you enter the conference room, understand that your goal isn’t to win the argument, but to not lose; a stalemate means your position is still valid and you’ll get another chance to seek resolution outside Thunderdome, so focus on not being shot down. There’s usually no need, but plenty of risk, in going for the kill.
3. It may sound like Sun Tzu 101, but you should know your opponent. Make an effort to understand every facet of the opposing argument, even if it means sparking a pre-debate to get everything out in the open. (Whatever you do, don’t then fall for your own stratagem and unleash all your own counterarguments: listen, learn, wait.)
4. Invite as many additional stakeholders into the meeting as possible. It’s very, very difficult for most people to remain silent throughout an entire meeting, which means more talk and less decision-making — if you can wait out the clock, you’ll leave the meeting with  a stalemate.
5. Come with data, and bring it in hard copy, not on a laptop. A loose sheaf of papers (no staples or clips) can be an effective prop against an opponent who shows up empty-handed.

–

Now here’s how to fight a bit dirtier — use as your conscience dictates:

–

1. It’s probably the oldest trick in the book: assuming you have the luxury of being able to set the meeting time, push it out at least a couple weeks and then reschedule it sooner at the last possible moment, denying your opponent the opportunity to prepare. This won’t help if your opponent is a natural improviser, but it won’t hurt either.
2. Avoid sitting directly opposite your opponent, which provides a convenient crosshair for his/her arguments. The two best positions in the room are (a) next to the decision-maker, or (b) on the side of your opponent opposite the decision-maker, so that your opponent is forced to split his/her attention. If you happen to be immediately next to your opponent, edge in as close as possible. Most people instinctively shy away from imposed proximity, which works against an aggressive opponent.
3. If you’ve managed to add attendees to your meeting, you’ll know in advance who’s going to be there and what their biases are. Obviously, if you can invite people who support your argument, that’s ideal — but it’s unlikely that you’ll be allowed to show up with your own posse. So your next choice will be your enemy’s enemies — those who disagree with your opponent on other issues and will hijack the debate to score points for their own cause (thereby keeping your opponent on the defensive). If you can’t get any of these sorts of people into the room, then your final option will be people who simply have a different agenda and can muddy the waters, allowing you to wait out the clock.
4. Defeating a straw man argument can appear to strengthen your position. If you have strong data to support one of your arguments, try quietly floating the opposite conclusion around the office beforehand — if you’re lucky, this easily rebutted argument will emerge from your opponent during debate, and if not, someone else in the room may offer it as an opportunity to contribute.
5. When studying your opponent’s arguments beforehand, take note of repetitive verbal tics. Many people have a handful of favorite cliches — analogies, idioms or jargon with which they shore up their arguments, and on which they subconsciously rely when flustered. Learn your opponent’s vocabulary and then, when arguing your case, try taking some of this familiar language off the table. For instance, if you have an opponent who favors analogies involving houses (e.g. the project plan is like the floorplan, the server infrastructure is the foundation, the presentation level code is the aluminum siding and roof shingles, etc.), start the meeting by asking “can we avoid talking about this problem like it’s a physical structure, since it’s a misleading analogy?” Your opponent will either struggle to make his/her point in another way, or lapse accidentally into the analogy which you’ve already devalued.

Project Slicer is a post-mortem management and dashboarding platform, which means that it endeavors to capture summary data about completed projects. Learning from the mistakes of previous projects is critical to ensuring improved performance on future projects.

Once registered (as a free, pro or premium member), users create their own project office and proceed to add projects and team members. Feedback can be either attributed or anonymous (at the preference of the project manager), and encompasses both quantifiable and qualitative data. All feedback is aggregated into the project office dashboard, which can be filtered by project manager, client or type of project.

Project Slicer is currently open to all users as a fully-functional beta, and feedback is always welcome through UserVoice. If tweeting, please mention (and follow!) @projectslicer.

Expect additional features and UI improvements in the months ahead…

…

I’ve worked with some great teams and (less frequently) as part of some less than great teams, and there are unambiguous differences between the two:

When I draw this sort of quality spectrum for senior stakeholders, I always get well-meaning nods, because really, all things being equal, who WOULDN’T want to live at the progressive edge of the quality spectrum? Of course all things are NOT equal, I’m invariably reminded, so that’s the time to layer another dimension onto the quality spectrum which will speak directly to those in the room with P&L responsibility:

There’s a linear relationship between quality and profitability; while quality in and of itself doesn’t guarantee market leadership (or we wouldn’t all be abandoning CDs for low-bitrate MP3s), there’s little doubt that it provides a more fertile ground for success. I recently wrote about decreased retention as one of the major costs of a low quality environment, but there are many, many others:

• Sub-standard deliverables throughout the project lifecycle, which can live on for years, iteration after iteration
• Bad PR, some of which will invariably make its way to clients and prospects
• Increasingly difficult recruitment leading to longer hiring cycles

So how can a company specifically target the intersection of quality and profit? For project managers, the logical tool is process optimization:

A nimble process set isn’t a silver bullet. There are myriad risks which can enhance or destabilize a growing team, none of which should be ignored — black-boxing; underutilization; overcommitment — but without a robust and flexible set of proven processes, a production team has as little chance of stumbling upon quality as a High Street busker has of joining the London Philharmonic.

(Nimbleness is obviously relative. For team members who’ve worked in start-up environments, submitting timesheets and juggling stakeholder approvals can seem onerous; conversely, graduates of process-heavy enterprise environments often feel untethered when given broad latitude to manage scope and resources. At either extreme you’ll find those who use process, or avoid process, to conceal individual deficiencies.

If you design processes which facilitate individual growth and inhibit unwanted risk, odds are you’ll find an acceptable balance between paperwork and creative improvisation.)

In fact, performance reviews generally fail for the same reason pyramid schemes succeed: there’s little incentive to be honest.

After grappling with this problem for several years, I’ve come to the conclusion that the best metric is the one favored by sales departments everywhere: profit. I try to base a large percentage of every employee’s performance review and bonus on project profitability, which accomplishes two things: it provides manager and employee alike with quantifiable data that balances out subjective feedback, and it incentivized back-office production staff to work collaboratively with front-office sales staff to their mutual benefit.

I do this, however, with a couple caveats:

• For this sort of no-nonsense approach to work, employees have to have a reasonable amount of control over the success of their projects. If they don’t share responsibility for the estimate and/or aren’t allowed to micromanage their own time, they shouldn’t be assessed on the eventual actuals. (Note that reasonable control does not mean complete control. Part of being an effective team member is managing the risks of the team.)
• Profitability should never be weighted so high that it inhibits innovation and risk.

Goals and Targets

To provide structure for the less quantifiable parts of a performance review, I tend to use a system of goals and targets which are negotiated at the beginning of the evaluation period and then revisited either quarterly or semi-annually. Goals are kept high-level and accommodate both peer / stakeholder feedback and supervisor feedback.

Each goal is ideally supported by specific targets which act as a roadmap for achieving the best possible score on that goal. Wherever possible, targets should be binary. “Create such and such an application” is a better target than “participate in product development.”

Although goals should be shared between all employees performing a similar task (to ensure equitability of assessment), targets need not be. Whichever path gets an employee to the desired goal is the right path.

Scoring

I tend to use percentages because they’re easy to work with. Quantifiable goals can be scored with precision, whereas less quantifiable goals are best captured as thresholds (I use increments of 25%). A particularly dysfunctional company I used to work for had the dubious plan, perhaps inspired by a certain scene in Spinal Tap, of allowing scores as high as 135% in the belief that it would encourage their employees to strive that much more (35% more!), but obviously all it accomplished was the devaluation of 100%. Keep it simple: stick to the basic math.

No Surprises

The teams I’ve led will tell you that I’m candid, probably to a fault. I don’t believe in the big reveal, and I apply the same philosophy to performance reviews: if I’m doing my job as a manager, a performance review need take no longer than a handshake and a few words of encouragement. If, on the other hand, I’ve scheduled the better part of an hour to walk through a laundry list of suggestions and concerns, I probably haven’t been providing enough event-specific feedback through design reviews, status meetings and project post-mortems, and you can therefore expect more of these check-ins in the months ahead.

(I’m looking at you, New York-based wireless startup named after a sitcom catchphrase.)

As your company matures, you’ll start letting go of those bottom-feeder projects, but every once in awhile something will come in that’s just too tempting to pass up. It’s a potential trainwreck, but you want to believe it’s a foot in the door for additional, pricier work in the future. From a superficial cost benefit perspective, it’s a no-brainer: the margins might be anemic, but the risk of a lean month pales next to the opportunity for future growth of the account. So you do it. But what you’ve forgotten to factor into your calculation is depreciated retention.

Bad projects cost you people. The more bad projects you take on, the more time your staff will spend on Monster looking for the next job. Quantifying this cost is difficult: revenue and salary varies widely across industries, and the amount of abuse one might be inclined to accept in a young industry is clearly different than the expectations of those in a more mature sector of the economy. With a bit of generalization, though, we can create a set of formulas that help us quantify this depreciation within a rough order of magnitude, and then run some sample numbers through them to see what we get.

Let’s start by defining a few variables:

Now let’s ballpark some constants — any of these percentages can be tweaked depending on the specific industry or individual project.

Based on these speculative values, we can create some algorithmic relationships between variables and constants. (Note that in the formulas below, parentheses are used both for order of operations and simply to provide clarity through conceptual segmentation.)

If we add up those three costs (and I’m sure there are more — feel free to add your own, or trade with your friends), we wind up with a simple high-level formula that looks like this:

Retention cost = lost productivity + equity loss + recruiting costs

Or, to write it out in full:

Retention cost = {eS x tS x L x pD} + {eS x tS x L x uS} + {[(eS x rF) + (rS x rU x hC) + (eS x hC x M)] x 33%}

Now, if I’d started off there, you’d have thought I was crazy, right?

Let’s run some numbers through the algorithm and see what happens. Assume a bad project comes in the door with a fixed budget of 50k and a lifecycle of three months. It requires a team of five who are each paid an average salary of 50k. Let’s also assume our company involves only two people in the recruiting process: the project manager and the HR manager (each of whom are paid 65k). If we replace the variables and constants with actual data, we get:

{50,000 x 5 x 0.25 x 0.25} + {50,000 x 5 x 0.25 x 0.5} + {[(50,000 x 0.15) + (130,000 x 0.25 x 0.2) + (50,000 x 0.2 x 1)] x 0.33}

Or:

$54,795

In other words, the retention cost of the project actually exceeds the overall project budget. When you also add in the cost of producing the project (which we can conservatively estimate at $25,000, assuming normal margins), we arrive at a total cost of $79,795 to produce a project budgeted at $50,000.

I’ve built a Google Docs spreadsheet to make it easier to experiment with these formulas; simply create your own copy from the template provided, but bear in mind, of course, that this is an illustrative thought experiment only — if you decide to feed this data into your accounting software, you do so at your own risk.

I’ve managed to forget much of what was presented that afternoon — there were a lot of teamwork exercises that involved making lists and not showing them to anybody, presumably because in a real negotiation with millions of dollars on the table, surreptitious list-making might give you enough of an edge to walk away with the hotel contract AND the waterfront casino.

I remember, though, that a portion of the presentation was dedicated to “dirty tricks,” and we all sat up and paid attention to those. In retrospect, few of the strategies listed as “dirty” were in any way unscrupulous (except the one about home buyers faking multiple high offers and then rescinding them to destroy a seller’s confidence; classic!). In fact, most were generic psychological tactics that anyone with a bit of Skinner under his or her belt might take for granted.

I want to share a handful of them here, since they’ve served me well in recent years when I’ve been in the unenviable position of having to deliver bad news to project stakeholders and negotiate a favorable outcome.

An inevitable part of every project manager’s job is delivering bad news. Projects fail, sometimes catastrophically but more often by degrees, and each incremental point of failure represents both an opportunity to correct problems and a responsibility to come clean with stakeholders. No one wants to admit failure; it’s embarrassing, and it takes a toll on morale and on credibility. And so most project managers dissemble. They use ambiguous language, they avoid confrontation, they defer to others up and down the chain of command; instead of immediately addressing the problem, they batten down the hatches and wait for the storm to blow over, which is just about the worst way to engage in any sort of negotiation.

To many project managers, the notion of failure as a form of negotiation is like being told the guillotine is a form of prisoner rehabilitation. It certainly didn’t occur to me until I heard it from a guy in a swim cap working the airport circuit. No matter how serious the failure, you can expect a spectrum of potential outcomes, and there are strategies to influence where on that spectrum you end up:

1. Don’t skirt the issue of money. Most of us try to cushion bad news by avoiding discussing the impact of a bad situation, especially when that impact involves money. Part of that is societal conditioning — on some level, many of us feel it’s vulgar to discuss money — and part of it our wariness of inducing sticker-shock. In fact, being coy about money just makes us seem evasive and encourages the other party to lead the negotiation. A better tactic is to use your adversary’s similar discomfort with money to your advantage. Go there immediately and keep the conversation outside of your mutual comfort zone until you’ve delivered the bad news and are ready to discuss the details of fixing the problem. Being frank about money also send the message that you realize the seriousness of the situation are are committed to solving the problem.
2. Negotiate face to face. Delivering bad news by email is a bad idea by any measure; it polarizes the conversation right from the beginning, and it cedes the advantage by allowing the recipient to react to the problem on his or her own turf. Voicemail and conference calls are similarly disempowering; neither approach allows you the freedom to guide the negotiation. As uncomfortable as it is to deliver bad news in person, just bite the bullet and do it. If nothing else, it’s a show of respect for your stakeholders, who deserve more than a few contrite words in their inbox Monday morning.
3. Don’t be afraid of a beating. Losing the battle is sometimes necessary to win the war. Confronted with failure, your stakeholders are going to be disappointed; they’re going to feel like you’ve misled them and their instinct may be to lash out. Just as a good parent tries not to invalidate the feelings of a child, not matter how frustrating or hurtful, a good project manager lets angry stakeholders vent their anger without responding in kind. Letting a stakeholder beat you up allows you two advantages: you’ll hopefully siphon off some of the tension, and you get to demonstrate that you’ve maintained your calm while your adversaries have lost theirs.
4. Provide false choices. This tactic is so common that it’s hard to implement it anymore with any degree of subtlety. I always smile when someone tries it on me (as a former employer actually did not that long ago when attempting to negotiate my severance). To distract from the substantive point of negotiation, focus on a lesser point of contention in which your adversary can choose between two or more equally insignificant options. So for instance: we’ve incurred 50k in cost overruns; should we add that to the final invoice or prorate it?
5. Restore confidence by setting arbitrary goals and then meeting them. After you’ve weathered a project failure, your stakeholders’ confidence will be abysmally low. To restore confidence, deliberately set several imminent interim goals — it doesn’t matter in the least what those goals are or whether they’re critical to the project; the sole point here is to set easily achievable milestones that will serve to build up confidence in your ability to meet expectations. The more granular your milestone, the more confidence you’ll instill when you meet it. For instance, “I’ll send you a detailed status report by Friday noon” will hold more weight than “I’ll have a status report for you before the end of the week,” even though they’re saying essentially the same thing.

A few years ago, I developed a spreadsheet-based resource calendar for dynamically managing teams across projects, and for lack of a better alternative I’ve continued to use this, migrating it into Google Docs and tweaking it to the needs of specific environments and resource structures. As a macroscopic visualization tool, it provides resource managers with several advantages over more granular task-based technologies:

• Real-time bird’s eye view of status and resourcing requirements across the organization
• Color-coded to visually demarcate billable work from unbillable or speculative work
• Two-tier permissioning using Google Docs page protection (only invited users can view the spreadsheet, and only authorized administrators like project managers can make changes) and auditing using revision history
• Built-in conditional logic to flag status colors and alerts

The one significant limitation of a spreadsheet-based approach to resource management is that the actual allocation of resource blocks is ONLY visual; booked time has no logical meaning within the spreadsheet and exists solely as colored spreadsheet cells, and so moving project allocations around remains a manual task that, if not handled conscientiously by the project manager, can become divorced from the original resource estimate. This hasn’t been enough of a hurdle in recent years to prompt me to build a more intelligent platform, but everyone’s resourcing needs will obviously differ.

Feel free to make a copy of the resource calendar and try it out in your own environment; please read the explanatory notes on the “read me” tab and also review the license.

Open the resource calendar: http://bit.ly/cfVka0