Agile Project Leadership

Leading from Within: Supporting the Right Project Team

by Kent McDonald


In my last article, I provided some thoughts on picking the right project team. This time around, I thought I would extend that thought and provide some ideas on what to do with that team once you have it formed.

Let's face it, if you went to all of that work to form the right team, you would certainly hope that your work as a Project Lead was done, right? Especially if you buy into some suggestions from my earlier articles about letting the team be self-organizing. Hey, if they are going to do all the planning, tracking, and keeping each other honest, I can just take an extended trip to Vegas, right?

Oh, if only it were that easy. Unfortunately, even though you have formed a team full of rock stars, your job is not done. Want proof? Just take a look at the 2004 USA Men's Olympic Basketball team. They were the odds on favorite going into the games because of the collection of raw talent that they brought to the table. But a funny thing happened on the way to the Acropolis (this was Greece, after all); they ended up going 5–3 and "settled" for the Bronze Medal. I know, I know, a bronze medal is quite an accomplishment for most folks, but when you face really high expectations...

My much belabored point is this: you may be able to build a fantastic team, but as Larry Brown found out, you still have to lead them through the project. Now here's the neat thing: your role as Project Lead is to coach the team on working together and to encourage the identification or evolution of leaders from among the team members. You see, during a project you are going to have different needs at different times for different skill sets. You will have the opportunity to experience roving, situational leadership based on the specific needs at certain times during the project. Throughout the entire project, you will actually witness three different leadership types that you need to be aware of: Business Leadership, Technical Leadership, and Process Leadership. I'll spend the rest of this article describing each of these in more detail. (Unless of course you wanted to talk more about basketball, in which case you can email me directly. I should note I picked the Olympic team because they noticeably did not live up to expectations. Generally speaking, I prefer the college game.)

Championing Business Value – Business Leadership

We like to think that every project has a purpose. We would also like to think that purpose is aligned with what makes the organization successful. Finally, we would like to think that everyone on the project understands that purpose, understands how it aligns with the organizational strategy, and what they can do on the project to make sure it accomplishes that purpose. We are sometimes disappointed.

There are projects out there that begin without a clear purpose in mind, have a purpose that does not aid the organization in creating a sustainable competitive advantage, or where the people working on the project do not know what the purpose is or how they can support it. I should know; I have worked on a couple of projects like that recently. Being on one of those projects is a drag. It is much akin to arranging deck chairs on the Titanic. You can work extremely hard and never be quite sure where you are going or why you are heading there.

Projects require someone to step up to help the team define the purpose of the project, tie it to the organization's strategy (to make sure it makes sense to do it) and to make sure everyone on the project keeps it mind when making decisions. Think of this as trying to answer the "Why are we here?" question (not as a human race, just for this particular project) and then use the answer to help guide team decisions throughout the course of the project.

So how do you do that? First, utilize the Project Charter as a tool for conversation instead of another step in the process. Gather all of the project stakeholders and the project team together and (gasp) discuss what problem the project is trying to solve. The resulting purpose will be more useful because it incorporates the appropriate perspectives, and it will be better understood because the people who need to understand it helped develop it.

Next you want to make sure that the project actually supports the strategy of the organization and does not run counter to it. One would think that would be a no-brainer, but how many projects have you been involved with that had no clear relevance to what the organization was really trying to accomplish, other than someone with a door on their office thought it was a good idea? Someone from the project team needs to lead these discussions, because chances are they will not be as enamored with the idea as several stakeholders would be and will be able to maintain an impartial examination of all the factors. There are several models and tools which can help this discussion, but the key is to have that discussion. If the purpose of the project aligns with organizational strategy, great help everyone on the project team understand that tie and move on. If they don't line up, stop the project, do not pass go, and do not waste the organization's money.

Finally, you need someone that is helping the team use the purpose and its tie to the strategy of the organization on an ongoing basis to help make decisions about such things as priorities and design approaches. An understanding of how a project is supposed to support the strategy of an organization can provide very simple, yet elegant rules that guide the decisions that the team makes on a day by day basis. You need someone reminding the team to think about how that particular feature helps the project support the organizational strategy. Do we really need to go to the effort of redesigning that widget when it is more important to match industry standards? Perhaps we can purchase that functionality and focus on stuff that really differentiates the company in the market.

So who is best suited to fulfill that kind of role? I look for someone who understands both the business and technical aspects of the project and is comfortable communicating with all of the project team members and stakeholders. Someone like a good business analyst who has the business and technical chops to own the business success of the project and make sure it is contributing business value to the organization, i.e. having a positive impact on the bottom line.

Championing Technical Excellence – Technical Leadership

Once you have someone focused on keeping the project doing the right thing, you want to make sure you are doing the right things in the right way. In other words, you want to make sure that the entire team is doing all of the important project activities as well as they possibly can so that quality is built into the product, rather than inspected in after the fact.

Naturally you want everyone on the team to practice technical excellence. But it is often handy to have at least one individual providing a definition of what technical excellence is in the context of that particular project, and coaching the team members to reach that level of excellence.

Keep in mind when I talk about technical excellence in this context, I am really thinking about any of the practices undertaken as part of the project. For a software development project, this is not only writing the actual code, but it is also excellence in performing tests, excellence in designing the system, and excellence in modeling the domain among others. Because my definition of technical here is quite broad, I have seen that Technical Leadership in this sense can be exhibited by one or many different individuals depending on the skills that need to be developed across the entire team.

Keeping Process Out of the Way – Process Leadership

While the actual person doing the above two types of leadership can vary based on the situation, I see Process Leadership as the responsibility of the Project Leader or Project Manager. Assuming that you let members of the team adopt the appropriate leadership roles, and plan and monitor their work collaboratively, you will eventually be inundated with obstacles that are getting in the way of the team's success. Process leadership in this case then is allowing the team to stop using unnecessary processes and only do the things that they need to do.

Here's the trick: just because you get rid of the processes that don't seem to be needed anymore, does not mean that you are eliminating the risks that they were meant to mitigate. Project methodologies are really all about risk mitigation. It just so happens that different people make different assumptions about their team's ability to mitigate those risks, which in some cases will result in the creation of overbearing process. The assumption in those cases is, "I am working with a bunch of automatons that can't think for themselves and so need all kind of structure to make sure that they don't make the mistake that a project team stumbled into 20 years ago."

Most project teams I run into are generally not filled with automatons. But put too many process controls into place, and they will start acting like automatons. Process Leadership is really all about finding the right mix of process and practice to successfully mitigate the risks you may run into while providing the team the freedom necessary to innovate, be creative, and ultimately successfully deliver what the project is setting out to do. The Project Leader is uniquely positioned to provide this kind of leadership, and when done properly, will enable the environment to allow the other two kinds of leadership to evolve in individuals on the team.

"Role Player" is not a Bad Thing

You often see two kinds of successful sports teams. Some have a superstar and their strong "supporting cast"—picture the Chicago Bulls of the 1990s when Michael Jordan was in his prime. Others are a group of very good players who played exceedingly well together and each provided their own strengths to the team—picture the Detroit Pistons of a couple of years ago. In both cases, people take over leadership roles at the right time when there is a need for their specific skill set. Contrast that with teams that have a superstar who feels that they have to do everything, either because the star's ego precludes relying on others or because the others really can't deliver. I'm not sure which category Kobe Bryant and the LA Lakers fit into, but that team is currently an example of one person trying to do it all.

Project leaders need to consider these kinds of things when working with their teams. They can't be (nor I would think would want to be) the "star" of the show and take on all of the leadership responsibilities themselves. Instead, they should try to identify the team members who are ready and able to take on business and technical leadership and help those people step into those positions. Then they can focus on keeping the process out of the team's way—and, who knows, maybe sneak in an extended weekend on the strip. I hear it's a great place to bet on a basketball game or two.








©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy