Classic PM: 02 Framework

Abstract

Have you managed projects? And if so, what is a project? Can we apply the term “project” to an advertising campaign or, for example, a 10% increase in company profits? Can we call production of cogs to increase sales with this term? And what about the production of 100 cogs with certain technical characteristics?

Before entering into a discussion, it is necessary to define the terminology, only then participants are able to understand each other. So, according to the PMI project management methodology, a project is a temporary activity existing in conditions of limited resources (time, finance), which results in a unique product or service.

Often the cause of project failure is insufficient planning. The ability to plan differentiates the professional from the novice, and this applies not only to project management - for example, professional athletes plan their training so as to approach the «hour-X» in the most prepared conditions. A professional fitter knows how to do certain types of work better even before the work begins. This applies to almost all specialties, perhaps only creative and, of course, it relates fully to the project manager. Whatever the goals of the project, the project manager must conduce planning, this is the most important requirement of the methodology - plan, perform, analyze.

Another mandatory requirement of PMI is the agreement of the project manager (and management) only for those projects that the organization is willing to carry out within objective limits. Of course, this requirement to fulfill is quite problematic, especially in Russia, but nevertheless, this requirement has a health fat - if the project fails, the project sponsor will lose a lot of funds, the customers of the project will be extremely unhappy, the project executor loses potential partners, and therefore profits.

Another principle that pervades PMBok is «whatsoever you manage the project, if it’s successful - you manage it right». Of course, since PMI is a commercial organization, it will not sound directly, but this corresponds not only to PMBok, but also to the truth.

General Terms

Operational Work

This is a type of activity that does not produce any unique product or service and is the company’s ongoing activity. In addition to the classic example - production at the factory - I can mention the activities of insurance, logistics companies, lawyers, aviation and railway carriers, etc.

Program

Program refers to a group of projects that are brought together to achieve better management, reduce roject Risks and increase the cost-effectiveness of Projects. Of course, such a grouping of Projects is carried out only on the condition that they are somehow related to each other. For example, to link the construction project of a soft toy factory and the repair work project in the boiler room is not logical. But, projects of designing a new hardware and developing a software for it can be combined into a Program.

Portfolio

This is a grouping of Programs and Projects. These are very large structures and they tend to link Programs (and Projects, consequently) from areas that are little connected but nevertheless have common joints. An example of a Portfolio is the construction of a new residential area in which, in addition to the construction of houses, it is necessary to (this list does not claim the status of complete, it just serves for a general understanding of the Portfolio):

• Provide water supply (Program), for which it is necessary to build a water receiver, pumps, mixers, dig up water reservoirs, build tanks and install pipelines (Projects);
• Provide electricity supply (Program), for which it is necessary to stretch high-voltage power transmission lines, build transformer substations, extend power communication lines to homes;
• To provide infrastructure (Program), it is necessary to build kindergarten, school, hospital, shops, public services buildings, roads, etc.;
• etc.

Schematically the Portfolio may look like this:

Project Management Office, PMO

The concept of a PMO includes a group of people who can perform one of the following roles:

• Train project management and guide Project Managers in the proper direction;
• Provides methodology, approaches and building blocks for project management;
• Assignment of project managers to various projects.

The PMO should also provide all Projects with everything needed (as defined in the planning) for its completion. Also, Budget or Time increases should be negotiated between key stakeholders, the project manager and members of the project management office.

In addition to the roles listed above, PMOs can perform the following functions:

• Rank projects according to their importance for the organization;
• Provide Project Managers with document templates, prescribe procedures and regulations for Project Management;
• Provide centralized communications between Projects;
• Participate in decisions on changes to the project;
• Participate in the decision to terminate the project in case of failure.

But for this, the organization in which the PMO exists needs to clearly define the role and responsibilities of the PMO not only in the organization, but also in each individual Project. If you consider the implementation of office project management in reality, it is not some additional department of the company, but exactly the group of professional project managers with a lot of experience. Of course, the PMO will only work with full management support.

Management by Objectives

This is the principle of management, when all actions of project team members are aimed at achieving the objectives of the project. The philosophy of this management can be expressed in three steps:

• Establish clear and achievable project goals;
• Carry out a periodic assessment of whether the objectives can be achieved;
• Constantly adjust the development vector of the project to match its goals.

What are the goals? Of course, the list of goals largely depends on each specific project and to realize these goals, PMI highlights the following requirements:

• The goals of the project should be clearly defined in the Project Charter;
• The project can be considered completed only when all the objectives of the project have been achieved;
• Project execution should be interrupted if it is clear that the goals will not be achieved;
• At the beginning of project execution, it is possible that the full Scope of the project will not be known. In this case, the Progressive Elaboration of the project enters into force;
• The Project Manager should keep the execution of the project within a certain framework;
• Risk management is mandatory because it reduces project Cost and increases project manageability;
• Project goals should be defined at the Initiation stage and disclosed at the Planning stage.

Constraints

As stated above, a Project is an activity carried out under constraints. Identify seven main constraints that affect the project:

• Scope
• Schedule
• Cost
• Quality
• Human Resources
• Risks
• Customers Satisfaction

All these influence (in one way or another) in every project. The task of the Project Manager is to manage these constraints and reduce their negative impacts and increase the positive affects on the project.

Stakeholders

The term Stakeholders refers to any person or organization that has an influence on, or is influenced by, a Project. The influence of the person concerned may or may not be strong, but in any case this influence should be taken into account by the Project Manager. Informal Stakeholders are divided into key and secondary - those with a large influence on the project (e.g., sponsors, management, customer, users of the result product, project team, etc.) and those with a small influence on the project (e.g., government agencies, equipment suppliers, outside observers, competitors, etc.). For the convenience of Stakeholders are combined into groups (that are essentially the Stakeholders) - so, for example, it does not make sense (or even impossible) to consider each person using the Internet as a single stakeholder, then they are combined into one Stakeholder named as «Internet user».

It is important to remember that the Project Manager should identify Stakeholders as soon as possible and the more precisely this will done, then higher chances of the project being implemented. Since the number of stakeholders is unique for each project, the methodology requires identifying as many as possible. Why? This is discussed in more details when considering the processes Determine Requirements and Stakeholders Identification/management/classic/stakeholders#ident.

Organizational Structure

Before considering the forms of organizations, it is worthy to note that PMI considers the suitability of a particular form for project activities. The forms are aligned in reverse order of convenience for classical project management:

• Functional - the most common form of organizations, but least conducive to classic project management. The activity of the functional organization is built on a single cyclical process (for example, factory), in which all management power belongs to the functional manager (senior workshop), and emerging projects do not play an essential role in the company’s activities, rather, they are subsidiary and secondary. The project manager has almost no power;

• Matrix - something between Functional and Projectized form of organization. Distinguished by three subtypes: Weak, Balanced and Strong matrix form. The essence of dividing is very simple - weak matrix is closer to functional form organization; strong to Projectized; and balanced - is at the middle of Strong and Weak forms;

Projectized is the most favorable form of organization for project management - all company activities are built around projects, therefore the project manager has great influence and power. Along with this, has a number of drawbacks and the most striking of them is that team members have to look for another job immediately after completion of the project.

Project Expeditor and Coordinator

Typically, such positions are only present on large Projects. The Project Coordinator is responsible for communications and other support tasks. The Coordinator has a higher status and can make decisions that are quite important to the project, as well as prepare and provide reports for management.

Product Lifecycle

First, let’s define the term “Product”, what is it? The Product is any result of the Project - the goal of the Project for which it is implemented. The concept of a Product also includes providing specific services, which are the results of the Project. In the methodology there is interchangeability of concepts result of Project and Product (and in practice we can ecounter with this interpretation, as well).

The life cycle of a Project result depends to a large extent on the nature of the Project and particular subject area. But usually they contains initial and final stages, which names may also depend on different conditions. The following is a common example of a 5-stage life cycle:

• Conception;
• Growth;
• Maturity;
• Decline;
• Withdrawal.

Project Lifecycle

Similarly to the Product Lifecycle, Project Lifecycle can vary depending on the subject area. The cycles of life, their stages and duration may not coincide on a time scale, but they are nevertheless connected.

Project Processes

This topic is covered in more details in the relevant article, but to understand the differences between Project and Product Life Cycles, a superficial description of the process approach will be very useful.

Let’s start with a diagram showing the Process Approach to project management:

, where

• I – Initiation;
• P – Planning;
• E – Execution;
• M&C – Monitoring and Control;
• C – Close.

Now let’s look at the interaction between processes within one stage of the Project Lifecycle:

1. After signing the Project Charter, initial information about the Project is used for more detailed planning in a group of Planning processes;
2. At the end of the Planning, the Project Team starts to execute the Project according to the plans;
3. In parallel with the execution of the Project, the Project Manager or Team Members should monitor the progress of the work and evaluate the effectiveness of the execution of the Project by comparing the actual status of the Project with the planned;
4. If during the Execution of the Project, no misses are found, the Project Team continues the execution of the Project;
5. Meanwhile, during the project Execution (regularly) there is a need to make Changes in the way of project Execution to adjust its vector of development, or when making any changes in accordance with new requirements by the Customer or Sponsor. But before making Changes directly, the Project Manager must assess the Change and replan the project. When Change enter into the force, the Project Plans should be updated and the Execution of the Project should continue in accordance with the changes;
6. If the Project has moved too far away from the original goals, then the Project Manager together with the chief management should conduct an analysis of whether it is worthy to continue the project;
7. Whatever the outcome (successful/unsuccessful) of the Project is, it should always be closed in a group of Closing processes, where the Project Manager and chief management have to do a lot of administrative work, in particular to evaluate the execution of the Project.

The Product Lifecycle may include several projects (and therefore several Project Lifecycles). Thus, for each stage of the Product Lifecycle, a separate project can be initiated. For example, for a mobile phone product there may be several stages, each of which will accommodate the sole project. Then the design of the mobile phone will be a separate project performed at the lifecycle stage of the design; the distribution of advertisement and stickers will be a separate project performed at the sales lifecycle stage; the delivery of goods and direct sales by dealers will be a project, in the sales lifecycle, etc.

Lessons Learned

Everything that happens on the Project must be recorded and documented. This contributes to the organization’s Knowledge Base, which can contain the resolution of difficult situations for subsequent projects of the organization. Suppose, the Project Manager has identified a defect in the produced products and after resolving the problem, he should put revealed cause of problem (as well as applied steps for problem resolution) into the Knowledge Base of the organization. Another Project Manager, when carrying out a similar project and encounter with the similar problem, he can look at previously accumulated knowledge and prevent such a situation, and if it does not succeed, then use the succesfull recipe for its resolution.

So what should be recorded in the [Lessons Learned]? There is no clear regulation - everything depends on the requirements of the company to maintain a knowledge base, but it is recommended to record the following:

• Sources of problems;
• Ways to resolve problems;
• Methodologies used;
• Analysis of the methodologies used;
• Project management quality analysis;
• Analysis of the Project Team (both individually and their collaborative work);
• Key Stakeholders;
• Project area management plans;
• Project performance measurements and its analysis;
  etc.

Regularly, the Lessons Learned Database is well structured and describe how it should be filled in. It is also worthy to note that the Knowledge Base can be fullfilled at any time, not necessarily at the end of the project.

Organizational Process Assets

In addition to the Enterprise Environmental Factors, Assets are one of the most common inputs to project management processes. When considering project management processes, as Organizational Process Assets, we will most often encounter the Lessons Learned, but the assets include all the assets of the organization, involved in the project and influencing its success. The following is a list of most entities that can be implied as assets:

• Organizational standards, policies and processes;
• Description of project management principles;
• Guidelines for carrying out the works and their evaluation;
• Templates;
• Communication requirements;
• Project completion guidance and requirements (see Closing Process Group);
• Project financial control procedures;
• Change management procedures (see Integrated Change Control Process);
• Risks;
• Lessons Learned;
  • Data from previous projects;
  • Historical information;
  • The knowledge base with previously encountered problems;
  • Final databases (Budgets/management/classic/cost#, Cost of Works/management/classic/cost#cow and conversions);
  • Basic knowledge of assessments (estimates of Risks, Cost, Deadlines/management/classic/time#dead, etc.).

Enterprise Environmental Factors

Any external or internal factors that influence the Project. External can include:

• State and international standards and requirements;
• Commercial database;
• Market information.

Internally:

• Organizational Structure;
• Infrastructure;
• Information about human resources of the company - skills, knowledge and other characteristics;
• Information on the understanding of the Stakeholders of the Project, both as a whole and in individual areas.

In addition, Enterprise Environmental Factors include the Project Management Information System (e.g., MS Project or Primavera).