How to share project plans with the team

Question

This may look a bit weird, but I stuck with the problem of sharing the project plans with team. The main purpose I try to achieve (though not sure if it's right) is that everyone should know what to do next (and do not ask about this every time he ends with current item) and to see the full picture of upcoming tasks.

Here's a list of approaches with their cons I see:

1. Board. Problem - when priority (and even entire list) of tasks is changed it's difficult to re-write it.
2. Project management software. (we use Goplan currently). Problem - not all tasks/small projects are managing here, sometimes it's not possible/easy for a member to recognize the right priority.
3. Google docs spreadsheet. Problem - not sure how to be with e-mail notifications so the team know when something is changed.

Also I'd like to reduce the number of software/instruments I use in project management (currently, it's web-based project management software to collaborate with customers, assigning tasks/tickets + my mind maps + one of the above things) to concentrate more on other aspects and not just do the copy-paste from program A to program B.

If this helps, the team size is 3-4 people now, the projects are websites/web-systems.

UPD: The point is I'm not sure what's the most efficient approach:

• say, every morning, tell everybody the list of tasks/bugs to be done this day

• give a schedule of tasks for a week/month

• task by task. When the work on task A is completed, tell about the task B.

UPD2: I guess I haven't clearly clarified this, but the problem is that requirements changes every day (and even during the day) and new important tasks/issues may arrive at anytime.

Hope this clarifies the initial question a bit.

Thanks.

Answer 1

Everyone works differently, and everyone wants different things from the manager. Some want to be given a task, then complete it, then be given another task... and so on. Some want to know the big picture and be left to manage their own time and priorities within it, and only be told when something material changes. And others will be at different points between the two extremes. No tool can resolve this for you, because you are dealing with people who don't fit into with an idealised model.

What I would do is have a regular but short team session. 5 to 15 minutes should be plenty. Have this daily if that works for you, or less frequently if you prefer. If you are using an agile methodology (scrum) then you should be doing this anyway. At that meeting, give the headlines, listen for warning signals, and as appropriate, hand out the day's tasks. Follow up specific issues and concerns on a one-to-one level outside the meeting if necessary. By the way, if you are accepting revised requirements or changing priorities on a daily basis, something is wrong with either the team's work, or you have a flawed relationship with your customers, or you need to think again about the way that you react to external influences.

Question: do all issues and change requests come through you, or direct to the person in the team who is best able to deal with them? If they all come to you, ask yourself why. Why should you act as a buffer? Wouldn't it be better to set out guidelines for the team to help them to prioritise, and let them work within these guidelines, without you having to get involved all the time?

If you must have tools, try using a spreadsheet of "must do" tasks that you print out and stick on the wall every week. Have sufficient slack within this to allow you to accommodate new, unplanned demands, and use sticky notes to capture these and move them around as priorities change. Software solutions are possible, but the physical act of moving yellow stickies around a sheet of A3 paper gives a sense of ownership, for reasons that I can't quite understand. It also conveys a sense of urgency if they all start piling up against Friday afternoon...!

Answer 2

Keep it simple. Make sure your team knows where they are headed, then let them figure it out. I am a huge fan of formal processes to optimize flow, efficiences, and productivity. A small team like yours has a way of creating this almost naturally. They will create the path of least resistance. If a new requirement comes down, give it to them and then let them go.

At all costs, don't introduce another tool.

Answer 3

I noticed that you felt using a "board" was a con when tasks have to get rewritten. I don't see that as a con. I think the biggest think you can do for the team is help them visualize the work. I have found boards to work best for this.

The teams work in "sprints" and fill in the board with their expected tasks and priorities every two weeks, if things are added/removed/changed along the way, then fine, we have probably learned something. One thing we do differently though is that every task is associated with some larger feature or priority and so our daily updates are more focused on how we are moving forward to complete the feature, which may be a task.

Sometimes this also helps the team get used to thinking about what they need to do as a team, instead of individuals, so they can look at the board and see where they might help someone else with the current priorities instead of asking what to do next.

On the tools comments, we also use a few different online/electronic tools for collaboration, but we bring them all together on the board for a single priority list and daily discussion. We have found this to be one of the most valuable parts of using a board.