Aligning the team in practice

Photo credit:Manojk (via Commons)

For the success of a project/program team alignment is critical.  If the team is newly created, there is a pressing need to make it effective soon. For complex projects,  the team dynamics are even more challenging, as the team is never stable. New team members get added as the workload reaches peak and team members leave as per  change in workload or due to other effects like attrition. Bigger teams require  better processes for communication/ coordination for effectiveness.  In this blog post, I share few theories and  practices that benefit the project/program.

According to B.W. Tuchman's theory   teams evolve through forming, storming,norming, performing and adjourning stages.  This has implication for Project Mangers to apply appropriate  leadership styles as per the team evolution stage. According to Connie Gersick's punctuated equilibrium model the initial behaviors and norms have a lasting impact, till they are shaken by a critical event which moves the team  to  reach another level of performance by modifying their behavior and norms. In this model,  Project Manager has to play a critical role, as he or she has a critical role in  shaping initial interactions.

For an effective team, the team needs to be clear about the objectives, roles, processes and relationships.   Project artifacts/events   help a lot, if the team members take active part in their preparation/review.  Let's review couple of key documents below.


Project Kickoff: Usually projects are kicked off by convening the initial  meting with the project stakeholders.  The scope of the project is discussed and clarified. The expectations from different teams  are discussed with respect to a rough timeline.

Project Plan: This  has several sections related to  various aspects which help team alignment. The project purpose, scope and deliverables are described. The various roles and responsibilities are identified. CTQs, Project Schedule, process for review, metrics, shared expectations  are  documented.The document is base lined after review by all team members.

What can't be usually captured in  project artifacts  is how well the project team understands all of the above and acts in accordance with them. The team's  interpersonal relationships play a key role in actual practice.

I realized this when the team that I led  went for an off-site team building session. We reached the venue by evening  and the activities were planned for the next day morning. The agenda was  communicated to all in advance.   When it was  time to start the activities for the day, the facilitator and I were surprised when only part of the team was present at the scheduled start time and others were joining in for close to ten minutes. The facilitator, being from a military background,  became angry at us and threatened  to cancel the sessions as he felt that the workshop will never be productive with this kind of behavior.  We felt sad.  After a bit of self reflection, the activity was  rescheduled after the facilitator impressed upon everybody about the need for meeting discipline.  The meeting discipline was improved as the team developed the meeting norms during the initial team building session and put them to practice.

The office atmosphere does not give much scope to build interpersonal relationships. It is important to assess the team alignment several times during the course of the  project.  This is usually done  by administering a team alignment survey with the help of HR member of the project. In this the team is asked to reflect and rate their agreement level on few statements about the project and team characteristics on a scale of  Strongly agree, Agree, Disagree and Strongly Disagree. As an example,  a survey statement may check the response on the team's understanding of and agreement  with project purpose and the desired results(vision).  Project manager's view  is compared  with the views of the team members. The findings in general as well as where the team's opinion differs from the PM are shared.  This can serve as a trigger to initiate specific actions to address the gaps.

In one instance the assessment revealed that there is a good understanding on project purpose, scope, goals but poor understanding of strategic road map and review mechanism.  The project manager  took an action to present the road map and review process in the next team meeting and the subsequent discussion helped improve clarity. 

The outbound helped everyone to know more about other team members, their  strengths, perspectives at a personal level through team building  games, which typically try to bring the elements of the project into focus in a short time. These  helped a lot in improving  interpersonal relationships which improved the team performance subsequently.

What has been your experience with team alignment? Are outbound sessions helpful for team building? Please discuss/share your views.

Automated metrics from repositories for better project insight

Metrics are important to understand project health.  Every project manager has to present them for  review meetings. Traditionally spreadsheet software was used extensively for  metrics preparation. Project Manager has to do a lot of work to contact team members for status information and then update the  spreadsheets. The metrics are subjective and are delayed.  Most of these spreadsheets also will not be ideal for knowledge management in organization, as these are not archived and available for future reference.This situation has improved with  increased use of   non spreadsheet  tools in the recent times.

Usually tools used for requirements, coding, code review, testing  and change  management and project management,  have  built-in reports. These are useful for understanding the status and issues in a project in a timely manner. These may require customization to conform to the specifics of process followed by the organization.  If the tools are not integrated,  consolidation of metrics requires additional effort and possibly use of spreadsheets again with their inherent advantages and disadvantages. Software analytics is a good alternative when the tools are not integrated.

Open source communities are leveraging tools like MetricsGrimoire  (See sample figure above from Dashboard of Wikimedia Development Community) to mine repositories associated with  configuration management, bug tracking and mailing list for projects and extract useful metrics and present them visually for analysis and action. These metrics are useful  to identify  top contributors, aging of artifacts, velocity of development as well as provide insight into issues.

What is the level of  non spreadsheet tools usage in your organization? How much time is spent in generating the metrics? Is there an opportunity to deploy additional tools, deploy software analytics tools  and develop automation scripts to extract metrics? These are all valid questions which can lead to improved productivity and project success.

Oppportunity Management

During my recent talk on Risk Management Best practices, I focused on applying standard risk model, which requires identifying the event  and its impact explicitly along  with their respective drivers(causes). Separate identification of drivers enables  preparation of prevention   and contingency plans. A participant asked me a question of how to manage opportunities,  events which  reduce the time, budget for a baselined project. As per PMBOK,  opportunities are managed the same way as risks. A detailed risk and opportunity management process applicable for a city council is a good read to understand the application of this concept. In IT/engineering projects, Opportunity Management  is not so common. In this blog post, I explore the Opportunity Management and share few thoughts that I hope are practical and useful in practice.

Usually projects are taken up to address an opportunity such as addressing a underserved customer need, acquiring new skills, establishing a platform/IP that can be leveraged for a long time. This means that entire project is actually an opportunity management at the level of organization's portfolio.

Estimates for complex projects involve great deal of uncertainty. These are generally optimistic given the excitement around new project and general human optimism, despite the use of robust processes. Once the project is approved, the focus is on delivering  the project as per expectations while managing  threats.  Given a good system engineering approach, work is planned and executed to deliver as per expectations. Multiple options with respect to schedule/cost are explored as part of Project Management before baselining. This process  implicitly manages the opportunities to reduce the schedule/budget.

Due to change in customer scope or technology advances,  it is possible that certain options which were not explored during the project proposal/planning phase may become desirable for long duration projects.  At the same time, such options will not be without their share of risks. As an example consider that an enterprise mobile  application was planned initially for  one category of mobile Operating system, During the course of development,  the push for Bring Your Own Device (BYOD) made the need for supporting multiple mobiles became a pressing need. Then the opportunity of utilizing  a mobile OS neutral platform, which allows seamless targeting of mobile app to  other mobile operating systems become attractive.  In such a  case, it is advisable to pursue such  opportunities if the cost/time benefit after considering the risks associated with it  is beneficial.  If not, then it  would be more useful is to route such ideas behind opportunities through innovation pipeline of the organisation/group.    Once the idea passes through the innovation pipeline, the technology developed could be utilised in  future projects.

So in summary, my view is that opportunity management is implicitly practiced at the project level. It is more practical do it explicitly at the portfolio/organisation level. Share your perspective?