Figure 2.4 sets out a typical organizational structure of a project. The details of the project structure will vary according to specific roles that people play in a particular project. We look at both in this section. Different organizations will label the same roles with different names. Irrespective of what actual names are used, the underlying responsibilities of the roles described here are found in most projects. Here we use the names and roles given in the PMBOK Guide for convenience, together with a few others, such as the project steering committee to reflect the reality of real-life project management. You need to understand the rationale for each of the roles in a project, and what their responsibilities are. You also need to know what these roles are actually called in your organization, as it is unlikely that your organization will follow the PMBOK Guide nomenclature for every project role. The most important roles in a project are the Sponsor and the Project Manager. It is vital to understand what these roles do and don't do in project management.
Figure 2.4. A representative organizational structure of a project
There are many different names for the titles or roles of those in the project who come under the Project Manager. The three main types are shown here. Sub-project managers have management responsibility for a part of the project. Subject matter experts may or may not perform project work, but their primary contribution to the projects is their specialized expertise remember that the Project Manager is not expected to know about all areas of the project, their role is to do project management, so subject matter experts provide the expertise necessary to design and plan the project and to make sound and informed decisions on their subject matter. Project team member is the term for anyone else on the project. It is useful to have a term for the group who collectively do project management in the project, and this is the project management team. The project team means everyone involved in doing project work, although normally the Customer, Sponsor and Steering Committee are excluded from both these groups as they are not involved in doing day-to-day project work. Where there is a Project or Programme Management Office, it may or may not be involved in project management or project execution, which is why in this diagram the PMO box is partly included in the broken-lined circles. On large projects or where the individual has negotiated a title increase, the Project Manager may be called Project Director.
The sponsor is responsible to the organization that owns the project for the resources committed to the project and, ultimately, for the project delivering results and for the performance of the project. Often the sponsor is a senior manager who wants the project done, usually because it will benefit them in some way. In some cases the sponsor may see the need for the project themselves, but in other cases the suggestion may come from elsewhere in the organization and the sponsor then adopts or is asked to adopt the idea. If there are several senior managers who will all benefit from the project, then it is important that this group agrees to nominate a single sponsor to avoid inefficiency in the project. Although the rule is 'one and only one sponsor in a project', there are many organizations where two or more sponsors are appointed because of the power structure in the organization and how the project relates to it. If your organization decides to appoint two sponsors, it is usually best to live with it rather than to argue the theoretical case for getting rid of one of them. It can be that the Project or Programme Management Office (PMO) is the sponsor see below.
A good sponsor is one who understands how the performing organization works and can get things done. The sponsor clears the way for the project and establishes links from the project to key areas within the performing organization. This requires pragmatism, political sensitivity and good management skills.
The sponsor's role is necessary because it is impractical for the whole management of the organization to be involved in every decision about directing the project. The organization therefore charges the individual who hopes to get the benefits of a successful project with the responsibility and authority for project supervision. This is not the same as project management it is rather someone who acts as the buyer of the project on behalf of the organization. Conceptually, the sponsor has a business need for the project, the firm grants the sponsor the money and resources for the project, and the sponsor then contracts with the project team to execute the project. Hence in project organization terms the project manager works for the sponsor, who works for the business.
The sponsor's focus is on the business objectives, and it is common for there to be little contact with the sponsor other than at major project events, unless the project is drifting off track and it looks like the business objectives will not be met. Sponsors tend to be busy people. Nonetheless, it is vital for there to be good communication between the sponsor and the project manager, and the sponsor should ensure that if the project manager needs to talk to them then the sponsor is available. It is the sponsor who has the final responsibility to protect the business by intervening if required to get the project back on track or, if necessary, to cancel the project before extra money is wasted.
The BSI definition of a sponsor is an 'individual or body for whom the project is undertaken and who is the primary risk taker'. This definition is useful because it highlights that the sponsor has the most to lose, the most at stake in the project.
A common problem for sponsors right now is that they are appointed as project sponsors but feel that they themselves lack experience and training in project management. The difficulty felt by many sponsors who are in such a position is that they cannot afford to reveal their lack of experience either to the project team or to their peers. If you are a sponsor who feels this, fear not. Project management is applied common sense, and the essential features of sponsorship are entirely within the skills and experience that you will already have acquired in your career. Your main job as sponsor is to do three things: listen to the project manager and intervene if they are out of their depth or heading in the wrong direction; keep the stakeholders on side with the project and smooth communication between them and the project team, especially the project manager; and keep your eye on the purpose of the project and see that it keeps heading in the right direction. Like all senior management jobs, much of project sponsorship is a matter of understanding the power and politics in your organization. Finally, if you feel that some training in project management would be useful, there are a number of specialist courses for project sponsorship; half a day is probably more than sufficient.
The project manager in effect contracts with the sponsor to manage the project that is defined in the project charter or project plan. The limits of the project manager's authority and responsibility must be understood by both the project manager and the sponsor. In most organizations, the project manager has authority to use money and resources up to the limits set out in the plan or charter but no more. If the project manager learns that the project will take more than has been authorized, then it is vital to seek reapproval on the new basis, otherwise the project manager will have no authority to proceed. The project manager plans, organizes, controls and reports project activities, working closely with the sponsor as appropriate. In practice this usually means that the two work more closely at the start of a project, to define scope and plan the project, and to work out what the project is and how it will fit into the organization. Once these things have been worked out and the project moves into the execution phase then contact tends to reduce, unless major problems or changes arise. The size of the project determines what the project manager does. On smaller projects, the project manager may undertake activities such as drafting the scope statement and planning on their own, but on large or complex projects a team of specialists may be required.
Finally, we should be quite clear about what the project manager's role is and is not in project management. It is about managing the project, not doing the work. Often in very small projects the person who is managing the project is also doing some of the work. There is nothing wrong with that, but only the work of managing the project can be called project management. For example, if a project manager is appointed to supervise the move of a thousand staff from one office building to another, the project management role is to plan the move and manage the people who are to physically carry the furniture from one location to another, and deal with all the communication needs and unexpected issues as they arise. The project manager is not, as project manager, doing the lifting of furniture. Management is a real activity that takes much time and effort, and has its own distinct discipline and body of professional knowledge. Nor is it the project manager's job to know everything about the subject matter in their project, but it is their job to ensure that the project has or has access to people with the right expertise. A project manager must be a subject matter expert in project management, and should ideally also have experience of the industry in which the project is working: it is project management expertise that is the primary consideration, because that is the prime need for the project management role.
Who makes a good project manager? This varies according to the industry and the nature of the project, but in general good project managers are:
Good project managers will normally have been trained in some recognized project management methodology. The main methodologies current at the time of writing are the following:
Previous standards for project management include:
What matters much more than which methodology or whether project managers have been trained is their ability to manage projects, which should be evidenced in their career history. Project managers' careers typically start in a project role other than project management, perhaps as the administrative assistant to a project manager, which is an ideal way to learn because one gets to see all of project management but without being exposed to the risk of responsibility. They then progress to managing a small project, perhaps an internal one, and from there get larger or more important projects according to their abilities.
Project team member
Team members carry out tasks or groups of tasks specified by the project manager, with agreed deliverables and to agreed timescales. Team members are expected to take responsibility for their own tasks, to keep the project manager informed about progress and to exercise initiative if they become aware of other factors outside their specific task that might also affect the project.
The team is vital to the project. People who want to be on the project will be much more valuable to it than people who don't want to be on the project. This means that the sponsor and project manager have a selling job from the moment the project is first conceived.
In organizations where several projects together form a programme, also known as a portfolio of projects, there will be a committee to oversee the programme. The programme board reviews, approves and prioritizes project proposals as well as authorizing resource allocation. It monitors project exceptions and instigates corrective action. It aligns the projects within the programme and may mandate standard methodologies, tools, techniques, reporting and training for each programme. ('Programme board' is not a PMBOK Guide term.)
Programme or project management office
Where an organization runs many projects, there are economies of scale to be gained from standardization across them. There may also be a need to coordinate projects as a portfolio, or programme, and to apportion scarce resources between them on a systematic basis such is the case for having a programme or project management office (PMO). The PMO is becoming an increasingly common structure in organizations, as more and more organizations see benefits from it.
The role of the PMO ranges from at one extreme nothing more than assistance and support at the whim of the project manager, to at the other extreme a management and controlling function that allocates resources to projects, directs how they should be done and how and when they should report, and enforces training and standards on project teams. A PMO that is mandated to operate more towards the controlling end of this spectrum is by no means necessarily a bad thing from the point of view of the project manager and the project, as it frees up much time for the project manager to concentrate on the tasks most essential to the project, and it also provides a large measure of insurance against failure. As ever, the personal relationships and communications established by the project manager are vital. If you are a project manager and are expected to work under a PMO, find out what it can do for you and your project, build excellent personal relationships with the key people in it, and use it. The PMO may take on some of the responsibilities of the project sponsor, or may even fill the role of the sponsor. The role of a PMO may include such things as:
Although there is a clear theoretical difference between a programme and a project, and a useful one, in practice it is unlikely that a single organization would run two separate bodies for programme and project management office, so we treat them both in one section here.
The term 'project office' is slightly different from 'project management office'. In project management, the project office is a role, not a room or a place. The role is to provide administrative support for the project. It has some relationship to a project management office in that a PMO can perform some or all of the functions of a project office. The project office is a good role in which to place graduate trainees and others at the start of their careers to give them safe exposure to project management, but it is also a career path in its own right. On a project of any size the project office or administrative function is substantial, and it is valuable to free the project manager from having to do project office tasks.
By this term we mean the organization, company, firm, business, government department or charity that owns the project, that organization within which the project is performed.
Stakeholders are all those who have an interest in the project, that is, who stand to gain or lose from the project. Stakeholders may be individuals or groups; some will be inside and some may be outside the performing organization. Examples of stakeholders include:
The role of stakeholders in a project must be dealt with on a case-by-case basis. Projects can have far-reaching effects and one of the potential pitfalls of project management is to believe that the only people who matter are those on the project team and the project's customers. Stakeholders is a loose category but the unifying idea is that their opinion matters in some way, and they often choose themselves rather than being appointed by the project manager. Their impact can be very great on some projects, and in some sectors companies have developed standard contingency plans that are applied on all projects. On the positive side, a network of enthusiastic supporters of the project is one of the hallmarks of a truly successful project and can itself contribute to that success.
Stakeholder management has elements of public relations, but project managers do not need to become public relations specialists. On small projects it is usually enough to remember that there are interested parties outside the formal project boundary, and to make an effort to communicate with them at appropriate times.
If the notion of stakeholders as described above is too broad, for example the idea of including a protest group as a stakeholder gets in the way of thinking clearly about the project, then the term 'influencer' may be useful as a kind of weak stakeholder, or a class of stakeholder who we would rather did not exist.
Subject matter expert
The project manager is required to be an expert in project management first and foremost, not in the subject matter of the project, although experience in it helps. The project will need expert input that the project manager and sponsor do not possess. This comes from people called subject matter experts. They may or may not do more than provide information and guidance to the project. Expert advisors can often add value quickly if they are used appropriately to address a specific problem within their area of expertise. Such inputs from internal or external experts may not require full-time membership of the project team, though if subject matter experts are used on a part-time basis then it may be necessary to set aside time to ensure they are up to speed with the latest developments in the project, and they should at least be given regular briefings. ('Subject matter expert' is not a PMBOK term.)
Seller (also Supplier)
'Seller' is the PMBOK standard term for a supplier to the project of products or services, although in this book we use the terms 'seller' and 'supplier' interchangeably, to accord with common usage. It is common for projects to rely on external suppliers for some of their critical outputs. The supplier might take on a sub-project but you, the project manager, are still responsible for overall delivery and should manage the supplier with no less care and attention than internal resources. Suppliers should be set SMART objectives and be required to give timely and accurate progress reports like other members of the team.
Users and customers (and 'intelligent customers')
The project's customer is the person or group for whom it is being done. They are the intended ultimate and main beneficiaries of the project. They benefit from the project's results. This makes them a critically important group. Their most formal relationship with the project is usually in specifying the user needs at the beginning of the project, and in accepting the project outputs at the end. During the project the role of the customer will vary but they will usually be called upon to provide continuing guidance throughout the life of the project in order to ensure that the results of the project stay on track and, just as importantly, that the expectations of the customer and of the project team remain aligned. Customers need to be managed by the project; this is a key task for the project manager and sponsor, and it usually requires that the customer be openly and honestly engaged in the project.
Where the customer is a large organization or a large group of people, then in order to keep communications working effectively it is normal for the customer to appoint a single point of contact to handle the interface with the project. In some cases this representative may need to have the authority to make binding decisions on behalf of the user group, including the decision to accept or reject changes in the project objectives. In some cases too an 'intelligent customer' may be designated. This term is not used to imply that all the other customers are not intelligent, but means that the designated intelligent customer has a detailed understanding of the results required of the project. Test pilots could be examples of intelligent customers for aircraft, for example. ('Intelligent customer' is not a PMBOK Guide term.)
The PMBOK Guide definitions for the terms 'user' and 'customer' given here imply a useful difference. Both the project's customers and users use products and services delivered by the project, but only the customer uses results of the project. One difference between results on the one hand and products and services on the other is that only results include outcomes.
To illustrate this difference and why it is useful, consider the example of a project to reduce credit card fraud. The customer of the project is the bank that issues the credit card, because the bank and not the customer benefits most of all, and directly, from the project's outcome, which is reduced fraud. (Generally speaking, the bank's customers do not pay directly if they are the victims of credit card fraud; it is the bank that bears the loss. For clarity in this example, ignore the minor costs of inconvenience, etc.) However, the project may produce certain services, such as a verification code, as part of achieving the desired end state, and the credit card holders may have to use the verification code. Hence both the credit card holders and the issuing bank are users but only the bank is the customer, in project terms. Why does this matter? In short, because in such a project all users need to be satisfied with the service they get from the project: for example, if the verification code service is such that credit card owners refuse to use it, the project will fail. So all users need to be engaged appropriately in the project, but in different ways. What sets apart the customer from other users in this example is that it is only the customer who has a direct interest in the outcome of the project, which is to reduce credit card fraud. If the reduction is not great enough from the customer's point of view the customer being the bank then the project will be a failure, no matter what the other users feel about the verification process. So, in your project, understand who the customers and users are.
Top of Page