PROJECT MANAGEMENT FOR TELECOMMUNICATIONS MANAGERS CHAPTER 15 pps

Chapter
15
PROJECT MANAGEMENT
Throughout this book we have been describing the roles of people from
every department of the company who work on projects. But so far we have
not address the most critical project role – that of the Project Manager. In
this chapter we address the role, the requirements and the characteristics of
the Project Manager, and we also look at some aspects of the project that are
strictly project related. These include:
The Role of the Project Manager
PM Characteristics
Earned Value
Project Communications
Project Closure
Earned value and communications have already been covered. The
remaining topics are covered here.
238
Project Management
In project management, there are a number of process areas for which
there are defined processes. These areas are:
initiating
planning
controlling
executing
closing
We identify processes in each chapter, and each of these processes falls
into one of the five areas listed.
The Role of the Project Manager
The role of the project manager is multi-faceted. He has accountability
for all aspects of the project. He must lead the team in producing the desired
project results. The team has responsibility for the project activities;this

involves strong leadership. And it requires the use of effective motivation
techniques. He must resolve any conflict that arises. He is accountable for all
project work, including the planning, product design and development, the
implementation, the administration, and the setting and meeting of all
deadlines. He must make project decisions, and ensure quality work. He
needs to secure agreement on the project scope, and to ensure that all project
239
Project Management
communications occur smoothly. He needs to think clearly, and to
understand the politics that inevitably surround a project. He needs to
understand all of the aspects of a project at a high level, whether they be
technical, social, political or business.
The project manager may write the project requirements himself, or
receive these from the sponsor or other stakeholders. However, no matter
who writes the requirements, the first neck on the line if the project does not
meet them is the project manager’s. So the PM has to be sure he or she
knows them, understands them, agrees to them, can communicate them
clearly to others, and can get the resources to produce them. This is no small
task.
Let’s look at the key responsibilities of the Project Manager. The work
generally starts when the potential PM is approached by the sponsor, asking
about his interest in the project. The role at this point is to understand from
the sponsor as much as possible about the expectations for the project. The
Project Manager should address all the aspects of the project, right from the
beginning, including potential scope, timing, budget, expectations regarding
outside procurement, availability of resources, etc. He should also try to
understand as much as possible about the sponsor himself – his
characteristics, his attitudes, what drives him, and his general expectations.
These will also be indicators of what the PM will be dealing with if he
accepts the project. Many times a sponsor comes up with a project that looks

like such a fantastic opportunity to the potential project manager that he
forgets to do due diligence. This might get the team into a difficult and
unexpected situation later in the project. The time to start the negotiation for
the things the team might need is before the project has even started, and this
responsibility falls to the PM. It is often easier to obtain agreement for
critical items at this early stage, before any resources have been committed
and before people have set their minds on specific directions for the project.
Once the Charter has been established and signed, the next step is to
define the project. This is the development of the scope statement, as
described in Chapter 3. Once the scope has been defined, the next step is to
add some structure to it, to enable the team to define the work elements, and
the PM to determine what needs to be managed, and when. The team moves
next to the creation of the Work Breakdown Structure, one of the most
important project management tools. This is described in Chapter 5. Once
the wbs is complete, the bottom level elements become the project activities,
and these can be used to obtain the resources, the budget, and the schedule.
We have described techniques for obtaining each of these as well. In every
240
Project Management
case it is recommended that the PM lead the development, with assistance
from the full team. In order to do this, the project manager also has to
identify people with the required skills, convince them to join the team, and
negotiate with their current managers for their availability for the project.
This will require negotiation skills, as discussed in Chapter 10.
When all of these aspects have been determined, the team can complete
the remaining aspects of the project plan, including the risk management
plan as described in Chapter 4, the procurement plan in chapter 9, the
communications plan which we will cover in this chapter, and the quality
management plan as per chapter 5. With the plan completed, there should be
enough information to proceed to the gates for approval to move into the

implementation phase.
Once the gate has been passed, the implementation phase can begin. At
this point the role of the project manager changes into one of monitoring and
control. The team starts focused, heads-down work on the project activities,
and the PM ensure that all product related, and all project related work
proceeds as planned, meeting all specifications and quality objectives.
During this phase the skills that the PM uses most are different from those
used in the initial project stages. Initially, strategic vision and open thinking
were the key skills. In implementation the PM needs to clearly focus on
getting things done, and doing them properly.
Once the implementation completes, the project will move forward again,
into the closure phase. We will discuss this phase in this chapter as well.
Characteristics of a Project Manager
In order to be successful at the wide variety of requirements, the PM
should possess special skills. Some of these skills are technical (that is
technical in the area of project management) while others are soft skills. We
know from psychology that although most people do possess both types of
skills, almost everyone has much more strength in one of these areas than the
other, and even if the skills are somewhat evenly matched, most people
prefer to use one type over the other. However, every project requires the use
of all of these skills, so if the PM does not have the time, interest or ability to
use all, he needs to ensure that someone on the team will be able to pick up
those areas he does not cover himself.
The technical project management skills include such areas as time
management, cost management, scope management, project integration,
241
Project Management
quality management, and risk management. Techniques and processes for
each of these areas are included in the relevant chapters of this book.
The soft skills include such areas as leadership, team building,

motivation, communication, conflict management, expectation management,
and so on. We cover many of these later in Chapter 10, but communications
will be handled later in this chapter.
In addition to the PM skills, the project manager should have some
background in the product area of the project. But what does this mean?
There is more than one dimension to any project. In every case the project
could benefit from a PM with background in the processes, the business
area, and/or the functions required to complete the project.
The PM needs some level of 'technical' understanding. Now, what this
means can vary from one person to another. It is pretty clear that a good
construction PM will not necessarily be a good PM for a software project.
Some level of competence in understanding the software development
environment is required.
However, beyond this, there is a question of what this means. Does it
mean that the PM must have personally developed code? or would it be good
enough to have been the marketing prime on a team or three that develops
software? Or even worked very closely, maybe as a customer, with a team
that develops software? Any of these gives the person a level of 'technical'
understanding. Any of these could be enough, given the right person and the
right project, but there are no guarantees. In some projects, notably ones
where there is a major development engineering component, a significant
degree of relevant technical experience may be crucial for the PM to
maintain credibility.
However, too much technical knowledge could also be a problem. If the
PM is an engineer with strong technical interests, but he is not also the
technical prime, then it can difficult for him to back away and let the actual
tech prime do his or her job. If the PM meddles, this can cause bad feelings
and problems. It may even split the team, or cause time delays. And, if the
PM carries dual roles of PM plus tech prime, it will be difficult for this
person to fairly assess questions which would best go one direction from a

technical perspective, but another from a business perspective. Of course
this can be done, and it is done every day, but it less likely that the PM will
succeed. In the case where the PM is also the tech prime, it is obvious that
242
Project Management
technical skills are needed, both in the area of technical project management
skills and also in the project subject matter.
Also, we need to be careful when we mention technical skills. This
should be used to refer to skills related to the project - which could be
marketing, purchasing, various types of engineering or programming, etc. A
PM who has some level of grounding in many or all of these areas, but not
extensive background in any of them would be considered a generalist - but
one with good technical knowledge.
It's an interesting question.
Consider the skills required for good project management. There are
many skills listed in different references, and all are quite valid. For
instance, in
A Leadership Profile of American Project Managers
Engineering Management Review Vol. 26 Number 4 Winter 1998
We see that the most significant characteristics of an effective project
manager are:
1.
Leadership by example
2.
Visionary
3. Technically competent
4. Decisive
5.
Good Communicator
6.

Good motivator
7.
Stands up to management when needed
8.
Supportive team member
9.
Encourages new ideas
From the same review, we find:
The 12
highest ranked
characteristics and behaviours for effective Project
Management
1.
Team Builder
2.
Communicator
3.
High self esteem
243
Project Management
4.
Focuses on results
5
.
Demonstrations of trust
6.
Goal setter
7.
Demonstration of respect
8.

Flexibility in response to change
9.
Team player
10.
Employee developer
11.
High level of interpersonal skills
12.
Empowers subordinates
Which of the PM traits is most important to project success, and why?
This is greatly dependent on the project. A worthwhile exercise is to
consider some actual projects which were successful or not, and determine
which of these traits (or lack thereof) caused this.
It is interesting to sit with a group of people experienced in project work,
and discuss which characteristics they feel are important on their projects.
Many of the skills listed above will appear, as will additional characteristics.
Project management is a field where the team will never be handed most of
the things that they need to manage and complete the project. The PM must
be able to analyze information and form solid conclusions. He must have the
skill to communicate these conclusions, and to decide who are the relevant
recipients of project communications. This requires both the ability to
analyze and knowledge of the project environment.
With leadership skills and technical credibility, the PM can engender the
trust that is required to allow him to motivate that the team to buy into the
project plan to meet the project objectives.
The Project Manager needs to be politically savvy in order to understand
the implications of different decisions and directions, and to be able to
manage the environment so that the project decisions will be accepted by
those whose opinion is important to the project.
Along with this, the PM needs to be able to build good rapport and

relationships with other people, and especially to be able to gain the support
of higher management. Here sales skills can help.
Project Closure
244
Project Management
Project closure need not be intensive or time consuming. This is the
phase in which the project activities are completed, any cleanup is done.
Project documentation is completed and filed, product hand-off is
completed, and team records are finished off. If necessary, the PM finds new
positions for the team members, and personnel review information is
prepared and communicated.
According to the PMBOK
®
Guide, the outputs are project archives,
lessons learned and formal acceptance. See Figure 3.
Any loose ends are tied, and the project is essentially ‘closed’. Although
many team members are leaving the project, or maybe even have already
left, the PM should get input from each of them on the lessons learned
during the project, in order to help the next team to avoid the problems that
this one faced. The intent is one of helping future projects – not to cast
blame on the current team or team members. So this should be done in a
positive way.
All project results must be collected and included in the documentation.
If this was not done as the project was underway, it can take considerable
time at the end. So it is always best to collect as much as possible, and keep
it well organized, as the project proceeds, to prevent loss or contamination of
information. Then the closure can run smoothly, the team will look
professional, and future project teams can benefit.