Should tasks be given as orders?

Question

Consider an example. An iteration plan is created by a project manager. It contains, say, 50 tasks for designers, programmers, testers. The tasks depend on each other (network diagram is ready). The PM announces the plan for the team and gets team commitment to complete it. People perform first tasks assigned to them.

Now it's time to start tasks that follow the ones already completed. Should people wait for "go ahead" from the PM? Or they should continue according to the plan? How "directive" the role of project manager should be?

Answer 1

I think the answer depends on the experience and capability of the individual worker.

A senior team member should be able to perform work without appreciable direction. They should understand the schedule because they helped create it. In many cases they will have a better understanding of the work and how it will happen than the project manager does. The relationship between a project manager and an experienced worker should ideally be at a peer-to-peer or consultative basis.

On the other end of the employee spectrum, a less capable employee will require complete supervision of their work - either by a senior worker on the team or by the project manager. For this level of worker each task would need to be checked and new tasks explicity assigned and instructions given to complete it. This is not a bad thing. Taking time and effort to train and develop new workers should be expected.

Answer 2

ADDITION: I think to level set the answers the OP needs to describe the level in the WBS or schedule about what he was thinking when asking this question. I am inferring from many of the answers provided here that many are describing a situation where a competent and experience technologist is asking the PM permission to do the next task every 15 minutes of 1/2 hour. I described in my answer below a situation of controlling work packages, wherein you can have hundreds of activities and tasks and can span a duration of days, months, or even years on really complex projects.

Part of cost and schedule control is this concept of the Work Authorization Document (WAD). This document, delivered to the team and / or individual resource, is the control order that describes what work is being performed, by whom, when, and where, the target cost and time, and the method of tracking their work hours, e.g., charge code(s).

The WAD can contain a single work package or several, depending on the nature of the work, dependencies, and risks. The team or individual is authorized to perform the work issued in the WAD and nothing else.

Carte blanche approval to just allow work to go without these types of controls means your project is out of control. Work and materiel need to be coordinated, risks and issues need to be worked through, cost and schedule variances need to be mitigated, change requests need to be assessed and scheduled, and scope needs to be verified and validated. Too much else goes on within a project for a shotgun release to be effective.

Answer 3

Is there a benefit to waiting to begin? Is there a cost in waiting? How do they compare?

I used to (long time ago) try to manage things this way, but beyond a few simple cases, trying to keep individuals in lock step while one person encountered a problem proved to be more of a headache than it was worth. What usually happens is either lots of slack is built into the plan (to allow for the variations) which builds in some inefficiencies to the plan, or you end up replanning once a week to compensate.

It was an interesting experience for me to really look into what was happening in the team. I realized that trying to model the very tightly coupled interactions with FF, FS, SF, and SS dependencies couldn't get me a stable model (one that didn't require constantly updating each week) Adopting the attitude of "I don't care what you do on M-F, so long as by Friday the team has accomplished X, Y and Z" (and the team gets to say what x, Y and Z are!) left the team to structure their work more effectively, and I ended up managing "week chunks" which we much easier to handle and replan as needed. Planning was then at a week basis and everyone aligned during the week. Because of this, people knew about how much "free time" they had for the week and could offer to help others who might be overloaded. (This was my "self discovery of Scrum")

Your example is programming (also my area of experience) so I'm not sure my answer applies to other domains (for example, in construction, there may be very good engineering and safety reasons to wait until the PM gives the go ahead)

Answer 4

In principle, I like to give teams (and individuals) the freedom to get on and do the work when they are ready to do it. However, there may be occasions where this is inappropriate:

For example, if waiting for a product to be Quality Assured, or an interface design to be approved, or something of that nature, then that is not an appropriate time for the team to do that work. You should not allow the team to make assumptions that the draft versions of such documents will remain unchanged, and you don't want to have to unpick work that was started on the basis of such assumptions.

The other situation is where you are using stages for governance of the project. No work should span a stage boundary (using the Prince terminology) until approval is given to start the next stage. This could be because of go/no-go (gateway) technical or business decisions, or simply that the funds have not been confirmed for the next stage. Either way, each stage should stand alone.

So, in summary: Within a stage, and subject to not making assumptions as to technical standards or designs, give the team their freedom to make progress. Just make sure you don't lose control of them!

Answer 5

I agree that tasks should be given in order if the employee is not experienced, however in most cases in practice using a good Project Management System helps very much about that -- you add the task, assign a person, assign a priority and the system notifies them.

I do not believe that there is a need to waste your time in giving tasks one by one like feeding a little kid -- if they are professionals they must manage their own tasks themselves and also I believe that a Project Manager has way more important things to do.

Answer 6

Giving team members the opportunity to sign up for tasks themselves lets them make their own commitments and collaborate effectively to achieve the results. From a psychological point of view, that's hugely powerful. People are far more likely to work hard and effectively to meet their own promises than promises made on their behalf.

Assigning tasks to individuals is more likely to cause them to work in a silo'd way, focusing on their own work ahead of helping their team mates, even if that help is the most effective thing to do.

If a team doesn't seem to be signing up for the right tasks, it may be that they don't have the skills, don't feel safe signing up for something challenging, or don't understand the priorities or vision of the project. Letting a development team sign up themselves is a great way to see what's happening in the project environment, since without this the only feedback you get as a PM is the length of time it takes to do the work. If you see that team members aren't proactive, there may be something as a manager which you can do to help, ensuring that the team has sufficient vision, skill, resources and safety to succeed.