As the project manager you cannot be expected to develop a personal relationship with every single project team member on a large project. But, everybody on the project team needs to understand the project plan. Comprehensive kick-off presentations with references to more detailed documentation are great, but they will only get you so far down the communication paths. So what do you do when you have 50 people calling you all at once needing answers because they don’t understand one piece or another?
PlanningIt is all in the project planning, because before you even get to this point, you rely on your project management tools: The project hierarchy chart and the communication plan. Appropriate use of these tools will significantly reduce project risk and ensure project success.
I look at leading a large project like leading a small company. The average size of a small company in the US being somewhere between $500,000 and $1,000,000 in annual sales and companies that size will not have anywhere near 200 employees. So you are kind of like a president of a small company every time you are leading one such project. Sometimes you have to hire your team, sometimes it is already provided for you. You have a board of directors aka. your stakeholders or their delegated liaisons to them. Just as a company has vice presidents, managers and supervisors, you need to have your vice presidents for your project.
Project OrganizationThis is where organization of the project team is very important to project success. Remember you can’t possibly develop a personal working relationship with everybody on a team of 50 members, let alone 200 or more team members. Do your project planning and define a core project leadership team, or in other words vice presidents for your project. These are the folks that you develop the personal working relationship with. As the project manager, work with them and develop a good project hierarchy and communication plan. Delegate specific areas of responsibility to each of your project leadership members. And delegate communications through them as selected points of contact.
For this example I will discuss integrated enterprise changes that must be changed throughout a great number (40 or more) of enterprise applications. But I have used the same approach for new product development with dozens of vendors as well. When such a project comes to me, the solution is not always known, but the need is. Depending upon the scope, I obtain one or more project business analyst(s) for the requirements, and one or more project architect(s)/engineer(s) for the design. I work with them to develop a project plan that includes the project hierarchy and communication plan. Upon completion of the plan, they understand exactly what is expected from them. Later, if there are questions on requirements, because a project hierarchy and communication plan is in place, those questions are channeled to the project business analyst. If there are questions on overall design or integration, they are channeled to the project architect/engineer.
When a high level design has been completed and agreed to, then the development or engineering teams are brought on board. Again, you cannot hope to develop a personal relationship with each of the engineers, analysts, developers, designers, quality assurance, production control folks and more. So each development team must have a single point of contact. That single point of contact will act as the application or engineering lead for that specific development team. I bring on board these leads and again present the plan, layout the expectations and delegate them as the single point of contact for their team and area of responsibility.
This not all that it takes to lead large projects, but by adding this organization of a good project hierarchy and a clear communication plan, you significantly reduce the over all project risk by giving clear lines of communication and responsibilities to your team and stakeholders.
Originally posted on: http://blog.ciber.com/2013/leading-large-teams-and-reducing-project-risk/