March 22, 2005
Small groups, with total control, no leader, complete trust, total transparency, and a clear achievable yet open ended goal
Getting projects done, and done well is a constant challenge. I and others I know are consistently part of teams attempting to complete projects, from logos to web designs to application UI’s to communities. Often a lack of certain elements leads to disaster, here is my incomplete collection of thoughts on what helps make projects run on a smoother track.
Small Groups
Find as few as possible people who want to do the job to complete your task. Do not be afraid to pick busy people, they often are the most efficient.
Total Control
Give up control. Once you have chosen your team, have confidence that you do not know what is best and that the team will return the best result, if not let them fix it after the proposed solution shows itself to not work. Failure is not a problem but an opportunity for everyone involved to learn what happened, and then apply that knowledge.
No Leader
Or maybe said everyone is a leader, if the group is small enough, tight enough and skilled enough I don’t think there is a need for a leader. Hold everyone accountable for the product, let no one slack.
Complete Trust
Let your team do what they know best, get out of the way and relinquish your control. You do not need to make decisions to show that you can add to the project, but answer question honestly when they are proposed by the team, then let them take or leave your feedback.
Total Transparency
As much as possible, everyone on the team or you should be able to know what is going on, and why decisions where made. This does mean you have to like the answer. Trust your team.
Clear Achievable Goal
Set a goal for the team that can be achieved. That does not mean that it can’t be something challenging, but if it seems completely out of bounds given the timeline, the project will start off under a cloud of discouragement.
Open Ended Goal
The job is never done. Do not set the expectation that at the competition date, the work is done. At completion the initial test is launched, feedback is gathered and the project is adjusted to keep what works and cut was does not.
Comments
So, did you have a bad experience and you're venting or are you just bestowing us with your wisdom? Just wondering. It does sound like a good strategy.
Posted by: Kevin Stout | March 25, 2005 10:27 AM
A bit of both, just felt like something to post about, and it seem slike something that comes up a lot.
Posted by: Anthony | March 25, 2005 11:39 PM
It sounds like many of my projects, except for the open ended goal. Usually we gather virtually, get the work done by sharing the tasks, and then drift apart when the project finishes; only to reassemble at a later date as a slightly different group.
I have worked like this with several groups of people, many of whom I've never met f2f. Nice synthesis.
Posted by: Harold Jarche | April 12, 2005 03:57 AM