already two decades ago, and many others after them as well. Successful projects consistently give significant weight to the human factor.An important part of the project reviews I do is the project delivery team review. The project delivery team consists of the project team (developers, testers, solution architect, business analysts, and so on), the project manager, project management office and line managers. Stakeholders, sponsor, and Steering Committee are not part of this project delivery team review. These are covered in a separate review because the focus there is a completely different one. From here on I will refer to the project delivery team just as the team.
When reviewing a team I usually look at three levels:
1) Team performance
2) Project management
3) Team members
These are not three separate reviews, but rather three overlapping perspectives of the team, which are part of a single review. While a substantial part of the interviewing can be performed concurrently, information from the review of team performance will provide input to the project management review, which will then provide input for the team member reviews. This will be discussed in detail in the following sections.
Team Performance
I start with a review of the project delivery team and focus on the performance of the team as a unit. Interview the initiating manager to get a general perspective of the team, and then meet with the project manager and other parties who interface regularly with the team (interviews can be conducted with multiple participants). The following list covers ten key issues that should be considered during your review and resulting interviews:
1) General team performance: Look at the team as a single unit. How well does the team perform? Are team activities well coordinated, and do team members cooperate well with each other? Look at the team’s accomplishments. Were they due to teamwork, or would individual team members working on their own have achieved them in any case? Look at the team’s setbacks: Could better teamwork have prevented them? How has the team performed over time? Has performance improved or declined?
2) Skill set: Look at the skill set necessary to deliver the project: Does the team have these skills? Does the team have the necessary experience? Are the team member’s skills up to date? Does the development organization have a training program for software developers, and if so, is the team taking advantage of the program? See my article "14 Essential software engineering practices for your agile project" for more background and ideas.
3) Unstaffed positions: At this point, we are not yet looking at understaffing (budgeting for a team that is too small to deliver the project); rather, we are looking at budgeted team positions that have not been filled. Are all approved team positions staffed? If not, for how long have unstaffed positions been empty? Is the project manager constantly looking for new people to fill empty positions? Are the right people in the right roles? Are positions part-time staffed that should be fulltime staffed?
4) Size of team: Look at the size of the team that has been budgeted in relation to the amount of work to be done. Is the team understaffed (too small)? Is the team overstaffed (too big)? Note that in some cases, overstaffing can be a problem (redundancy, overlapping responsibilities, greater management overhead, budget used for the wrong things). How bad is the understaffing or overstaffing?
5) Development facilities: Look at the facilities and tools available to the team. Does the team have the necessary development tools to deliver the project? Do team members have an appropriate workspace, desks, chairs, powerful laptop/pc, 2 screens, and meeting rooms? Does the team have the necessary communications facilities (chat, Kanban board, whiteboards, flipcharts)? Does the team have enough support (administrative support, technical support, PMO)?
6) Organization of team(s): Is the software being developed at a single location, or is it a distributed team? How is the team distributed (different offices, different companies, different countries, offshore, nearshore)? How is the team mixed (internal vs external, location vs location, junior vs senior)? Does the mix and/or split make sense? Would it not be better to have one team at one location? Is the team a feature team or a component team? See my articles "Agile Team Organization" and "Outsourcing technical competence" for more background and ideas.
7) Team atmosphere: Clearly, the failure of a project will affect the morale and spirit of the team. But is there anything else that is causing low morale (if so, what is it)? Is there a lack of commitment to the project. Do team members seem to like each other, goof off together, and celebrate each other's success? Do team members hold each other accountable to high standards, and challenge each other to grow?
8) Relationships with other groups and teams: Look at the project team’s relationships with other external groups and teams. How well do they work with the infrastructure team, the independent test team, the field support team, the architecture team, stakeholders and other projects?
9) Conflicts: Are there any internal or external team conflicts or tensions that could disrupt the project? How long have they existed? How severe are they? Have there been attempts to resolve them? How did this go? Are there issues/opportunities the team isn't discussing because they're too uncomfortable?
10) Management: How good is the relationship between the team and management (the project manager and line management)? Is line management aware of the team problems? Have there been any attempts to resolve the problems? Have the managers responsible for the project been changed recently or frequently? Does line management still support the project and the team?
7) Team atmosphere: Clearly, the failure of a project will affect the morale and spirit of the team. But is there anything else that is causing low morale (if so, what is it)? Is there a lack of commitment to the project. Do team members seem to like each other, goof off together, and celebrate each other's success? Do team members hold each other accountable to high standards, and challenge each other to grow?
8) Relationships with other groups and teams: Look at the project team’s relationships with other external groups and teams. How well do they work with the infrastructure team, the independent test team, the field support team, the architecture team, stakeholders and other projects?
9) Conflicts: Are there any internal or external team conflicts or tensions that could disrupt the project? How long have they existed? How severe are they? Have there been attempts to resolve them? How did this go? Are there issues/opportunities the team isn't discussing because they're too uncomfortable?
10) Management: How good is the relationship between the team and management (the project manager and line management)? Is line management aware of the team problems? Have there been any attempts to resolve the problems? Have the managers responsible for the project been changed recently or frequently? Does line management still support the project and the team?
These ten points are not distinct, meaning that they do not need to be covered separately (they are not a checklist in the sense that you finish one and move on to the next). The review, interviews, and meetings can cover a broad range of topics at a single session, and some of the topics can be discussed concurrently. Use the input from the team performance review to prioritize the later interviews with the individual team members and the other project stakeholders. This way you will be able to put the main pieces of the picture in place more quickly. Reevaluate the priorities after each interview or meeting, and be prepared to repeat interviews when new questions and information comes on your path.
Project Management
The project management review focuses mainly on the leadership (not the administrative / PMO) aspects of the project and considers the main problems confronting the project manager and the way they are handled.
Very often, project managers are the first to be blamed for a failed project. It is important, however, to remember that projects fail for many reasons, several of which are unrelated to the qualities of the project manager. You should approach the review with no preconceptions. Although senior management may sometimes instinctively blame project management, it is your responsibility, after examining the facts, to independently determine if there are any major incompatibilities between the qualities of the project manager and the needs of the project. This is especially important because of the personal impact of your evaluation results.
1) Skills: Look at the main skills required for the project (avoid a comprehensive wish list for an ideal project manager). Concentrate on core skills without which it is clear that the project manager will not be able to successfully lead the project. Does the project manager have these skills? In my opinion for a software development project these skills consist of:
- a good understanding of the software development process
- a good understanding of the business and the business problem that will be addressed
- leadership skills
- project management skills
- a good understanding of the software development process
- a good understanding of the business and the business problem that will be addressed
- leadership skills
- project management skills
2) Relationships: How do others perceive the project manager’s ability to successfully lead the project? Look at the quality of the project manager’s relationships with the following groups:
- Team: Look at individual relationships, respect as a leader, and loyalty. Have there been any severe conflicts?
- Senior management: Look at individual relationships with key managers, issues of respect, and confidence in the project manager’s required capabilities. Have there been any severe conflicts?
- Other groups: Look at the working relationship with project support groups, such as the test group, quality assurance, field support, marketing, other projects, and so on.
- Other project stakeholders: In addition to senior management, look at the relationship with customers, users, investors, sub-contractors, partners, and so on.
Have any of these relationships contributed to problems? If other project problems are solved, does the disturbed relationship(s) still endanger project success? See my article "10 Principles of Stakeholder Engagement" for more background and ideas.
- Team: Look at individual relationships, respect as a leader, and loyalty. Have there been any severe conflicts?
- Senior management: Look at individual relationships with key managers, issues of respect, and confidence in the project manager’s required capabilities. Have there been any severe conflicts?
- Other groups: Look at the working relationship with project support groups, such as the test group, quality assurance, field support, marketing, other projects, and so on.
- Other project stakeholders: In addition to senior management, look at the relationship with customers, users, investors, sub-contractors, partners, and so on.
Have any of these relationships contributed to problems? If other project problems are solved, does the disturbed relationship(s) still endanger project success? See my article "10 Principles of Stakeholder Engagement" for more background and ideas.
3) Confidence in the project: Is the project manager confident that the project can be realized? Is doing the project worth the effort? In the project manager’s opinion, what are the top three well-defined things that need to be done to get the project done?
4) Spirit, motivation, commitment: How committed is the project manager to the success of the project? Look at the project manager’s personal identification with the project, the amount of time invested in the project (full time, part-time, and so on), loyalty to the project team, and more generally the level of enthusiasm in making the project a success. Clearly, much of this is related to the previous point.
5) Other problems: What other problems related to the project manager may have contributed to a negative impact on the project? Consider, for example, personal problems or sickness.
6) General capabilities: Based on points 1 to 5 look at the project manager’s overall ability to successfully manage the project (leadership, personality, competence, and so on). Concentrate only on major points (remember that this is not a performance review). Ask the following question: If other project problems (that are unrelated to the project manager’s work) are solved can the project manager lead the project to success?
Team Members
This review will identify team member problems that can prevent the project from being successfully completed. This is achieved through individual interviews that focus on the team problems identified during the team unit review. It is important to remember that this is not a performance review for the team members, and it is not concerned with problems that will not affect the overall success of the project.
If the team is large, there may not be sufficient time to meet with all team members individually—in such cases, select the ones relevant to the main team problems that have already been uncovered.
The following list includes seven key points to be considered during the individual team member interviews:
1) Role: Determine the team member’s official job function, his/her description of their role in the project, and compare it with the role as described by the project manager. Are there significant discrepancies? When the person's role is ScrumMaster have a look at the ScrumMaster Checklist.
2) Skills: Does the team member have the skills necessary to perform the project team role (avoid a comprehensive wish list and concentrate only on the main skills)?
3) Achievements and contributions: Look at the results (not effort) of the team member’s work on the project so far. What have been the main contributions to the project? Have the team member’s activities been a factor in the success/failure of the project? If so, how big is this factor?
4) Relationships: Look at the team member’s relationship with other persons involved in the project, including:
- Other team members
- The project manager
- Members of other groups/teams
- The project stakeholders
Are any of these relationships problematic? If so, how serious are the problems and how do they affect the project?
- Other team members
- The project manager
- Members of other groups/teams
- The project stakeholders
Are any of these relationships problematic? If so, how serious are the problems and how do they affect the project?
5) Morale and commitment issues: Does the team member have any motivation issues that go beyond the situation of the project? How committed is the team member to the project and especially to the attempt to bring it to success? Can the team member be expected to stay with the project if a recovery plan is implemented?
6) Other problems: What other problems have affected the team member’s work on the project? Look at issues such as work environment, tools and facilities, training, and personal problems.
7) Capabilities: Based on the points (1 to 6) look at the team member’s overall ability to successfully perform the role. Concentrate only on major points. Ask the following question: If a new project plan is implemented, will the team member be capable of successfully fulfilling the requirements of the, potentially new, role?
Results
As described in the previous sections there are several sources of information, and three different levels, for the evaluation of the project delivery team. The goal of the project delivery team review is to combine the information to form a single coherent view of the team. I usually do the following:
1) Complete and write down my view of things, identify information/evidence gaps and identify contradicting information.
2) Archive all interview minutes/recordings, received documents, written documents, and all related emails. This will save substantial time if the findings ever need to be re-examined.
3) Prepare a short team overview document. The document should be no more than 3–6 pages (depending on the size and complexity of the team) and should take between two and four hours to prepare. Include the main sources of information, the list of interviews, the reasoning that led to any significant findings, and any problems or incompatibles that arose during the evaluation.
4) Review the overview with the initiating manager. Review a draft of the document with the initiating manager. Expand any key points that are unclear and correct any factual errors.
5) Adjust the evaluation. Additional information about the team may well continue to emerge throughout the disentanglement process. If any of the new information affects your main findings, be prepared to adjust your conclusions. However, avoid frequent changes to your findings, especially when the new data does not significantly affect your key conclusions.
Due to the information on individual team members, the team overview document cannot be considered a public document. However, a summary of the findings should be available to the team and to the project stakeholders (consult with the initiating manager regarding any business reasons to limit distribution).