Somehow, I’ve become embroiled in a controversy (why do these things happen to me?) about the proper use of “professional.”

Many of those who have studied the topic insist it be restricted to, at a minimum, roles for which accredited institutions award certifications.

Some go further, wanting “professional” to be used only when the law doesn’t allow anyone to practice a craft without certification. By this definition, of course, cosmetologists qualify, but there is no such thing as an IT professional.

My own position? As I lack the authority to enforce linguistic usages on anyone (and if I had it, I’d use it to make using hopefully to mean I hope a felony), I limited my part of the conversation to description rather than prescription: “Professional” has at least four different meanings. In addition to the two already listed, it can mean “someone who practices a trade or craft that makes use of an extensive, well-defined body of knowledge and skills.” That’s what we mean when we talk about IT professionals.

And, it can mean “someone who gets paid for doing what they do.” I’m old enough to remember when professional athletes were barred from Olympic competition, the only difference between professional and amateur athletes being whether they’re paid for their efforts.

For some reason, these rather obvious points made some participants in the conversation downright grumpy.

Which brings us to the seemingly unrelated topic of whether incentive pay amounts to bribery, as claimed here not very long ago (“Do retention bribes make sense?” KJR, 7/2/2012).

The place to start is the definition. Many correspondents insisted it isn’t a bribe unless the result is nefarious or illegal behavior, so incentive pay isn’t bribery.

But by that definition, giving a politician money in exchange for their agreeing to vote a certain way on an issue isn’t a bribe either. After all, voting a certain way on an issue isn’t illegal. For that matter, changing one’s mind, and therefore one’s vote isn’t illegal. Changing it in exchange for cash or other favors is what makes the cash or favors a bribe … and therefore illegal … in the first place.

Unless it’s a campaign contribution, of course, which, I’m told, is an exercise of free speech, not a bribe. Which of course makes complete sense: The purpose of free speech is to allow us to persuade each other through the presentation of compelling arguments, and what argument is more compelling to elected officials than a large wad of cash they can use in their attempts to get elected?

I trust the distinction is clear. But I digress. The question is whether incentive compensation is bribery. As what makes bribing an elected official illegal is that it gets them to do what they otherwise would not have done, that appears to be the essence of the beast.

Which leads to this frequently expressed objection to the incentive-comp-as-bribery proposition: If that’s a bribe, isn’t all compensation a bribe? After all, very few of us would show up for work if our employers stopped paying us.

It’s a good point. A very good point, that leads to a very important insight about leadership. But it isn’t quite right, because basic compensation doesn’t get anyone to do what they wouldn’t otherwise do.

Unless you’re wealthy enough to retire with the lifestyle you desire (and aren’t in a position to get enough money to live on via other means, like extortion or armed robbery) your options are limited: Starve to death or get a paying job.

So when your employer pays you, it isn’t to get you to go to work. You’d do that anyway. It’s to influence your choice of where to go to work—a very different matter.

Which gets us to why the point matters: Many business “leaders” (as opposed to leaders) think that money is the only tool they have to get employees to work for them, instead of somewhere else. They think, that is, they have to bribe people to work for them.

And so, they pay more than they have to and get worse results for it, because if money is all that matters to their employees, how they treat their employees doesn’t matter. “Leaders” like this don’t treat them very well.

Which leads to this week’s question: What could an employer offer you to get you to work for them if the best they could pay you was 15% less than what you’re making right now?

And this week’s second question: If you’re in management, do you offer this to the employees who work for you right now?

If it’s a project, plan it.

Seems obvious, doesn’t it?

But it isn’t. I was reminded of this in a recent project postmortem. While the project wasn’t a catastrophe, it was pretty ragged, or so I was told. And when I asked to see the project charter and schedule, and the project manager explained it was such a simple project that he hadn’t bothered to create them, the root cause swam into focus.

The usual thought process about project plans is, the bigger the project, the bigger the plan. It isn’t a bad thought process, either.

What it is is misleading, because it implies that the amount of planning needed as projects increase or decrease in size is described by a straight line, when in fact it’s best described by an S-curve.

The curve flattens out at the far right because as a project (or multi-project initiative or multi-initiative program) continues to increase in size, there comes a point of diminishing returns, beyond which the project manager is simply micromanaging.

In other words, while it can make sense to go beyond “Get dressed” to “Put on your shoes,” and even from there to “Tie your shoes” as the level of task granularity,  going beyond “Tie your shoes” to “Grasp left shoelace between left thumb and left forefinger; then grasp right shoelace between right thumb and right forefinger” means you have the wrong people on the project team.

At the far left, where projects are small and simple? The curve also flattens out, well above zero. There is an irreducible minimum level of planning you should do for even the smallest of projects, for three reasons: (1) Without a plan you can’t be sure you fully understand what’s actually needed; (2) even with a small project, everyone on the team needs to know what they’re responsible for and when it’s due; and  (3) you don’t know it’s that small until after you plan it.

The project in question didn’t suffer from the first issue. It was a software upgrade. Everyone did understand its point and what it was supposed to accomplish (upgrade the software without disrupting the business).

This doesn’t make the issue irrelevant. It means the project manager got lucky. As it happens, there was no desire to look for business advantages from new features the upgrade provided, but there could have been. The project manager should have asked, and would have had he created a charter.

The second issue? You bet. The project in question got messy during testing. (Yes, it can happen … Trust me!)

The reason it got messy was that (another situation you’ve never heard of before) there was no test plan, so everyone involved in testing just banged away on the keyboard until they couldn’t think of anything else to put in.

Which was fine until the time came to cut over to the new system. That’s when the team member responsible for testing got the jitters, and started to think of new tests to run. And more new tests. And more …

The project manager was understandingly unhappy with Testing Guy, but his unhappiness was misplaced. As it turned out, Testing Guy wasn’t a software quality assurance professional, and had no background to understand that there were such things as formal test plans, let alone what a formal test plan looks like.

Which would have been okay had the list of project deliverables included a test plan, or if the task list had included a task labeled “create test plan.” But it didn’t include a test plan on the deliverables list because there was no list of project deliverables, because there was no project charter. There was no appropriately labeled task because there was no project schedule either, because the project was too small to need either one.

That leaves the third and most obvious reason that even the smallest project needs a charter and schedule: Until you have them, you don’t know the project is small enough that it doesn’t need a charter and schedule.

Unless you have an exceptionally well-developed beezer, you can’t determine a project’s size by smell. What you need is a plan — to know what you’re supposed to produce, what it’s for, what it will take to build, and when it’s due. You might then find the project really was too small to plan.

But I doubt it. Even small projects are hard. And the smaller you assume they are, the harder they’ll turn out to be.