Looking for advice: project management / delegation...
-
So i have something like six urgent bugs to fix, and two consultants to assign them to. Trouble is, if i just assign them, they won't get done - i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed. So i need to sit down and actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone. As you can probably imagine, this doesn't really save a lot of time over just fixing the damn things myself. :sigh: So i need some advice. While i know these aren't the shiniest tools in the shed, they can't be completely worthless - somehow, i'm just not making proper use of them. There must be a better way of communicating what i need, and how to go about accomplishing it... but, i'm absolutely terrible at communicating with other people even at the best of times, and this sure ain't that. Any suggestions? Tricks? Fun games to take my mind off it?
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
Shog9 wrote:
i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed. So i need to sit down and actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone. ... Any suggestions?
Yes. Get better "consultants". No, really. -- modified at 18:51 Sunday 8th April, 2007 I'll explain why I said that: what you're suggesting is (imho) the right approach to finding and fixing the bugs. But it's something you should be able to hand off to a capable developer. It appears that you're not in a position to enforce the "capable" aspect. Am I right? Or am I reading too much into your post? /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
The interesting point about Shogs question is: What if you can't get more capable developers?
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist -
Marc Clifton wrote:
What's their relationship to the project?
Someone told our VP that foreign consultants were Teh Sh!t, so that's what we're getting to replace coders lost through attrition.
Marc Clifton wrote:
Is it their only project? How do they get paid--by the hour, by the milestone?
No. Hourly, i believe.
Marc Clifton wrote:
What's their skillset with relation to the project?
Based on my own observation, on a scale of 1-5 (with 5 being competent and 1 being the echo from a long piece of PVC):
- Basic (programming) language: 4
- Basic (English) language: 3
- Analysis: 3
- Verification: 3
- Documentation: 2
- Regression testing: 1
Or to put it another way: given a problem, they can find and implement working solution just over half the time, communicate that solution about 2/3rds of the time, and with a lot of luck and a little assistance, verify that it hasn't broken anything else about one time out of five.
Marc Clifton wrote:
What's the current contract with them say (or is it a verbal agreement)? Can their rate be docked if they deliver late?
I haven't been given much in the way of information here... From the look of things, the only people my opinion actually matters to have no power to change things (their contract is re-negotiated periodically based on how many warm bodies we think we need.)
Marc Clifton wrote:
Ask yourself how these fellows are failing at communicating and if/how they are taking advantage of you.
I already know the answers to those questions. I'm tilling a garden with a teaspoon. But i've spent half my life creating tools when none were available and making computers do things that don't seem to be possible given the constraints in place... i'm just hoping i can learn to do this with people. I appreciate all the advice i've been given here today... this is why i love CP - programming problems i can usually find a solution to, but stuff like this just throws me.
----
It appears that everybody is under the impression th
Shog9 wrote:
but stuff like this just throws me.
Ah, it sounds like the small outsource team my client once hired. Mostly capable, as long as what they were doing was "by the book".
Shog9 wrote:
From the look of things, the only people my opinion actually matters to have no power to change things
Well then, this usually falls into the category of "the only person you can change is you." In other words, if your team doesn't take bugs and deadlines seriously, then you can't either--it's like tilting at windmills (or whatever the expression is).
Shog9 wrote:
But i've spent half my life creating tools when none were available and making computers do things that don't seem to be possible given the constraints in place... i'm just hoping i can learn to do this with people.
I've taken Dale Carnegie's "How to win friends and influence people" course, then was a teacher assistant for it, worked with people in person and half a world away, and no matter what you try, it comes down to chemistry and ethics. If there's no chemistry between two people, it creates imbalance. If a team member has no sense of ethics regarding the work, it creates imbalance. The only thing you can fall back on is a strong manager that gets rid of the people that aren't working out or motivates them with a big stick. Rarely, very rarely, is there a manager who can really inspire people and bring out the "ideal" in them. But as a "peer", I'm in the same boat, I've never figured out how to motivate coworkers. As a result, I just do what I can do, but I don't try to pick up the slack anymore. I used to, and the reaction from the slackers would be to slack even more, and I would get angry and frustrated and hate my job. Computers are much easier to work with than people. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
The interesting point about Shogs question is: What if you can't get more capable developers?
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighistpeterchen wrote:
What if you can't get more capable developers?
If that's the case (as it might well be), he's probably going to be expending more effort in using the assigned developers vs. doing the work himself. The solution lies in someone higher up in the food chain being made aware and convinced of this. /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
-
Bassam Saoud wrote:
If they are not good at what they do, why do you keep them around?
The VP decided that we were doing this outsourcing thing. To Infosys. On the cheap. I've argued, but that doesn't go anywhere - i'm just the guy who gets shit done. So, time to make the best of it.
Bassam Saoud wrote:
I am speaking with experience as I am a consultant and in similar cases I always hold meetings and discussions with the PM and with the team that end up putting a road map to the solution as well as a timeline
Yeah, that's looking like something i'm gonna have to try. It grates on me, because... well, i'm used to tracking down problems that aren't properly documented, in rotten old code that isn't commented, sitting alone in a room for hours with a Sharpie and a ream of printouts if that's what it takes... it feels like i have to baby these guys. But perhaps that's just another conceit i have to work past. :sigh: :-O
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
Shog9 wrote:
it feels like i have to baby these guys. But perhaps that's just another conceit i have to work past
The hardest part of managing people is to stop managing people. Give them tasks, tell them when you want it done, then get out of their way. If you constantly babysit people, people will act like babies. Treat them like adults. If they screw up, pin the tail on the donkey (but make sure you have documented your end to CYOA).
-
Shog9 wrote:
but stuff like this just throws me.
Ah, it sounds like the small outsource team my client once hired. Mostly capable, as long as what they were doing was "by the book".
Shog9 wrote:
From the look of things, the only people my opinion actually matters to have no power to change things
Well then, this usually falls into the category of "the only person you can change is you." In other words, if your team doesn't take bugs and deadlines seriously, then you can't either--it's like tilting at windmills (or whatever the expression is).
Shog9 wrote:
But i've spent half my life creating tools when none were available and making computers do things that don't seem to be possible given the constraints in place... i'm just hoping i can learn to do this with people.
I've taken Dale Carnegie's "How to win friends and influence people" course, then was a teacher assistant for it, worked with people in person and half a world away, and no matter what you try, it comes down to chemistry and ethics. If there's no chemistry between two people, it creates imbalance. If a team member has no sense of ethics regarding the work, it creates imbalance. The only thing you can fall back on is a strong manager that gets rid of the people that aren't working out or motivates them with a big stick. Rarely, very rarely, is there a manager who can really inspire people and bring out the "ideal" in them. But as a "peer", I'm in the same boat, I've never figured out how to motivate coworkers. As a result, I just do what I can do, but I don't try to pick up the slack anymore. I used to, and the reaction from the slackers would be to slack even more, and I would get angry and frustrated and hate my job. Computers are much easier to work with than people. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
Computers are much easier to work with than people.
The next version release of people should come equipped with OFF switches.
-
I'd love to know what Infosys is billing you for these guys....
Charlie Gilley Will program for food... Whoever said children were cheaper by the dozen... lied. Yeah, whatever....
-
peterchen wrote:
What if you can't get more capable developers?
If that's the case (as it might well be), he's probably going to be expending more effort in using the assigned developers vs. doing the work himself. The solution lies in someone higher up in the food chain being made aware and convinced of this. /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
The solution lies in someone higher up in the food chain being made aware and convinced of this.
That may well be what this comes down to. Based on the advice i've gotten here, i plan to switch tactics: rather than trying to pass off bugs, i'll perform a very brief initial analysis, spec out milestones and estimate the time involved for each, and then track each: for every milestone missed or task that i have to end up doing myself, i'll log it as a contributing factor to delays on my own tasks (rather than putting in overtime to compensate). When the next release slips... well, one way or another, i guess i'll know where i stand.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
Shog9 wrote:
but stuff like this just throws me.
Ah, it sounds like the small outsource team my client once hired. Mostly capable, as long as what they were doing was "by the book".
Shog9 wrote:
From the look of things, the only people my opinion actually matters to have no power to change things
Well then, this usually falls into the category of "the only person you can change is you." In other words, if your team doesn't take bugs and deadlines seriously, then you can't either--it's like tilting at windmills (or whatever the expression is).
Shog9 wrote:
But i've spent half my life creating tools when none were available and making computers do things that don't seem to be possible given the constraints in place... i'm just hoping i can learn to do this with people.
I've taken Dale Carnegie's "How to win friends and influence people" course, then was a teacher assistant for it, worked with people in person and half a world away, and no matter what you try, it comes down to chemistry and ethics. If there's no chemistry between two people, it creates imbalance. If a team member has no sense of ethics regarding the work, it creates imbalance. The only thing you can fall back on is a strong manager that gets rid of the people that aren't working out or motivates them with a big stick. Rarely, very rarely, is there a manager who can really inspire people and bring out the "ideal" in them. But as a "peer", I'm in the same boat, I've never figured out how to motivate coworkers. As a result, I just do what I can do, but I don't try to pick up the slack anymore. I used to, and the reaction from the slackers would be to slack even more, and I would get angry and frustrated and hate my job. Computers are much easier to work with than people. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
Well then, this usually falls into the category of "the only person you can change is you." In other words, if your team doesn't take bugs and deadlines seriously, then you can't either--it's like tilting at windmills (or whatever the expression is).
Yeah... you know, this might sound bad, but i've always felt that it's a sign of impending doom if i start to actually give a sh*t about the company i work for. Time to take a step back and let the ships fail where they may... (to mangle another old saw :snicker: ) Thanks, Marc.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
Shog9 wrote:
it feels like i have to baby these guys. But perhaps that's just another conceit i have to work past
The hardest part of managing people is to stop managing people. Give them tasks, tell them when you want it done, then get out of their way. If you constantly babysit people, people will act like babies. Treat them like adults. If they screw up, pin the tail on the donkey (but make sure you have documented your end to CYOA).
Ed Gadziemski wrote:
If they screw up, pin the tail on the donkey (but make sure you have documented your end to CYOA).
Aye. Sounds cynical as hell, but i think that's gonna be the way to go.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
Marc Clifton wrote:
What's their relationship to the project?
Someone told our VP that foreign consultants were Teh Sh!t, so that's what we're getting to replace coders lost through attrition.
Marc Clifton wrote:
Is it their only project? How do they get paid--by the hour, by the milestone?
No. Hourly, i believe.
Marc Clifton wrote:
What's their skillset with relation to the project?
Based on my own observation, on a scale of 1-5 (with 5 being competent and 1 being the echo from a long piece of PVC):
- Basic (programming) language: 4
- Basic (English) language: 3
- Analysis: 3
- Verification: 3
- Documentation: 2
- Regression testing: 1
Or to put it another way: given a problem, they can find and implement working solution just over half the time, communicate that solution about 2/3rds of the time, and with a lot of luck and a little assistance, verify that it hasn't broken anything else about one time out of five.
Marc Clifton wrote:
What's the current contract with them say (or is it a verbal agreement)? Can their rate be docked if they deliver late?
I haven't been given much in the way of information here... From the look of things, the only people my opinion actually matters to have no power to change things (their contract is re-negotiated periodically based on how many warm bodies we think we need.)
Marc Clifton wrote:
Ask yourself how these fellows are failing at communicating and if/how they are taking advantage of you.
I already know the answers to those questions. I'm tilling a garden with a teaspoon. But i've spent half my life creating tools when none were available and making computers do things that don't seem to be possible given the constraints in place... i'm just hoping i can learn to do this with people. I appreciate all the advice i've been given here today... this is why i love CP - programming problems i can usually find a solution to, but stuff like this just throws me.
----
It appears that everybody is under the impression th
Shog9 wrote:
Documentation: 2 Regression testing: 1
in that case, and seeing as it's your 'shop', is there anything you can do when you get these guys to make life easier for them (*1) to provide you what you need ... just before anyone jumps off the deep and, and freely admitting where I work we dont do it either, but we would like to give all contractors a 'xyz guide to working at abc co' booklet, outlining what build, documentation and testing frameworks exist at abc co and how they are expected to use them (and the penalties for not using them).... (*1) sigh, I know, give contractors something to make their life easier so that they can make your life easier - almost a bit chicken and egg-ish .. but I dont think you can expect a contractor to walk onto a site and know def framework these days ... if they know what testing means or how to spell or or that they should be doing it, then showing them how you'd like it done is likely as good as you'll get (who knows, if they learn it you might ask them back) ... what I mean here in all this is have a documented methodology for your dev process - that way the contractors can concentrate on the bugs etc ... unless you also have a test, build manager etc who can shepherd them 'g'
-
So i have something like six urgent bugs to fix, and two consultants to assign them to. Trouble is, if i just assign them, they won't get done - i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed. So i need to sit down and actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone. As you can probably imagine, this doesn't really save a lot of time over just fixing the damn things myself. :sigh: So i need some advice. While i know these aren't the shiniest tools in the shed, they can't be completely worthless - somehow, i'm just not making proper use of them. There must be a better way of communicating what i need, and how to go about accomplishing it... but, i'm absolutely terrible at communicating with other people even at the best of times, and this sure ain't that. Any suggestions? Tricks? Fun games to take my mind off it?
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
Shog9 wrote:
actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone.
If i were you and if i could not change them, i would divide the problem fixing into two parts the first part will be this(above) , ASK them (the consultant) to do this and then in the second part ASK them to fix it. and at all times you look into them from a distance and smile :)
Omit Needless Words - Strunk, William, Jr.
Vista? Photoshop Preview Handler here
-
Probably just as well i don't know that.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
:)
Rocky <>< Latest Code Blog Post: OpenID - More thought - Great system if.. Latest Tech Blog Post: Want to test Joost (video on demand) - I have invites!
-
So i have something like six urgent bugs to fix, and two consultants to assign them to. Trouble is, if i just assign them, they won't get done - i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed. So i need to sit down and actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone. As you can probably imagine, this doesn't really save a lot of time over just fixing the damn things myself. :sigh: So i need some advice. While i know these aren't the shiniest tools in the shed, they can't be completely worthless - somehow, i'm just not making proper use of them. There must be a better way of communicating what i need, and how to go about accomplishing it... but, i'm absolutely terrible at communicating with other people even at the best of times, and this sure ain't that. Any suggestions? Tricks? Fun games to take my mind off it?
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
By consultant, I'm assuming you mean free lance consultant (ie you are employing them). Frankly, if I had the kind of fears that you have with them I wouldn't be employing them. I have had this situation in the past and I found the great motivator was "do you want to get paid?" Its fine if there are problems that make tracking down and fixing a bug longer than expected but you should get detailed explanations for why. When I've asked for these in the past miraculously a cure is found. Good luck (I feel your pain :))
-
By consultant, I'm assuming you mean free lance consultant (ie you are employing them). Frankly, if I had the kind of fears that you have with them I wouldn't be employing them. I have had this situation in the past and I found the great motivator was "do you want to get paid?" Its fine if there are problems that make tracking down and fixing a bug longer than expected but you should get detailed explanations for why. When I've asked for these in the past miraculously a cure is found. Good luck (I feel your pain :))
Sorry, I've just read the above thread saying you are stuck with them. As someone else has already pointed out, you need some help form higher up, someone who can make the do or die decision. Its not easy do deal with this, but in the end the buck is going to stop with you. You need to do whatever it takes to make sure that those that need to know are aware of the problem. Waiting until their are problems will look like you're making excuses. Get in early and pass it up the food chain. Cheers
-
So i have something like six urgent bugs to fix, and two consultants to assign them to. Trouble is, if i just assign them, they won't get done - i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed. So i need to sit down and actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone. As you can probably imagine, this doesn't really save a lot of time over just fixing the damn things myself. :sigh: So i need some advice. While i know these aren't the shiniest tools in the shed, they can't be completely worthless - somehow, i'm just not making proper use of them. There must be a better way of communicating what i need, and how to go about accomplishing it... but, i'm absolutely terrible at communicating with other people even at the best of times, and this sure ain't that. Any suggestions? Tricks? Fun games to take my mind off it?
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
Try the carrot and stick method big stick and :confused: even bigger carrot. Beat them with the stick to get them motivated and if the do not perform :zzz: then try the carrot. Shove it up their A**** :mad: as you show them the door. The old ways are still the best! :rolleyes:
Bird with no beak was born to succeed.
-
Shog9 wrote:
but stuff like this just throws me.
Ah, it sounds like the small outsource team my client once hired. Mostly capable, as long as what they were doing was "by the book".
Shog9 wrote:
From the look of things, the only people my opinion actually matters to have no power to change things
Well then, this usually falls into the category of "the only person you can change is you." In other words, if your team doesn't take bugs and deadlines seriously, then you can't either--it's like tilting at windmills (or whatever the expression is).
Shog9 wrote:
But i've spent half my life creating tools when none were available and making computers do things that don't seem to be possible given the constraints in place... i'm just hoping i can learn to do this with people.
I've taken Dale Carnegie's "How to win friends and influence people" course, then was a teacher assistant for it, worked with people in person and half a world away, and no matter what you try, it comes down to chemistry and ethics. If there's no chemistry between two people, it creates imbalance. If a team member has no sense of ethics regarding the work, it creates imbalance. The only thing you can fall back on is a strong manager that gets rid of the people that aren't working out or motivates them with a big stick. Rarely, very rarely, is there a manager who can really inspire people and bring out the "ideal" in them. But as a "peer", I'm in the same boat, I've never figured out how to motivate coworkers. As a result, I just do what I can do, but I don't try to pick up the slack anymore. I used to, and the reaction from the slackers would be to slack even more, and I would get angry and frustrated and hate my job. Computers are much easier to work with than people. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
Computers are much easier to work with than people.
And people wonder at the origin of my misanthropy. :laugh:
-- CleaKO The sad part about this instance is that none of the users ever said anything [about the problem]. Pete O`Hanlon Doesn't that just tell you everything you need to know about users?
-
I hear you it is a difficult. It is kind of strange to hear myself say this but have you ever used Scrum? I have been in a department using Scrum now about 8 months and it has some useful features. I like the daily standup and the sprints but the most useful thing so far has been knowing when something is going wrong early. Consultants may not be so eager about it but at least you know what is getting done every day. It has made a big difference for us but it took a bit to get everyone onboard but after they saw how it worked it was ok.
We have daily team meetings that last about 15-30 minutes. It gives everyone an opportunity to vent, gives us a chance to sound each other out for solutions to sticking points, brings blocking issues to the surface so that they can be dealt with, and (most importantly for you, it sounds like) gives me a chance to get status updates from each individual on the team. When you ask someone how task "x" is going in front of the team, they generally have to have something to say. It doesn't take people many meetings to figure out that blank stares, dumb looks, and ringing silence are not conducive to continued employment. And as long as you take notes, you'll have the documentation you need to resolve the issue by firing the consultant.
Grim
(aka Toby)
MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL GO
(0 row(s) affected)
-
Break the task up just as you said you would do it yourself:
Shog9 wrote:
research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then fix assign the bug to someone.
Put deadlines on the parts and schedule status meetings to discus results at each milepost. You need to make it a practice to get more than just bug fixes out of this - get some usable regression tests as well.
I'm not surprised how many 'beat the horses into submission' suggestions appeared in this thread, but it's really a low-level way of thinking, imho. There were a couple of good suggestions but i think they were kind of read-between-the-lines things that should be re-iterated. You have to look at yourself and be sure you want to manage the two consultants and not just plug along in your comfort zone of analyzing and fixing code yourself. You have to know yourself. As regards the consultants, this is a wheel that has been invented a few times before. Make the end objective clear, make the incremental objectives (mileposts) clear, and get absolute unequivocal buy-in from the consultants and from your manager that this is the path to run. Then, set them free to earn their money. You want to focus on the goals more than how they are achieved. When (not if) they do not meet goals, find out why and facilitate. (I always like 7am meetings until a crisis is resolved.) Treat them the way you would want to be treated, but do not assume that their methods and values are the same as yours. Embrace the differences. Good luck and welcome to a new level in your career. Good luck.
-
So i have something like six urgent bugs to fix, and two consultants to assign them to. Trouble is, if i just assign them, they won't get done - i'll get vague status reports for a few weeks, and then some poorly-worded explanation of why it can't be fixed. So i need to sit down and actually research the problem, find the area where the root problem lies, write some test cases to illustrate the problem and verify when it's been fixed, and then assign the bug to someone. As you can probably imagine, this doesn't really save a lot of time over just fixing the damn things myself. :sigh: So i need some advice. While i know these aren't the shiniest tools in the shed, they can't be completely worthless - somehow, i'm just not making proper use of them. There must be a better way of communicating what i need, and how to go about accomplishing it... but, i'm absolutely terrible at communicating with other people even at the best of times, and this sure ain't that. Any suggestions? Tricks? Fun games to take my mind off it?
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
That sounds like you hired somebody to do a job, and they can't do it. When that is the case, there is only one solution. You shouldn't have to do the whole job yourself... you hired somebody else!
"Quality Software since 1983!"
http://www.smoothjazzy.com/ - see the "Programming" section for freeware tools and articles.