Team Effectiveness

With much of the work in organizations accomplished through teams it is important to determine the factors that lead to effective as well as ineffective team processes and to better specify how, why, and when they contribute. It doesn’t matter if the team is brought together for a specific project and then disbands, or if it is a fairly permanent part of the organization, similar principles are at work.

Input-Process-Output model

The input-process-output model of teams is a great place to start. While simplistic, it can offer a good model of what makes teams works and is applicable to the different types of teams.

Input factors are the organizational context, team composition, task design that influence the team. Process factors are what mediates between the inputs and desired outputs.

  • Leadership:  The leadership style(s) (participative, facilitative, transformational, directive, etc) of the team leader influences the team toward the achievement of goals.
  • Management support refers to the help or effort provided by senior management to assist the project team, including managerial involvement and resource support.
  • Rewards are the recompense that the organization gives in return for good work.
  • Knowledge/skills are the knowledge, experience and capability of team members to process, interpret, manipulate and use information.
  • Team diversity includes functional diversity as well as overall diversity.
  • Goal clarity is the degree to which the goals of the project are well defined and the importance of the goals to the organization is clearly communicated to all team members.
  • Cooperation is the measure of how well team members work with each other and with other groups.
  • Communication is the exchange of knowledge and information related to tasks with the team (internal) or between team members and external stakeholders (external).
  • Learning activities are the process by which a team takes action, contains feedback and makes changes to improve. Under this fits the PDCA lifecycle, including Lean, SixSigma and similar problem solving methodologies..
  • Cohesion is the spirit of togetherness and support for other team members that helps team members quickly resolve conflicts without residual hard feelings, also referred to as team trust, team spirit, team member support or team member involvement.
  • Effort includes the amount of time that team members devote to the project.
  • Commitment refers to the condition where team members are bound emotionally or intellectually to the project and to each other during the team process.

Process Factors are usually the focus on team excellence frameworks, such as the ASQ or the PMI.

Outputs, or outcomes, are the consequences of the team’s actions or activities:

  • Effectiveness is the extent a project achieves the performance expectations of key project stakeholders. Expectations are usually different for different projects and across different stake-holders; thus, various measures have been used to evaluate effectiveness, usually quality, functionality, or reliability. Effectiveness can be meeting customer/user requirements, meeting project goals or some other related set of measures.
  • Efficiency is the ability of the project team to meet its budget and schedule goals and utilize resources within constraints Measures include: adherence to budget, adherence to schedule, resource utilization within constraints, etc.
  • Innovation is the creative accomplishment of teams in generating new ideas, methods, approaches, inventions, or applications and the degree to which the project outputs were novel.

Under this model we can find a various levers to improve out outcomes and enhance the culture of our teams.

Personal Audits as part of team building for Projects

The personal audit is a tool used in change and project management (and such) to help team members and sponsors judge their strengths and weaknesses with respect to change leadership. It illustrates some skills from the full range necessary to introduce change into an organization.

This exercise is great to do at the beginning of the project, where it can help team members begin to understand some of the human issues applicable to all projects. As one mentor once told me – If this exercise strikes team members as inapplicable, then they really need to do it.

Domain What I do Well What I Need to Work On
Manage Attention: To what extent do I manage my time, energy, passion, focus and agenda?    
Adopt change roles? How much attention do I pay to smatters like: Creating a need, Shaping a vision, Mobilizing commitment,  Monitoring progress, Finishing the job,  Anchoring the change)    
Technical competence: To what extent to I demonstrate competence in technical abilities?    
Interpersonal competence: how skilled am I at interacting with others?    
Vision: How well can I articulate the desired outcome of the project and the benefits to others?    
Teamwork: How often do I recognize good work done by teammates?    
Diplomacy: How closely am I working with all the groups affected by this project?    
Conflict management: Can I deal with disagreement without avoiding it or blowing up?    
Summary: Overall strengths and weaknesses    

Risk Management leads to Change Management, Change Management contains Risk Management

We did an FMEA for the design of the room. Why do we need a risk assessment for the change control to implement the design features?

We have an environmental risk management plan, including a HAACP. Why does this change control require a new risk assessment?

If I received a nickel……

I want to expand on my earlier thoughts on risk management enabling change.

Risk Management is a key enabler of any quality by design, whether of product, facility or equipment. We do living risk assessments to understand the scope of our ongoing risk. Inevitably we either want to implement that new or improved design or we want to mitigate the ongoing risks in our operation. So we turn to change management. And as part of that change management we do a risk assessment. Our change management then informs ongoing risk review.

Risk Management Leads to Change Management

Design Implementation

Through your iterative design lifecycle there is a final design ready for introduction. Perhaps this is a totally new thing, perhaps it is a new set of equipment or processes, or just a modification.

All along through the iterative design lifecycle risk management has been applied to establish measurable, testable, unambiguous and traceable performance requirements. Now your process engages with change management to introduce the change.

And a new risk assessment is conducted.

This risk assessment is asking a different question. During the interative design lifecycle the risk question is some form of “What are the risks from this design on the patient/process.” As part of risk management, the question is “What are the risks to SISPQ/GMP from introducing the change.”

This risk assessment is narrower, in that it looks at the process of implementing. Broader that it looks at the entirety of your operations: facility, supply chain, quality system, etc.

The design risk assessment and risk management activities informs the change management risk assessment, but it cannot replace them. They also can serve to lower the rigor of the change management risk assessment, allowing the use of a less formal tool.

Living Risk Reviews

risk leads to change

In the third phase of risk management – risk review – we confirm that the risks identified and mitigated as planned and are functioning as intended. We also evaluate to see if any additional, previously unpredicted risks have appeared. Risk review is the living part of the lifecycle as we return to it on a periodic basis.

From this will come new mitigations, targeted to address the identified risks. These mitigations inevitably lead to change management.

We again do a new risk assessment focusing on the risk of implementing the change. Informed by the living risk assessment, we can often utilize a less formal tool to look at the full ramifications of introducing the mitigation (a change).

Change Controls contains Risk Management

risk and change management connections

Effective change management is enabled by risk management.

Each and every change requires a risk assessment to capture the risks of the change. This ICHQ10 requirement is the best way to determine if the change is acceptable.

This risk assessment evaluates the impact on the change on the facility, equipment, materials, supply chain, processes. testing, quality systems and everything else. It is one of the critical reasons it is crucial to involve the right experts.

From this risk assessment comes the appropriate actions before implementing the change, as well as appropriate follow-up activities and it can help define the effectiveness review.

What about grouped change controls?

Depends. Sometimes the risk management looks at the individual implementations. Othertimes you need to do separate ones. Many times the risk assessment lead you to breaking up one change control into many. Evaluate as follows:

  • Are the risks from the separate implementations appropriately captured
  • Are the risks from pauses between implementations appropriately captured
  • As the ripples appropriately understood

Change Management Leads back to Risk Management

Sometimes a change control requires a specific risk assessment to be updated, or requires specific risk management to happen.

What about HAACP?

Hazard Analysis Critical Control Point (HACCP) are great tools for risk assessments. They are often the catalyst for doing a change, they are often the artifact of a change. They should never be utilized for determining the impact of a change.

A hazard is any biological, chemical, or physical property that impacts human safety. The HAACP identifies and establishes critical limits. But a HAACP is not the tool to use to determine if a change should move forward and what actions to do. It is to static.

In Closing

Risk Management is an enabler for change, a tenet enshrined in the ICH guidances. We are engaging in risk management activities throughout our organizations. It is critical to understand how the various risk management activities fit together and how they should be separated.

Don’t Just Tell Employees Organizational Changes Are Coming — Explain Why

To be successful, your story needs to start with the company’s core mission and then offer a compelling and inspiring future vision. You want to answer: How are the changes you make today helping you achieve your vision for tomorrow?
Don’t Just Tell Employees Organizational Changes Are Coming — Explain Why by Morgan Galbraith

I can’t stress enough the importance of proper communication around all changes, from the large transformations on down. Effective communication is effective change management.

I’ve discussed the need to be able to identify changes to strategic plans and use that to inspire, inform, empower, and engage.

changing business environment

Always spend the time on a good communication plan:

Information to Communicate
(What)
Objective
(Why)
Target Audience
(Who to)
Frequency
(When)
Start Date
(When)
End Date
(When)
Media
(How)
Responsible
(Who from)
Deliverable Comments
What to people need to know o Determine site readiness to start the project

o Define resource needs and availability

Tailor the communication to specific audiences. The same information is sometimes presented different ways How often? Start date End Date From face-to-face to all the other communication tools available in the modern workplace. Be creative Who is responsible for completing the communication What will execution look like  

 

Change Management of multi-site implementations

A colleague asks in response to my post Group change controls:

… deploying a Learning + documentation system … all around the word [as a global deployment]  … do we I initiate a GLOBAL CC or does each site created a local CC.

The answer is usually, in my experience, both.

Change management is about process, organization, technology and people. Any change control needs to capture the actions necessary to successful implement the change.

so at implementation I would do two sets of changes. A global to capture all the global level changes and to implement the new (hopefully) harmonized system And then a local change control at each site to capture all the site impact.

System Element Global Local
Process Introduce the new global process

Update all global standards, procedures, etc

How will local procedures change? How will local system interactions change – clean up all the local procedures to ensure the point to the new global procedures and are harmonized as necessary.
Technology Computer system validation

Global interfaces

Global migration strategy

Local interfaces (if any) and configurations

Are local technologies being replaced? Plan for decommissioning.

Local migration (tactical)

People What do people do on the global level?

How will people interact within the system in the future?

Global training

What will be different for people at each individual site?

Localized training

Organization Will there be new organizational structures in place? Is this system being run out of a global group? How will communication be run.

System governance and change management

Site organization changes

How will different organizations and sub organizations adopt, adapt and work with the system

If you just have a global change control you are at real risk of missing a ton of local uniqueness and leaving in place a bunch of old ways of thinking and doing things.

If you just do local change controls you will be at risk of not seeing the big picture and getting the full benefits of harmonization. You also will probably have way too many change controls that regurgitate the same content, and then are at risk of divergence – a compliance nightmare.

This structure allows you better capture the diversity of perspectives at the sites. A global change control tends to be dominated by the folks at each site who own the system (all your documents and training folks in this example), while a site change will hopefully include other functions, such as engineering and operations. Trust me, they will have all sorts of impact.

This structure also allows you to have rolling implementations. The global implements when the technology is validated and the core processes are effective. each site then can implement based on their site deliverables. useful when deploying a document management system and you have a lot of migration.

Multisite changes

As part of the deployment make sure to think through matters of governance, especially change management. Once deployed it is easy to imagine many changes just needing a central change control. But be sure to have thought through the criteria that will require site change controls – such as impact other interrelated systems, site validation or different implementation dates.

I’ve done a lot of changes and a lot of deployment of systems. This structure has always worked well. I’ve never done just a global and been happy with the final results, they always leave too much unchanged elements behind that come back to haunt you. In the last year I’ve done 2 major changes to great success with this model, and seen one where the decision not to use this model has left us with lots of little messes to clean up.

As a final comment, keep the questions coming and I would love to hear other folks perspectives on these matters. I’m perpetually learning and I know there are lots of permutations to explore.