Hidden Project Changes: Team Configuration

By

scope-creepThis is the second post in a series about hidden project changes: things that affect scope but are easily overlooked. The topic for this particular post is team configuration. Feel free to read the previous post about shared code base, too.

Let me first explain what I mean by “team configuration”. To me, it does not only include who’s on your team.

Everyone involved in the successful completion of the project is on the team! This includes:

  • The project manager
  • Stakeholders
  • Sub-contractors
  • The customer
  • Steering committee

Not only is team configuration about who’s involved; it is also about each individual’s priorities and commitments, personal agendas, reasons for participating, knowledge, experience, capacity, and so on.

Members of the steering committee may be committed to other projects as well. Trying to meet all obligations, they might be tempted to split resources between projects. This, in turn, decreases productivity of all projects involved, and the individual team member’s capacity to deliver. (See my previous post about stray team members.)

If you rely on sub-contractors consider their ability to deliver on time. What level of support can they offer? How quickly do they supply bug fixes? Is their software documented? Are the APIs robust?

An honest and open relationship with the customer increases the chance of success. On the other hand, if you can’t get in touch with the customer to get the answers and decisions you need to move forward, it jeopardizes the whole project.

The productivity of team members depend on many things:

  • Experience
  • Stress level
  • Focus
  • Dedication
  • Priorities and commitments
  • Personal traits
  • Private situation

That brings us to another key role in a project: the project manager. While some things are out of the project manager’s control, the behavior of the project manager can still help mitigate negative circumstances.

Conclusion

To succeed, you need to carefully analyze the team. Not only the number of resources (actually I think that’s less important) but also their level of commitment, experience and capacity to deliver.

The team consists of everyone affecting the project, and for any project to succeed communication and good relationships are key. The best way to establish such an environment is to realize that everyone is on the same team: everyone wants the project to succeed.

Some points to consider:

  • The steering committee needs to be committed. They need to understand how their decisions affect the project. For example if they remove resources or change the project scope.
  • Communicate! Everyone involved should have the same view, and work towards the same goal.
  • As a project manager be
    • honest and transparent
    • enthusiastic and engaging
    • organized and disciplined
  • Invite the customer to participate as closely as possible in the project. This is one of the reasons agile methodologies work.
  • Add any team related risks to the risk analysis. For example:
    • Personnel turnover
    • Poor quality from sub-contractors
    • Lack of communication
    • Junior staff

Many times the project manager doesn’t have much say in how the project is staffed, and management often has a simplified view of how resources affect progress. In the worst case their understanding is reduced to work / people = time. In reality, the difference is huge between an experienced developer and someone that just graduated, the value of a resource that knows the project is far greater than bringing someone new aboard, and so on.

Brook’s Law
Brook’s law states that adding resources to a late project makes it later. Some good discussions about why can be found here and here.

No comments:

Post a Comment