PM-Foundations – “H” is for Humble

A few weeks ago I listened to the eulogies at my father-in-law’s memorial service and reflected on the fact that it was not what he had accomplished in his lifetime that was so important, but rather how he accomplished it. My father-in-law was an accomplished mechanical engineer who during his time a McDonnell Aircraft was involved in testing the first Mercury space capsule prior to its flight. He moved with his family to Dayton in 1960, and was employed at Wright-Patterson Air Force Base, where he spent 30 years as a Structural Test Engineer. During his career, he was responsible for conducting full-scale tests and is the author of many technical reports describing these tests. He received numerous awards and letters of commendation for his work during his career. During all his years as an engineer, he was most known for the dedicated and unassuming manner in which he led these mission critical tests. This humble and committed approach carried over to his personal life as a husband, father, and grandfather. He was the person that would quietly “step up” and solve problems, whether it was finding the missing homework, or picking up the grandchildren from a band competition.

I share these thoughts about my father-in-law because I think they are very relevant in the context of the role of a project manager. The project manager role is responsible for leading the team to achieve specific project goals and objectives. Team members tend to more clearly remember and describe how the goals and objectives were achieved, vs. if they were achieved. Traditional project leadership involves a command and control type of approach, with the project manager monitoring and directing activities. In contrast, the servant leadership style puts the needs of the team member first, and the project manager’s role is focused on supporting project activities and removing roadblocks. I am not saying that there is one “right answer” to the appropriate project leadership style, but I do believe I would prefer to be remembered as a hardworking and humble project leader, than a hard-driving and demanding project leader. The servant leadership style creates a high degree of engagement and participation of team members in decision-making, as the project manager encourages and supports team members to leverage their full potential and abilities. Below I highlight several ways that a project manager can take a more humble and supportive approach, while still leading the team to successful project outcomes.

7 ways to be humble while leading a project team

As a project manager, there are a number of tangible things that you can do to establish a servant leadership approach to project management. This approach places heavy emphasis on creating a fully engaged team, establishing a positive project environment, and focusing on supporting vs. directing project activities. These 7 tips represent a combination of applying servant leadership based skills, and implementing practical techniques to enhance the project environment.

1. Articulate the Vision & Emphasize Teamwork – I spend a lot of time making sure the project team understands that they are a team working towards a common objective, and not a bunch of individuals assigned to a project. Establishing a group that works as a team starts with making sure the team understands what we are trying to accomplish, and what success looks like. It also includes ensuring that everyone has internalized what their role is on the team, and how their role connects with the success of the overall project. There are things you can do to make sure the group feels like a team. Schedule regular team interactions (team meetings), provide meaningful project updates, and promote collaboration / interaction. Unless this group has worked together before, it takes some real work and focus on your part to make the group feel and interact like a team. Do not be discourage or give up as the team traverses through the forming and storming phases of creating a team. Your leadership can make a significant difference in terms of how the team works together.

2. Focus on Facilitating vs. Directing – Much of what a project manager does involves facilitation – enabling project teams to collaborate to get work done. Project managers facilitate meetings, decision making, and issue resolution (to name a few). Effective facilitators understand the impartial role of the facilitator, ask good questions to promote meaningful discussions, and leverage facilitation tools to achieve the desire results. Facilitation encourages team members to perform project work in a highly collaborative manner.

3. Exercise Active Listening – Active listening is required to understand what people are working on, identify challenges team members have encountered, and capture ideas to improve project performance. Active listening also provides the project manager with better “peripheral vision” (things that are not in the project manager’s direct line of sight) to identify potential problems or risks. Many project managers feel that leading involves a lot of talking, and I would argue that leading involves much more listening.

4. Leverage the Talents of the Team – As the team is forming, it is important to get to know the individual team members. Not only do you need to understand their strengths and weaknesses, but also what are the things that motivate and energize them. If you have insights into team member’s professional development path, you can help align work with the areas where they have talents, are excited about, and/or desire to learn. Aligning work and responsibilities in a manner that gives people a chance to “step up” on the team goes on a long ways towards building a highly motivated team that delivers positive results. The opportunities on the team can be both in the form of specific work assignments, as well as roles (e.g., facilitation of team meetings, coordination of team events).

5. Be Accountable to the Team –The servant leader will quietly take accountability for actions required to remove roadblocks encountered by the team. You complete these actions with the same diligence and urgency that you would expect from other team members. You don’t want to become the “weakest link” that is responsible for an open issue that blocks progress, and impacts project success.

6. Recognize Contributions – It is extremely important to recognize people’s contributions on the team. There are two categories of contributions that I recognize on the team – (1) efforts that help the team achieve its goals, and (2) efforts that demonstrate or promote teamwork. As the project manager, you are recognizing contributions that helped drive positive project outcomes based upon either the work that was performed, or the way in which it was performed. A significant amount of positive energy can be created on the team by recognizing the right efforts at the right time. The recognition does not need to be elaborate, but it must be sincere, and a bit of creativity helps generate a fun atmosphere on the team.

7. Close the Project – When you have come this far with the team, do not forget to bring appropriate closure to the effort. Effectively facilitating the lessons learned process helps the team reflect on what was accomplished, how it was accomplished, and what would the team do differently on the next project. This is the opportunity for the team to have a real impact on how projects are completed within your organization in the form of implementing continuous improvement actions. The other important element of project closure is celebrating success. Facilitate a project celebration that helps team members feel good about was accomplished before they rush off to their next assignment.

This blog post is dedicated in loving memory of Murray N. England (May 7, 1930 – January 24, 2013).

Advertisements

PM Foundations – Project Assumptions

You have probably heard the saying, “Be careful when you assume something. It will end up making an Ass of U and ME.” From a project management perspective, assumptions are your friend. Assumptions are things that you believe to be true which may not be true. Assumptions help you clarify the thought process behind project plans. They also make it possible to get beyond seemingly impenetrable roadblocks during the planning process. Every project has a certain number of unknowns. If we waited until everything was known, a project would never get started.

 

Examples of Assumptions

  • Benefits associated with the project – When building a business case, you often need to make assumptions about what impact (hopefully positive) the project will have after it is completed. You can gather information (e.g., time studies) to refine the assumptions, but there will still be unknowns until the new processes and systems are in place and fully operational.
  • The way things will work within the product – You do not know exactly how something is going to work until you start to define and build it. This means that during the planning process you probably need to make some assumptions about what “it” is. These assumptions will impact the planned effort and duration of the project.
  • Things you can leverage to develop the product – Often times you are not starting from scratch. There are assets from previous efforts that can be reused, but you may not know exactly to what extent. Another good example of when to create an assumption.
  • Resources you will use to build the product – The number and types of resources will definitely have an impact on the timing and quality of your efforts. At the time you are planning the project you may or may not have all the exact resources in place – this includes the partners that you may hire to help with the effort. The assumptions in this area also include things like: Do I need to include time and costs for training? Do I have the facilities and computers available to support these resources?
  • Dependencies and lead times – What needs to be completed to start working on specific activities? If you wait for all the answers to these questions, you will never complete the project schedule.
  • Cost of developing the product – You may not have all of the exact cost estimates, but you need a project budget. Again, you can gather information (e.g., costs from similar projects) to refine the assumptions, but you may still have some unknowns associated with the cost / pricing for specific components of the effort. Insert an assumption.

When do you make assumptions?

  • Developing the business case – As I mentioned in the examples, during project initiation, when you are developing the justification for the project, there will be a ton of unknowns and assumptions help construct the initial business case for the project.
  • Developing the project plan – Throughout the planning process (defining the product and project scope, creating the project schedule, and developing the project budget) there will be things you will not know until you get to that point in the project.
  • Managing change – As project changes occur you may not know the exact impact of the change on the project or product. This is a good example of why assumptions must be managed throughout the project life cycle.
  • Managing risks – Just by the very nature of a risk, assessing the probability or impact of a risk may require some assumptions (e.g., if this risk occurs it will delay the project by 2 weeks). Try and get your mind wrapped around that one – unknowns related to the unknowns.

Best practices associated with assumptions

  • Do not use assumptions to CYA – be specific, and you must believe them to be true – I hate it when I run across assumptions like: We have enough resources to complete the project. –or- The client will be available to approve the deliverables. These assumptions are either added because of a CYA mentality or because they are believed to be untrue. Assumptions need to be specific and manageable, and most importantly you need to believe they are true at the time you identify them – if not, they are just “noise” in your project plans
  • Make sure they are documented – When you identify an assumption, document it, either in the project management plan or in a separate list of assumptions that are maintained and managed. Some assumptions seem innocent enough, but I have had plenty of times when we have had to revisit the rationale behind the plan because we did not document the assumptions well enough.
  • Assumptions need to be managed throughout the project life cycle – On an on-going basis you need to review and test your assumptions, particularly the ones that are critical to your plan (scope, timing, or cost). Assumptions can be deleted from the list as work is completed and they are OBE (overcome by events).
  • Focus on the key assumptions – Over time you tend to accumulate a lot of assumptions. Make sure that you have established a mechanism to focus on the critical assumptions (based upon the timing of the project activities, and the nature of the assumption).
  • Assumption management is tied to the risk management process – As discussed above, managing assumptions is directly tied to managing risks because they both relate to unknowns. It is a best practice to perform a quick review of key assumptions at the same time you are updating the risks. Think of it in the same way as changing the batteries in your smoke detector when you change your clocks for daylight savings time.