by Peter Tarhanidis
I’ve served in various leadership roles throughout my career. In one role, I worked with engineers to build and deliver a technical roadmap of solutions. In another, I was charged with coordinating team efforts to ensure a post-merger integration would be successful.
All of my leadership roles ultimately taught me there’s no-one-size-fits-all style for how to head up a team. Instead, the situation and structure of the team determines the right approach.
Traditional teams are comprised of a sole leader in charge of several team members with set job descriptions and specialized skills, each with individual tasks and accountability. The leader in this environment serves as the chief motivator, the coach and mentor, and the culture enforcer. He or she is also the primary role model—and therefore expected to set a strong example.
But, this traditional team setup is not always the norm.
Take self-managed teams, for example. On these teams, the roles are interchangeable, the team is accountable as one unit, the work is interdependent, the job roles are flexible and the team is multi-skilled, according to Leadership: Theory, Application, & Skill Development, written by Robert M. Lussier, a professor of business management at Springfield College in Springfield, Massachusetts, USA.
On a self-managed team, each person’s capabilities support the team’s overall effectiveness. While these teams do need to have their efforts coordinated, they spread leadership accountability across the group.
Members each initiate and coordinate team efforts without relying on an individual leader’s direction, according to Expertise Coordination over Distance: Shared Leadership in Dispersed New Product Development Teams by Miriam Muethel and Martin Hoegl.
Effective leaders adjust their style to the needs of varied situations and the capability of their followers. Their styles are not automatic. Instead, they get to know their team members and ensure their teams are set up to succeed.
How do you pick the right leadership style to use with your teams?
In my last post, I discussed how powers of position—legitimate power, the power to penalize and the power to reward—don’t create a productive environment. To continue the discussion, I’d like to look at how to turn over powers to team members to create more productive environments.
1. Delegate work: This is the first step toward releasing power. Delegating creates opportunities for us to entrust powers to team members. However, be cautious of downloading—searching for candidates to do work simply because we’re overloaded. Delegating is more strategic. It involves identifying the right work to delegate, finding potential in the team, assessing skills gaps, preparing a plan, providing training and then sparing time to support.
2. Take risks: Even if we delegate, the accountability for work still lies with us and we are answerable to their faults. In fact, giving work and power to team members is filled with risks. However it has its own rewards. Taking risks is essential to provide opportunities to team members, grow their capabilities and create a productive environment. We can mitigate the risks with better planning, by assessing skills gaps and by preparing a response plan. Reviewing and supporting the team members during execution is an important part of risk mitigation.
3. Be an enabler: Acting as enabler is the most powerful practice to entrust our power to the team. It means we are no longer only an actor, doing the work, but also a resource to our team members. An enabler provides direction to team members, coaches them to take new steps, enhances team members’ skills and lets them face challenges. He or she helps teams find the solutions rather than providing a readymade one.
Enabling also means providing praise and constructive feedback regularly—or even sometimes in the moment.
4. Empower: When we become a resource for our team we stop executing our formal powers because it was the manager who had these powers. One of those powers we are giving up is the power of making decisions. Empowering team members to make decisions requires patience. We shouldn’t panic and start acting like a manager to see quicker results. These moments are tests of our trust in our people. Instead, go back to the enabler mindset—explain the circumstances, suggest options and describe the benefits of finding a final or intermediate decision within a given timeframe.
By turning over these powers to our team members, we not only show our trust in their capabilities, but give them opportunities to enhance their career. This will surpass all the benefits of reward power. It will also generate a positive energy of ownership, collaboration and cooperation, leading to a productive environment that can never be achieved via the negative energy of legitimate or coercive powers.
I look forward to hearing your experience.
By Peter Tarhanidis
These days there is such a high influx of projects and such a demand for project managers, but such a limited supply of practitioners. How can companies help their project professionals improve their skills and knowledge so that they can work to meet that need?
Leaders deliver more results by sponsoring grassroots project management learning and development programs. Common approaches and best practices are shared across all levels of project managers—ranging from novices to practitioners. Therefore, if an organization has more employees who can learn to leverage project management disciplines, then the organization can meet the increasing demand, and are more likely to develop mature practices that achieve better results.
One type of grassroots effort is to establish a project management community of practice (CoP). CoPs are groups of people who share a craft or a profession. Members operationalize the processes and strategies they learn in an instructional setting. The group evolves based on common interests or missions with the goal of gaining knowledge related to their field.
For project managers, there is a specific added benefit of CoPs. They bring together a group who are traditionally part of separately managed units within an organization focused on strategic portfolios and programs.
CoP members develop by sharing information and experiences, which in turn develops professional competence and personal leadership. CoPs are interactive places to meet online, discuss ideas and build the profession’s body of knowledge. Knowledge is developed that is both explicit (concepts, principles, procedures) and implicit (knowledge that we cannot articulate).
In my experience, I have seen CoP utilized in lieu of project management offices. The members define a common set of tools, process and methodology. The CoP distributed work across more participants, increased their productivity to deliver hundreds of projects, improved the visibility of the members with management and positioned members for functional rotations throughout the business.
Which do you think drive better performance outcomes—establishing hierarchal project management organizations or mature project management disciplines through CoPs?
By Kevin Korterud
As project delivery methods have evolved, so has project leadership. Hybrid approaches have emerged: Traditional waterfall project and program managers are now faced with the prospect of having a portion of their work use iterative agile approaches. Agile Scrum Masters and product managers executing rapid iterations of new products now have to contend with budgets, financial forecasts, release schedules and business case benefits, as well as with aligning implementation of products with other projects across the enterprise.
With this as a backdrop, a frequent question that comes up from my colleagues is whether an industry needs a project manager who knows agile, or agile leads who are competent in more traditional project management practices. In today’s complex world of delivery, we urgently need both.
1. Project Managers Need to Understand Agile
It’s inevitable that a project manager will at some point oversee an agile delivery process. So it’s important that project managers start their journey to competency as soon as possible. This journey can begin with training in agile methods as well as shadowing an agile lead to see how the iterative process works.
As the journey continues, project managers will start to immerse themselves in advanced areas such as agile metrics, alignment of agile to testing and release processes as well as the people factors. A project manager will soon see what sort of projects can best be delivered through agile vs. waterfall methods, as well as the linkages to enterprise functions required regardless of delivery approach.
2. Agile Leads Need to Understand Project Management
Agile leads typically have experience with iterative methods used to quickly shape and deliver solutions. In addition, they typically have a strong business analysis background that comes into play when defining user stories.
In the past, these skills alone were sufficient for agile delivery efforts.
With the complexities of contemporary delivery, however, many agile leads now encounter similar expectations when it to comes to schedule, budget, product quality and business case realization as their waterfall counterparts.
These expectations compel agile leads to gain skills in traditional project management areas such as estimation, forecasting, resource management, technical requirements as well as testing and implementation practices. Acquiring these skills will enable agile leads to deliver higher-quality products in a more timely and efficient manner.
3. Everyone Needs Enterprise Function Support
As hybrid project delivery approaches become more common, the considerations for aligning delivery activities to produce the most value to an organization become more numerous. These considerations can include (but are not limited to) the speed at which agile produces product iterations, business and technology complexities, and the increasing expectations of consumers.
All of this amplifies the importance of enterprise functions such as portfolio management, release management and resource management. These and other traditional enterprise delivery disciplines have been identified by the Scaled Agile Framework (“SAFe”) as being key to success.
It’s not so much that the SAFe framework has had a “eureka moment” around enterprise functions as new innovations. Rather, it has identified the critical need to have these functions in place and engaged for all types of delivery. Both project managers as well as agile leads can be more successful when tightly integrated with enterprise functions. Without having robust enterprise functions in place, organizations will struggle with more frequent schedule, resource, dependency, testing and implementation conflicts. And those conflicts dilute the business value of projects regardless of delivery style.
What do you think? Do organizations need agile leads with project management knowledge, or project managers with agile knowledge? I welcome thoughts regarding delivery successes and failures relative to either or both roles.
By Kevin Korterud
My last posthttp://www.projectmanagement.com/blog/Voices-on-Project-Management/20344/ offered two tips for project managers who want to develop a big-project mindset while executing small projects: leverage support resources and implement quality assurance practices. But why stop there? Here are two more.
1. Understand Change Management
It’s easy to think small projects don’t require many business change management activities. But even a project that has a modest projected budget could face unforeseen change management activities.
For example, I worked on a project several years back that was straightforward to implement but required specialized support for remote locations. The original project budget estimate had not considered this.
Even for projects of modest size, project managers should examine the need for business change management activities such as business process transitions, different types and levels of training materials, and measuring the timely adoption of the functionality the project creates.
2. Validate the Project’s Complexity and Forecasting
Project managers running small projects are often handed a budget and schedule that allow for neither timely nor successful implementation. This usually comes about from poor estimation processes that don’t take into consideration the necessary complexity analysis typically found on big projects.
This in turn can create budget and schedule errors of a much larger percentage than the small project can absorb. In addition, small project schedules can be affected by adjustments of large projects if they share a project or technical dependency, which creates unanticipated impacts to schedule and budget.
Project managers can save themselves a lot of future pain by initially confirming the complexity assumptions for the project before proceeding. In addition, project managers running small projects still need to undertake the same level of forecasting rigor found on large projects: resource availability, work planning, milestone progress, cross-project and technical dependencies, business outage windows and other considerations that can more greatly impact a small project.
When project managers “think big” on small projects, it allows them to be successful no matter the size of the project. Do you have any advice for project managers running small projects on how to think big?