PROJECT MANAGEMENT FOR TELECOMMUNICATIONS MANAGERS CHAPTER 15 pps

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..

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:

Earned value and communications have already been covered The remaining topics are covered here

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

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

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,

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

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

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

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