Looking for advice: project management / delegation...
-
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. -
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.
Rob Graham wrote:
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 was about to write the same thing, so instead I'll second the recommendation. Also be clear about what you want documented and how, so that you've got clear standards to enforce along with the schedule.
-
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:
If a team member has no sense of ethics regarding the work, it creates imbalance.
I've had problems with junior staff (as a consultant) and found that if you have limited time to "coach" people or not enough time to get rid of them, then you just have to focus on channeling their behavior. The missus used to teach management courses, which she freely admitted was a waste of time in most cases, but she did give me this useful list of task management approaches to go through. In order of increasing ability to take something and run with it: * telling (thou shalt do X in the following steps at the following intervals) * selling (Hey, you really want to do X!) * participating (Let's do X together! [urgh]) * delegating (get X done by time Y, see you then.) If you've got consultants who are paid to support you, as customer you should really only have to pick between telling and delegating. If they can't be trusted to deliver in a given timeframe with limited guidance, then it's time to tell them what to do and make them hit incremental reporting and progress goals.
-
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
Are you using a bug / feature tracking system? It's a good way to see what your developers are doing. Assign priorities to the bugs and anything with a top priority has to be fixed first. That's a good start.
Todd Smith
-
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
Shog9 wrote:
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.
I agree with Ed, that's the only way I've found it get it done. I would add that as PM in these types of situations (poor performers) you may also want to communicate status to your boss. I've found that communcating up can be as important as communicating down - especially when there are issues.
-
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
Welcome to management
-
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
Project Management Problem:
How to assign tasks, set milestones, document and get out of their way.
I personally recommend you implement www.easyprojects.net a web based project/task/time tracking product You can self host using any crap xp windows machine in your office [i.e secure & no server/hosting fees required] It is the cheapest ($89 for 1 user & ~1K for 10 user) and easiest. I have been using it for several years and it works! Log onto the demo and have a play Easyprojects Demo Simple Process (via a web browser) -------------- 1. Create a Task & assign (Automatically sends an email to asignee) 2. Staff then record time & progress. Its got loads of reporting features, its simple and fast. (You can also Outline project in MsProject and import, useful for large projects) n.b. Projects are buckets for tasks Best of all it works, has little impact on workflow and is easy to use. I wish there were more products like this! David :laugh: www.dmvdesigns.com Complete Product Development Industrial design, Engineering, Drafting, Consulting, Model shop services and more.
-
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
Looking at some of your other posts in this thread it sounds like you are trying to manage resources (consultants) that are outside of your direct control. This is not a fun position to be in, especially if your VP seems unsympathetic. From similar experience, the best advice I can give is to first establish how these six urgent problems are going to affect your business. If you have any project responsibility then you should have access to and consult the principal stakeholder -- this is the person in your organization who [should] have the final say and vested business interest in the service/application/project/product's successful outcome. If you don't know who that is then you're in trouble and need remedy asap. This could be your VP or someone else. Make sure you understand their goals, priorities, and needs so that you can frame your problems against them. Just talking technical may not make any impact. Regardless, make them understand how your problems are theirs too and get them on your side. Find out, if you can, what commitments the consultants have and their priorities. They may simply not have the time and are just not skilled enough to say 'no' directly. Explain the problem to them and how the business and you are being affected - yes, you're appealing emotionally to their better nature! That may be enough to swing a real commitment from them. If not, or they just don't care, or are not approachable then: i) find out who is responsible for the consultants time; ii) try the same negotiation with them; iii) if that fails, escalate the problem with the principal stakeholder -- it's time for their direct involvement! If the problems are serious enough then someone in the relationship chain is going to have the political/commercial clout to command some real action. If it reaches that point remember to keep things positive and business-like since if you get the outcome you want you're going to be working with those people to get the job done. Show your appreciation to all in case you need to call upon them again. If after all that, things still go south then order the biggest chocolate cake for yourself and consider if it's time for a better position elsewhere ;)
-
Looking at some of your other posts in this thread it sounds like you are trying to manage resources (consultants) that are outside of your direct control. This is not a fun position to be in, especially if your VP seems unsympathetic. From similar experience, the best advice I can give is to first establish how these six urgent problems are going to affect your business. If you have any project responsibility then you should have access to and consult the principal stakeholder -- this is the person in your organization who [should] have the final say and vested business interest in the service/application/project/product's successful outcome. If you don't know who that is then you're in trouble and need remedy asap. This could be your VP or someone else. Make sure you understand their goals, priorities, and needs so that you can frame your problems against them. Just talking technical may not make any impact. Regardless, make them understand how your problems are theirs too and get them on your side. Find out, if you can, what commitments the consultants have and their priorities. They may simply not have the time and are just not skilled enough to say 'no' directly. Explain the problem to them and how the business and you are being affected - yes, you're appealing emotionally to their better nature! That may be enough to swing a real commitment from them. If not, or they just don't care, or are not approachable then: i) find out who is responsible for the consultants time; ii) try the same negotiation with them; iii) if that fails, escalate the problem with the principal stakeholder -- it's time for their direct involvement! If the problems are serious enough then someone in the relationship chain is going to have the political/commercial clout to command some real action. If it reaches that point remember to keep things positive and business-like since if you get the outcome you want you're going to be working with those people to get the job done. Show your appreciation to all in case you need to call upon them again. If after all that, things still go south then order the biggest chocolate cake for yourself and consider if it's time for a better position elsewhere ;)