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?
Planning
It 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 Organization
This 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/
