While working recently with a client, they asked for some specific advice for managing small project teams when delivering software projects.
Previously their project teams were quite large, but the nature of their work now needs small project teams completing software modules in less time. This is to enable them to support ever-changing market needs.
Their teams were used to a culture of clear role definition and never stepping outside that role even if it meant that the project was delayed. They claim that they could remain focused on the task at hand and they could specialize in a field of expertise relating to the client business.
The client knew they needed to adapt but they were fearful of the impact of this change on their operation and if it could impact what they do in a negative way.
The “large team” mindset certainly has its merits. But it only has it merits in a certain context, i.e. where there is a large team of people available. Where there are large project teams there is generally the availability to pick up the slack and reassign tasks to the next available resource. Small project teams do not have this luxury and therefore need a different mindset.
Smaller project teams can drive a different behavior and therefore need to foster a different culture to survive. In smaller project teams flexibility is everything. Although team/members still have a primary role they also have an obligation to do what ever it takes to keep the project moving. For example there is no reason why a business analyst cannot support software acceptance testing or author and review key documents.
The project manager has a similar obligation when it comes to keeping things moving on a project. For example I have witnessed too often where a PM is waiting on a resource to perform a simple review task when the review task is well within the skill set of the PM.
All project team members need to keep focused on the end goal and it is one of the responsibilities of the project manager to ensure that this vision is clear and obvious to all concerned.
Project Team members (including the PM) have an individual primary responsibility but also have a common secondary obligation to keep the project moving if they have the capacity and ability to do so.
The situation is best managed by a daily touch point with the full team. At the meeting we must understand – What is the priority for today? Do we have the skill set within the team to achieve this goal? Do we have the capacity to achieve this goal? What is the impact of completing this task?
As with each person’s primary responsibility, should come secondary ownership and expectations. If anyone finishes a task ahead of schedule what should they do? Answer – they should review what else needs to be done and what they themselves can do to achieve the next milestone or goal. They should also see if any of their colleagues need any support to complete a task.
Project Team members (including the PM) have an individual primary responsibility but also have a common secondary obligation to keep the project moving if they have the capacity to do so.
The agile scrum approach is an effective means of managing such work. The work tasks are queued up in a priority and the work is reviewed daily. Therefore, a change in priority can be communicated easily. This approach encourages and facilitates regular feedback.
An underlying theme here is strong, effective, clear and frequent communication.
Small teams need to adopt a slightly different approach to large project teams and base their work on the following principles:
1. There can be no 100% demarcation of work
2. The priority can change daily
3. The task you are assigned and working on can change daily.
4. Be prepared to step outside your comfort zone from time to time
5. Project success or failure is the responsibility of all concerned
6. Encourage open honest feedback among the team
7. We all fail or we all succeed.
Set these ground rules with small project teams and review the effectiveness of your approach regularly. Deal with any issues or concerns swiftly and do not let any issues fester. The solution to most project team problems can often be found within the team itself. Encourage feedback from the team on how the project is performing. From these suggestions, don’t be afraid to experiment with tasks, you may be pleasantly surprised, but don’t take crazy risks.
Culture doesn’t change overnight, and some people are not suited to the small team set up. This is a hard reality.
Flexibility does not mean multi tasking. Multi tasking is a myth – see this previous blog here
One person can only focus on one task effectively at a time.
We’d love to hear from you on this topic. E-mail us here