Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Re: Failure To Refactor

by Rex(Wrecks) (Curate)
on May 15, 2002 at 05:39 UTC ( #166651=note: print w/replies, xml ) Need Help??

in reply to Failure To Refactor

++ on the node, and sorry about the project.

I worked on a similar project some years ago, and your ideas are very sound. I would add a couple that I have learned along the way as well. These have been crucial in the joint projects I have worked on. Your mileage may vary:

Assign an Owner

Projects need an Owner, and someone who is, ultimately, responsible for the outcome. Loose groups seldom work unless the group has worked together for some time and knows the others habits and styles. You touch on this in "Who's The Boss" above, but I would advocate that a "Leader" per-say may not be the same as an Owner. With an Owner you have acountability and therein lays one of the secrets. Someone is accountable!

Get buyoff from Management

Present a plan to management, and don't start until you get paper signed buyoff. This can be tricky, and details may change, but getting approval can save headaches later. Your plan should include who will be the Owner of the project and what resources and/or authority the Owner will require. This may not end up being you! But if it is you, present a clear goal to your team, and modify it with their input. Ideally this is done before the buyoff from management.

I hope this gives some input and sheds some light for you. These are a couple things I use to keep my life sane when working on group projects.

"Nothing is sure but death and taxes" I say combine the two and its death to all taxes!

Replies are listed 'Best First'.
Becoming the Owner
by pdcawley (Hermit) on May 15, 2002 at 20:12 UTC
    If you become the owner of one of these projects it is really important that you are free to choose who you have on your team. Ideally you want to keep the people who've been maintaining the code up to now, but if it becomes impossible to work with them then you must be able to either fire them (from the project) or be able to walk away yourself.

    Walking away is a drastic option, no question, but there may come a point where continuing to work with a team you don't get on with is doing you far more harm than good.

    Remember, if you're the Owner then you are responsible, do everything in your power to make sure that you deliver. And if you reach the point that you know you can't deliver, run, don't walk to your management and give them the bad news; putting it off will only make things worse. And if doing that loses you the job... well, if you can't change your organization, change your organization.

      "If you become the owner of one of these projects it is really important that you are free to choose who you have on your team."

      Update: Actually the above stament might be more true in smaller environments or startup situations. However I work for a large (50,000+ employees) company, and in my case it is very seldom that you get to pick and choose.

      In an Ideal World this may be true. Unfortunatly, in most cases you will be lucky to have input on who will be team members, let alone be able to choose. But you are right about one thing, you MUST have the authority to keep the group in line.

      And I also agree that management should be kept up to speed on progress, especially in the software world, where slipping dates has become the norm (and, no I don't like it anymore than anyone else).

      "Nothing is sure but death and taxes" I say combine the two and its death to all taxes!

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://166651]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (3)
As of 2021-07-30 14:28 GMT
Find Nodes?
    Voting Booth?

    No recent polls found