I often find myself teaching various classes on agile methods. One of my more popular sessions surrounds the mapping of traditional project management techniques towards the agile methods. I do this quite often in a wide variety of venues. One metric I’ve noticed is that the more PMPs in the audience the more spirited the discussions become.

One of the core translation areas between traditional and agile project management relates to risk management. I often get a lot of pushback from the PMs telling me that the agile approaches to risk management simply won’t work. Their arguments are more based on traditional thinking, PMBOK guidance, and “we’ve always done it this way” pattern; rather than a situational response to individual project needs. I usually just leave it that agile risk management is “different” and move onto safer topic areas. But I usually want to add more flavor and this post seemed like a good opportunity to do so.

Traditional Risk Management

In this view, the project manager is managing the risk. The premise is that you need a highly skilled and experienced PM to adequately control and manage project risks. That risk can be anticipated, planning, triggered, and mitigated.

One of the first activities with any project is to begin the compilation of a risk list so one can manage the project risks. These risks can be gleaned in a wide variety of methods—team brainstorming, speaking directly to key stakeholders, analyzing previous projects, and from the technology and business climate.

Once identified, a common method is to evaluate the size of each risk. A common mechanism is to gather likelihood and impact from the project team, then multiply the likelihood of the risk occurring against the impact the risk would have.

Potential Risk	Likelihood of Occurrence: 0 – minimal / none, 1, 2, 3 – Certain!	Impact of Risk: 0 – minimal / none, 1, 2, 3 – Project Failure!	Risk Priority
50% of technical team will leave for a competitive position	0	3	0
The open source LAMP stack will be acquired by Oracle	1	2	2
Chance we will deliver 100% of the agreed functionality?	3	1	3
System Performance will not meet requirement levels; only 50%	2	2	4
Business stakeholders will be confused on required features	3	2	6

Once you’ve accumulated a “complete” list of risks and analyzed their “priority”, then a plan is put in place to detect and mitigate the risks that are most likely to occur. Quite often, this is a very detailed plan that is formulated with all of the project’s functional teams—expending quite a bit of time and effort towards these hypothetical risks both in upfront planning and in ongoing monitoring and discussion.

A Quick Point of Context

Oh, and I need to get this point out of the way. My primary context for this post is technology projects. If you’ve managed a technology-driven project, IT project, development effort, integration project, etc., you will certainly agree that these beasties are “different” than other types of projects. And yes, their risks are different too. Rarely can you predict risks early on in these projects. Why? Because you simply haven’t done it before—so you have little to no experience with this specific type of project or technology within the team chartered with implementing it.

The variability in complex software projects is what undermines traditional risk management in my view. We try to expend all of our effort in up-front risk management. Rather, we should expend most of our efforts towards figuring out what we do and do not know. We should decide how to design and code this particular widget I.e. do some of the project work before trying to predict risk.  Let the risks emerge from our efforts rather than trying to predict them.

Agile Risk Management

This nicely leads into the essence of agile risk management being an emergent approach. First of all, you rarely hear the agile methods focus on risk at all. Why? Because we flip the notion of planning risk on its ear a bit. How is that? Well, instead of guessing or planning for risk, one of the central themes of the agile methodologies is to deliver real working software in very thin slices of functionality in time-boxed iterations. Realization of risk occurs quickly and abruptly. It hits you in the face as a team at the earliest possible moment. Quite often it surfaces in a daily stand-up meeting.

Is it solely the responsibility of the project manager? No, in the agile case the self-directed team is primarily responsible for detecting, acting on, and mitigating risk…and here’s the important part, in real-time, as each risk occurs. It’s a whole-team and reactive view towards risk.

The team often engages in strategies surrounding risk by how they approach iteration planning. They have the choice of what to build first, so very often the development strategy is to load risky items first—

• To do early experimentation to see how the team will respond to technical challenges and the unknown.
• To measure the velocity of the team to understand their capacity to meet business milestones.
• To engage stakeholders in assessing requirements as they evolve…in real-time and on working software.

Conclusions

Now all of that being said, I don’t think we throw out all of the traditional approaches in agile contexts. For example, I think it a very healthy exercise for larger-scale agile projects to assess and understand the Top 10 risks they might be facing. In addition, to also look for more systemic or organizational risks and do a bit of up-front planning.

But don’t spend too much time there. Nor in exhaustive detection strategies or mitigation plans. Setup a straw man risk structure and then start leveraging the emergent nature of agile iterations to surface risks quickly.

Now for you traditional project managers listening in, I wonder if some of these agile approaches might be applicable in your current contexts! 

Don’t forget to leave your comments below

So much of an organization’s success is tied to project success!  Can you think of any significant organization initiative or improvement that didn’t tie to at least one project?  I’ve worked with many organizations, across diverse industries and globally, and I cannot think of a single example.  Therefore, what could be more important than figuring out how to ensure project success?

I did a quick survey of clients and business contacts to find the top three causes of project failure. If we address these, we’ll greatly increase our chances of success. The survey identified the following as the three most common stumbling blocks on the path to project success: 

1. Lack of a Clearly Designated Project Leader:  It’s amazing how many times this seemingly simple issue arises.  There are many reasons –  the project team is a group of peers and no one is assigned or assumes leadership. No one wants to assign a project leader because everyone already has a full-time job and is swamped (especially in today’s business environment!). Each department assumes the other department will lead the project.    

   However, there is nothing more important to project success than the project leader.  There are countless reasons. A few of the most vital include: the project leader must clearly articulate the project’s goals  The project leader must facilitate the development of the project plan with clearly designated tasks, milestones and accountabilities. The project leader must proactively address roadblocks and ensure the team completes the tasks on time and within budget.  Finally, the project leader must communicate progress to the appropriate parties. 

   Undoubtedly, your project will derail without a clear project leader!

2. Lack of Clear Expectations and Goals:  Following on the heels of no clearly designated project leader is no clear expectations and goals.  Even the best project leader cannot succeed without clear expectations and goals.  What is the objective of the project?  Why is the objective important to the organization?  How does each project team member add value to achieving the goal?  Is the goal clear?  Is the timing understood?  

   For example, for one client, the end goal was clear (inventory reduction); however, the project team didn’t have clear expectations and goals at first.  Thus, the branches had no incentive to share inventory figures, which was a main component in reducing inventory. As a result, progress was largely at a standstill until the project objectives and metrics were clarified.

3. Communication Challenges:  Communication challenges are common yet can deter even the best projects.  Even in the best of circumstances, it is easy to suffer from miscommunication and confusion.  Did you play the game of telephone as a young child?  Just in case you haven’t, I’ll explain – the game starts with a person who communicates a message to the next person.  And it continues until the message has gone around to the last person in the circle.  By the time it gets to the last person, it never resembles the original message!  Thus, it can be a lot of fun to hear the mixed up messages your friends come up with after 10 to 20 interchanges.  And this is when each person is trying to convey the correct message.  So, imagine what occurs when organizational confusion and politics get involved.

   Aside from typical communication issues, there is also a plethora of other communication challenges, ranging from cultural and language communication barriers to functional communication barriers (such as sales people communicating with technicians and finance folks talking with R&D).  These can pose a serious roadblock.  For example, I’ve worked with many project teams containing numerous team members where English was a second language.  Typically there have been two or three different primary languages.  Even with an excellent project leader it can be complex to ensure that communication is clear and that everyone on the team is aligned with the path forward.  Otherwise, it can be easy to run around in circles – even well-intentioned ones.

   It is vital to communicate, communicate, and communicate.  I’ve found that you have to repeat important project communications multiple times.  Try saying it in different ways.  Try different communication vehicles.  Ask team members for their understanding.  Send reminders.  Follow-up.  Never stop communicating.

According to my clients, if you can mitigate these three most significant causes of project failure, you’ll be one of the few to succeed – on-time, on-budget, and on-expectation.  Why not become the organization to “get it right” – and pass your competition by accelerating project results? 

The Good, the Bad and the Complex

In earlier articles in the Complex Project Management, series, we introduced the topic and discussed Complex Project Management (CPM) evolution and trends, and we presented the new, validated project complexity model.  The model consists of nine complexity dimensions that may (and often do) exist on highly complex projects and programs.  In this and subsequent articles we will discuss each complexity dimension in detail. 

This article considers the unique complexities of projects with large, diverse and often virtual teams that pose challenges to project success, and offers both old and new management strategies to handle the complexities.  Refer to Table 1: Team Composition Complexity Profile to examine the nature of these project characteristics as team complexity dimensions increase. 

Complexity Dimension: Team Composition
Independent Project	PM: competent, experienced Team: internal; worked together in past Methodology: defined, proven
Moderately Complex Project	PM: competent, inexperienced Team: internal and external, worked together in past Methodology: defined, unproven Contracts: straightforward Contractor Past Performance: good
Highly Complex Projects	PM: competent; poor/no experience with complex projects Team: internal and external, have not worked together in past Methodology: somewhat defined, diverse Contracts: complex Contractor Past Performance: unknown
Highly Complex Program “Mega Project”	PM: competent, poor/no experience with megaprojects Team: complex structure of varying competencies and performance records (e.g., contractor, virtual, culturally diverse, outsourced teams) Methodology: undefined, diverse Contracts: highly complex Contractor Past Performance: poor

Table 1: Team Composition and Past Performance Complexity Profile 

Great teams, like all great organizations, are those that make a distinctive impact and deliver superior performance over a long period of time.[i]  For a project, performance is typically measured in terms of on time, under budget, with full scope of features, meeting quality specifications, and delivering the business benefit that was expected.  Project teams do not need to be big to be great…big does not equal great.  But all too often contemporary project teams are too large, too dispersed, too diverse, and just plain too complex to manage using typical project management techniques alone.  So how can we be successful when a project demands complex teams?  Success in the 21^st century demands that we acquire new competencies to form, manage, and use large, diverse teams as a competitive advantage.

The Good:  Great Teams are Powerful – Very Powerful

Transformational projects in the 21^st century almost always involve multiple forms and types of teams. Applying the effective team management practices to diverse groups at the right time is in itself a complex endeavor. Successful teams are the result of many elements coming together, including adaptive team leadership, optimal team structure, just the right team composition, a disciplined culture, co-location of core team leaders, effective collaboration, communication, and coordination, and patience to steer the groups as each evolves from a collection of people, into a good team, and finally into a great team.

Since projects involving significant change in the way business is conducted are almost certain to involve complex team structures, it is not unusual for project teams to have sponsors, customers, architects, and developers sprinkled around the globe.  It is too expensive, and simply too exhausting, to continually travel around the world to meet with team members in person.  To reap the rewards of significant changes to optimize business and technology, we must find new ways to manage complex teams, complementing face-to-face sessions with robust virtual exchanges[ii].

The demands of the twenty-first century are requiring businesses to reject traditional “command and control” management structures and reach out into the virtual and physical world to create innovative approaches to team composition.  To remain competitive, companies are establishing inventive, but also complex, organizational communities.  These alliances may be with strategic suppliers, networks of customers, and win-win partnerships with key political groups, regulatory entities, and yes, even with competitors.  Through these inventive alliances, which manifest themselves in both physical and virtual models, organizations are addressing the pressures of unprecedented change, global competition, time-to-market compression, rapidly changing technologies, and increasing business and technological complexity.   

Geographical diver­sity and dependency on technology for communication and collaboration dramatically magnify the challenges of leading teams.  Applying the appro­priate team management techniques to multiple parties at the right time is a complex endeavor.  The project leadership role becomes as much about team leadership and group development, as about project and requirements management.

We will first explore the nature of the complexities that come into play when managing complex teams with dissimilar cultural norms, complicated contractual agreements, and multiple methodologies, including:

• Teams as complex adaptive systems
• Interactional uncertainty
• Integration challenges

We then examine the use of sophisticated team management techniques, while at the same time establishing an environment of adaptability, innovation, and creativity.  Areas that will be examined include:

• Leveraging team potential
• Becoming a team leader
• Using team collaboration, communication and coordination tools and techniques.

The Bad: Teams are Difficult to Manage – Very Difficult

There are many complexities that come into play when managing complex teams with dissimilar cultural norms, complicated contractual agreements, and multiple methodologies.  Here, we explore just a few.

Teams as Complex Adaptive Systems

As complexity science teaches us, human behaviour is complex because humans are always reacting to their environment, and therefore human activity is impossible to predict.  In addition, teams are complex adaptive systems within the larger program; the program is also a complex adaptive system operating within a complex adaptive organization; the organization is trying to succeed (by changing and adapting) within a complex adaptive global economy. As a leader of a new complex project or program, you cannot predict how your team members will react to each other, to the project requirements, and to their place within the program and the larger organization. So, complex team leadership is hard, very hard.  Stop thinking of yourself as a project or program manager, and begin to hone your team leadership skills, for you are now managing through teams.  When managing a complex project, you are a team leader, not a project manager.

Interactional Uncertainty

At first glance, it appears that team members who have worked together in the past will evolve into a high performing team quickly.  However, they may have baggage and bring biases or resentments toward one another to the new team. Whereas, team members who have not yet worked together are likely to hold back until they learn about each other, the team dynamics, the task at hand, and their expected role and responsibility. This concept, referred to as “interactional uncertainty,”[iii] recognizes that if there is uncertainty in a relationship, the participants will tend to withhold information and calculate the effects of sharing information. The project leadership team must guide members through the inevitable early stages of team growth toward “interactional certainty” that leads to trust. Then, team members can focus their energies on positive interactions.  When working in a virtual environment, it is very challenging to establish a trusting environment, achieve “interactional certainty” and therefore, foster trusting relationships.

Integration Challenges

Working with many disparate teams almost always leads to integration issues, making it difficult to amalgamate interdependent solution components that have been designed and constructed by different teams.  Teams often use dissimilar procedures, practices, and tools which results in work products of varying quality and consistency.  Finally, deficiencies in many project management techniques, e.g., risk management and complexity management can lead to unknown consequences requiring rework to resolve.

The Complex: Great Teams are Complex, Very Complex

To lead complex layers of teams, project leaders must leverage the potential of teams, master team leadership, and learn to use sophisticated collaboration, communication, and coordination systems.

Teams are a critical asset used to improve performance in all kinds of organizations. Yet today’s business leaders consistently overlook opportunities to exploit their potential, confusing teams with teamwork, empowerment, or participative management.²  We simply cannot meet 21st century challenges, from business transformation to innovation to global competition, without understanding and leveraging the power and wisdom of teams. 

Leverage the power of teams to achieve results unavailable to individuals

“Teams help ordinary people achieve extraordinary results.”

—W.H. Murray, Scottish Himalayan Expedition

Successful complex project managers appreciate the power of teams. Success stories abound: Motorola surpassed the Japanese in the battle to dominate the cell phone market by using teams as a competitive advantage; 3M uses teams to reach its goal of generating half of each year’s revenues from the previous five years’ innovations. High-performing teams are all around us: U. S. Navy Seals, tiger teams established to perform a special mission or attack a difficult problem, paramedic teams, fire fighter teams, surgical teams, symphony orchestras, and professional sports teams. These teams demonstrate their accomplishments, insights, and enthusiasm on a daily basis and are a persuasive testament to the power of teams. Clearly, we must learn how to form, develop, and sustain high-performing teams if we are to deliver on complex projects.  Teams are powerful.  Use your teams to achieve exceptional results!

Harness the wisdom of teams to get great people to get great results

“None of us is as smart as all of us.”

—Ken Blanchard, Consultant, Speaker, Trainer, Author

Warren Bennis talks about team members who along the way provide support and camaraderie for each other. Foster these characteristics in your teams described by Bennis: ³

• They have a shared dream.
• They abandon individual egos for the pursuit of the dream.
• They are isolated and protected from political influences.
• They are united against a real or imagined enemy.
• They view themselves as winning underdogs.
• They are willing to pay a personal price.
• They are strong leaders.
• They are the product of meticulous recruiting.
• They deliver the goods.

The successful complex project managers strive to understand the benefits of teams and learn how to optimize team performance by developing individual members, fostering team cohesiveness, and rewarding team results. Since teams are the primary building blocks of strong organizational performance, complex project managers cannot ignore the power and wisdom of teams.⁵

Exceptional team leadership leads to exceptional results.  So how do we groom ourselves to become exceptional team leaders?  There are a few “must haves” including experience, team development and nurturing, exceptional team composition, and an optimal team structure.

There is no substitute for experience

Projects fail because of people, not science or technology. Team leadership differs significantly from traditional management, just as teams differ from operational work groups. The complex project manager leads through others; it is those “others” who actually manage the project. Team leadership is more of an art than a science and is fraught with trial, error, and experience. Expertise in communications, problem-solving, and conflict resolution and other so-called “soft skills” are essential. Leaders of complex projects derive their power and influence not so much from a position of authority in the organizational hierarchy, but as a result of their ability to build relationships. These leaders must be expert, influential, well-connected, held in high regard, indeed, considered indispensable.

Learn how to build and nurture your team

Leaders of complex teams must have an understanding of the dynamics of team development and how teams work; they develop specialized skills that they use to build and sustain high performance. Traditional managers and technical experts cannot necessarily become effective team leaders without the appropriate mindset, training, and coaching.  Make a concerted effort to develop team-leadership skills and dedicate considerable energy to transition your team members into a cohesive team with shared values, beliefs, and an ethical cultural foundation. The best teams are collaborative and share the leadership role, depending on the precise needs of the project at any given time. The situational team leader understands that varying leadership styles are appropriate depending on the different stages of team

Get the “right stuff” on your team – recruit meticulously

Selecting the right members for your team is perhaps the most important decision you will ever make.  When you enlist team members, do so not only based on their knowledge and skills, but also because they are passionate, strategic thinkers who thrive in a challenging, collaborative environment. Conventional wisdom tells us to determine what needs to be done first and then select the appropriate person who has the knowledge and skills required to do it. However, in his book Good to Great, Jim Collins emphatically tells us: first who . . .then what. Rather than setting a direction, a vision, and a strategy for your project and then getting people committed and aligned, Collins and his research team found that great companies did just the opposite: They first selected the people who had the “right stuff” and then collaboratively set their course.⁹

Establish an optimal team structure

Structure matters! Typical contemporary team structures suggested by gurus like Jim Highsmith[iv] and Jim Collins[v] include:

• A core team or “hub” structure. This structure reflects aspects of both hierarchical and network structures. This model is often comprised of several customer teams, numerous feature teams, an architecture team, a verification and validation team, and a project management team. Teams take on all possible configurations: virtual, co-located, or a combination thereof.
• Self-organization extensions. As the number of teams within the project expands, the organizational structure transitions from a team framework to a project framework within which multiple teams operate. Creating a self-organizing team framework involves: (1) getting the right leaders, (2) communicating the work breakdown and integration strategies, (3) encouraging interaction and information flow between teams, and (4) framing project-wide decision-making. Obviously, as more teams are formed, complexity increases. Managing inter-team dependencies is critical; teams need to fully understand their boundaries and their interdependencies.
• A culture of empowerment and discipline. Behaviors required of teams when working in this structure include: (1) accept accountability for team results, (2) engage collaboratively with other teams, (3) work within the project organization framework, and (4) balance project goals with team goals.

For effective team collaboration, communication, and coordination of complex team structures, consider the following practices:

• A standard methodology 
• Collaborative planning and decision making 
• State-of-the-art collaboration tools 

A standard methodology fosters discipline and facilitates communication

For complex projects, using a standard methodology—while encouraging each team to tailor it as needed—goes a long way toward eliminating unknown cross-team dependencies.  However, a word of caution: Do not overly burden the various teams with standards, but do insist on those that are needed to provide a realistic view of the overall project and to manage cross-team dependencies. Enforce the use of standard collaboration procedures, practices, and tools.

Collaborative planning and decision making promotes commitment

Involve all core team members in the project planning process and seek feedback often to continually improve the performance of the team. There is no substitute for face-to-face working sessions during planning meetings, especially for brainstorming, innovating, analysing feasibility of potential solutions, scoping, scheduling, identifying risks and dependencies, and conducting critical control-gate reviews. When preparing your project budget, be sure to include adequate time and budget to bring core team members together for these critical sessions.  Be firm about establishing decision checkpoints that involve all core project team members at critical junctures.

State-of-the-art collaboration tools facilitate consensus

Secure best-in-class software tools to enable collaboration and document-sharing. Two general types of collaboration tools are available: professional service automation (PSA), which is designed to optimize service engagements; and enterprise project management (EPM) tool suites, which are used to manage multiple projects.

In addition, provide your team members with personal communication and telecommunications tools so that they feel closely tied and connected. If these tools are an unconventional expense item for projects in your organizational culture, educate your project sponsor on the criticality of collaboration, stressing the need to manage the cross-project interdependencies that are known at the start of the project, as well as those that will emerge along the way.  Also, experiment with social networks and communities.  This computer-mediated communication has become very popular with sites like MySpace and YouTube and has resulted in large user bases and billion-dollar purchases of the software and their communities by large corporations.

Summary

So there you have it: the good, the bad, and the complex of 21^st century teams.  There is no stopping a great team. However, great teams do not happen by accident. Hard work, planning, and disciplined effort are required to convert a group of great people into a great team. For complex projects the effort is magnified because multiple large, geographically dispersed, and culturally diverse teams are involved. Leaders of complex projects cease to be project managers and become leaders of teams. Both conventional and adaptive approaches are needed for large, long-duration projects to be successful (Table 2).

Managing Large, Dispersed, Culturally Diverse Project Teams
Complexities	Many complex adaptive teams Human behaviors impossible to predict Multi-layered, interdependent teams Geographically dispersed Culturally diverse Virtual Multi-skilled Dissimilar procedures, practices, and tools leading to integration issues Risk management inadequacies and inconsistencies, leading to unknown events Integration of interdependent components produced by different teams
Management Approaches	Adaptive Establish an experienced core leadership team Leverage the power of teams Build great teams Use edge-of-chaos management when innovating and experimenting Empower agile teams Instil teams with a culture of discipline Use virtual teams as a strategic asset Insist on face-to-face meetings for key planning and decision-making Conventional Lead, don’t manage contractor teams. Insist on standard procedures and tools when appropriate. Establish a culture of collaboration and open communication.

Table 2: Approaches for Managing the Complexities of Large, Dispersed, Diverse Teams

Adapted with permission from Managing Complex Projects, A New Model, by Kathleen B. Hass. ©2009 by Management Concepts, Inc. All rights reserved. www.managementconcepts.com/pubs

Don’t forget to leave your comments below

---

Kathleen B. (Kitty) Hass, PMP, is an Award Winning Author, Consultant, Facilitator, and Presenter, an IIBA Board of Director and Chair of the IIBA Chapter Governance Committee and Chapter Council. Kitty is the president of Kathleen Hass and Associates, Inc., a practice specializing in business analysis, complex project management, and strategy execution. Download free information about business analysis at www.kathleenhass.com or contact her directly at [email protected].

References
[i] Jim Collins, Good to Great, Why Some Companies make the Leap and Others Don’t (New York: HarperCollins Publishers, Inc. 2001.)
[ii] See Use Virtual Teams as a Competitive Advantage, by Kathleen Hass in the March issue of the IIBA Newsletter. http://www.theiiba.org/AM/Template.cfm?Section=Member_Newsletters&Template=/CM/HTMLDisplay.cfm&ContentID=5517
[iii] Christian Jensen, Staffan Johansson, and Mikael Lofstrom, Project Relationships – A Model for Analyzing Interactional Uncertainty  (International Journal of Project Management, Vol. 24, No. 1, 2006) 4-12.
[iv] Jim Highsmith, Agile Project Management: Creating Innovative Products (Boston: Addison-Wesley, 2004), 235-251
[v] Jim Collins, Good to Great, Why Some Companies make the Leap and Others Don’t (New York: HarperCollins Publishers, Inc. 2001.)

Most of the projects I am involved with nowadays are organisational change projects, many related to the implementation of a true project management culture and all its relevant processes, behaviours and tools.

I use a “user-centric”, self-organizing, collaborative approach I call “changeboxing”, that I developed specifically for these types of projects. It is a mixture of agile project management “timeboxing” techniques and collaborative implementation approaches. It is based on voluntary work by concerned stakeholders of projects in an organisation, following an internal diagnosis where these stakeholders identify and confirm the organisational change they desire, and then work together to make it happen.

More often than not, the approach works quite well and accelerates new processes’ implementation and integration in the day-to-day life of the organisation they serve to improve. To succeed, however, the whole change process must be based on a real desire to change and to collaborate as a team towards the new project management culture…and complete transparency and trust among stakeholders. I have been coaching customers through this “changeboxing” approach to organisational change for five years now. When we have run into difficulties and the approach failed to deliver the expected harmonious change, it was always because a group of stakeholders were not sincere and would try to manipulate the others in preserving THEIR status quo. When such a roadblock appears, I really expect that upper management, as the sponsor/client of the changes, will take on its traditional role as the legitimate ultimate organisational authority. It must give a precise indication of its expectations, give clear direction and then just do what it’s supposed to do: DIRECT. This might look like a very rigid approach from “agile” me. Maybe! My belief is that exercising Situational Leadership [¹] is an agile approach and that the S1 alternative (directing and telling) is quite a valid alternative when the context calls for it.

Alas, in all instances when such a roadblock appeared, none of the chief executives involved came forward to apply the required directive approach. They preferred waiting for the conflict to just settle by itself or to get some more “persuasive S2 alternative” change management going on in a context where the will to change is not there. Of course, the change then stalled and stalled; the status quo desired by the resisting group was maintained. And the organisation ended up worse that it was in the first place, because the vast majority that desired the change was deprived of it and will not collaborate next time we come to them to work on improving their organisational project management maturity.

I am really puzzled by the aversion to directing and using authority, which seems to be the norm now with upper managers. I give a course on “How to influence with limited or no formal authority” because, it seems, people do believe that it is so difficult to influence without formal authority. Yet, those who have legitimate authority seem to be in need of their own course: “When and how to use the formal authority that you already have”.

For me, the issue is very simple here. It is part of leadership to direct when need be, and there will always be instances where directing is the preferred, if not the only option. When times come for real change and a majority calls for it but cannot move forward, because of a group or a person, not wishing to be part of a team effort, resists obvious and necessary organisational change, project management leadership through directing is called for. Real project leadership can face adversity. Real project leadership is not a question of leading by consensus. Real project leadership is a question of leading and taking charge when times call for it. Let the true leaders rise and manage properly these organisations where change is necessary, that is all organisations.

1 Situational Leadership models explain that proper leadership style is contextual and that basically four different styles can be used depending of the context: S1-Directing, S2-Persuading, S3-Concerting, S4-Letting go (autonomous teams)

Don’t forget to leave your comments below