from the time we’re little, we’re taught 2 lessons:

  1. respect your elders
  2. because i told you so

that first lesson can more appropriately mean, “respect those people with more authority than you” and the second as “because you’re not in a position to oppose this.” so many people grow up—go through school, life, and everything—and adhere to those rules. they enable people to lead, not because they themselves can’t lead, but because they we’re always told to follow.

so what’s all this have to do with anything? bottom line: if you tell someone to do something, chances are they’ll do it—if they know how to or not.

as a team leader, project manager, small work manager—whatever your title is—you hold power to tell people to do things that they feel they’re not allowed to challenge. even if you say, “let me know if you have any issues” people generally won’t because that’s both, (a) an admission of a lack of competence, and (b) a waste of time because even if they had a problem, they always ask themselves “would my bringing this up really change the situation?”

when we create project documents to outline the scope, goals, etc. it is vitally important that we define exactly what needs to happen before telling someone to do it.

it sounds completely stupid because it’s rather common sense, but you’d be surprised how many people don’t do it. project documents need to be descriptive, easily understood, and all goals—both functional and technical—ought to be clearly marked out. scope documents (or sections about the scope inside an overall project plan document) are not 10th grade word problems. all the requirements for work should be expressly stated.

example:

True-ups: There is a known system issue where the new rate change is not used for terminations that occurred in the prior month; therefore, a query is required to identify the retiree, alternate payee and terminated vested population affected by the new rate. Any impacted retiree payments will be recalculated and adjusted to reflect the new rate for January 1, 2008 payments. A similar true-up process will be performed for DB7.

An additional true-up query is required as part of the interim process. The query will be run in DB Module to capture new rate eligible participants who retired 3/27/08 to the DB7 Live Date (5/12/08) to ensure their benefit payment was calculated based on the correct rate. (A query to identify benefit payments that commenced 1/1/08 to 3/26/08 has already been run to validate the correct rate had been used in determining their benefit payment.)

the above would be much better described in a form such as:

true-ups

to accurately capture the information needed, we are completing 2 true-up queries to identify populations affected by the rate change. because of a known system issue with the rate changes not going into effect for participants terminated in the prior month, the two queries being performed are:

  1. a query to find: retiree, alternate payee and terminated vested populations affected.
the participant's status change must have occurred between 1 January 2008 and 26 March 2008   2. a query to find: retiree, alternate payee and terminated vested populations affected.

the participant's status change must have occurred between 27 March 2008 and 12 May 2008

these queries must be performed to adjust and recalculate payments to reflect the new rate.

the first query is run once approval is granted on the project plan for this work item. the second query will not be run until the migration has been made to our new DB7 system.

in this way, the queries are more clearly defined (though the technical requirements for these queries are, admittedly, not here for reasons i think you could probably understand). when defined in this fashion, you can see a definite breakdown of (1) the purpose, (2) what needs to happen, (3) why they need to happen, and (4) when those things need to happen. now, ok, i wrote this in what? 10 minutes here—so the wording, etc. is not exactly how i would present something like this to a client, but the information is all there as it was in the original version only it’s presented in a much more effective way.

well begun is half finished. if you clearly define what you’re doing ahead of time, you will save yourself many headaches due to rework or unnecessarily long e-mail conversations over what work needs to happen.

like i said, people will do what you tell them to if they understand how to or not. it’s up to you how easy or hard you make it, so make it easy and help them understand the work that needs to be done.