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:
they can't be completely worthless
Yes they can. What's their relationship to the project? Is it their only project? How do they get paid--by the hour, by the milestone? What's their skillset with relation to the project? How did you find them, and why are they interested in working with you, besides the money? What's the current contract with them say (or is it a verbal agreement)? Can their rate be docked if they deliver late? The reason I ask all these questions is, you basically need to figure out what their motivation is, and you need to figure out if they really are the right people for the project. What you describe in "I need to sit down and..." should actually be done by them as part of the verification that they did the job right. There's clearly a problem that doesn't lie entirely with your difficulty in communicating. Communication is a two way street. Ask yourself how these fellows are failing at communicating and if/how they are taking advantage of you. Anyways, if you can elobrate on the above questions/thoughts, I can see what other ideas I come up with. 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 -
Shog9 wrote:
they can't be completely worthless
Yes they can. What's their relationship to the project? Is it their only project? How do they get paid--by the hour, by the milestone? What's their skillset with relation to the project? How did you find them, and why are they interested in working with you, besides the money? What's the current contract with them say (or is it a verbal agreement)? Can their rate be docked if they deliver late? The reason I ask all these questions is, you basically need to figure out what their motivation is, and you need to figure out if they really are the right people for the project. What you describe in "I need to sit down and..." should actually be done by them as part of the verification that they did the job right. There's clearly a problem that doesn't lie entirely with your difficulty in communicating. Communication is a two way street. Ask yourself how these fellows are failing at communicating and if/how they are taking advantage of you. Anyways, if you can elobrate on the above questions/thoughts, I can see what other ideas I come up with. 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:
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
-
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
-
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
-
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
Hmm.... how about setting (or agreeing) dates for initial and full analysis then when you have that a date for the fix?
-
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