New national standard in project management in Russia
By Sergei Ilin, PhD, FS Management Consultant, Russia.
Key words: project management, project organisation structure, national standards, CIS, emerging markets.
Introduction
Are you a professional in PMO, project / programme or portfolio management? Do you investigate or study national standards? Are you interested in emerging markets especially in Russia? Do you have business with local office in CIS and want to understand the cultural gap? Then my articles might be in the area of your professional interests.
To update worldwide professional societies with details of new Russian standard in a project management including some comments on possible future improvement is the main purpose of this article.
Out of many standards used by professional project managers worldwide, PMBoK, PRINCE-2, and ICB are discussed in this article (see table 1).
Table 1. PM international standards
|
|
Standard |
Year (1st/last edition) |
|
Europe |
IPMA ICB (International Competence Baseline) |
1998/2006 |
|
US |
PMI PMBoK (Project Management Body of Knowledge) |
1983(7?)/2008
|
|
UK |
OCG PRINCE-2 (PRoject In Controlled Environment) |
1989/2009
|
All standards created with purpose to increase the project success rate. In the article with investigation results intended to enhance PMBoK investigators write (Ghosh and others, 2012): “Different standards do so by putting emphasis on different competences. PMBoK emphasizes on repeatable processes, ICB stresses on technical, contextual and emotional competences, Scrum brings customer collaboration, quick turnaround time, PRINCE2 focuses on product of the project in a controlled environment, P2M devises innovation and alignment with project portfolio”.
The most popular standard widely used in big companies in Russia is a PMBoK. If one looks at other countries from the former USSR we find professional societies with IPMA, V-Modell, P2M, PRINCE-2 and other standards adapted to the needs of companies also. Nevertheless all these standards are not official and this was the reason why new Russian standard was developed and published this year. The development process was initiated in 2008 by a company “PM Expert” and a holding “Proektnaya PRAKTIKA” who established a non profit organisation “Centre of project management standardisation”. Russian professionals including those having international PM certifications participated in development of new standards.
The quote from a participant of the development group gives us some background in understanding the standards we discuss: “First of all, this standard is brief and short. Developers agreed not to develop a Russian version of American standard PMBoK (Project Management Body of Knowledge) in principle. Nevertheless the team initially went in this direction. But discussions became long and there was another decision that the standard will contain only what must be in project activities. The second feature – universalism meaning that standard’s requirements will expand on management of all IT projects and could be applied to projects implemented as by persons and by companies and also by third parties, external or internal ones. The third feature – orientation to results meaning that the standard determines only outcomes of project management processes but does not contain requirements to realisation tools and techniques of these processes” (O.Pavlova, 2012)
Few comments from opponents to this publication are very interesting as well: “By the way I have not seen principle difference between new GOST and Russian edition of PMBoK”. “This GOST demonstrates immaturity of project community in Russia. As we know they developed this first edition of the standard”. “Who did teach the developers to create scheme?”
Well, these are just opinions. Let’s consider what is inside of the discussed standard. Other two standards (“Project management. Requirements for program management”, 2011 and “Project management. Requirements for projects portfolio management”, 2011) will be discussed in different articles which will follow after this publication.
Project management standard overview
The national standard “GOST R 54869―2011” (Project management. Requirements for project management, 2011) is 8 pages long plus one appendix.
An introduction to the document says: “This standard sets requirements for project management from start to its completion, at the same time the subject of standardization is outcomes of project management processes. The standard does not contain requirements which can be considered mandatory for defined types of projects only, requirements to methods of project management processes realisation, and requirements to pre-project and post-project activities.”
A project management organization section describes the main roles in project management organization:
“• Project Sponsor (Customer) – a person or a legal body owing project results
• Project Curator – a person responsible for supporting project financially, administratively, etc. and providing resources
• Project Manager – person managing a project and responsible for project results
• Project Team – persons, groups or organizations united to temporary organizational structure for completing project work”
Also it refers to the appendix with the following diagram .
Pic 1 GOST: Main project management terms and their interlinks
The main section Project management describes Project management areas and sequence of processes including initiation, planning, and execution, control, and closure processes. The translated text of this section is in Appendix 1.
Discussion
This section discusses the main differences among PMBoK, PRINCE-2 and ICB. All these points can be used by the working group working to implrove the the Standard and increase a project success rate.
Project Organizational Structure
The Russian project management standard does not refer to the project environment. For example, 4th edition of PMBoK describes the main concepts of portfolio management and programme management from the beginning (PMI, 2008), and PRINCE-2 refers by referring to a program structure (OGC, 2009).
It is easier to understand the organizational structure of a project in the Russian standard by changing the design and presenting the roles in a hierarchical view as below (with removed few links to simplify the diagram)
Pic 2 GOST: Main project management terms and their interlinks - Design changed
As you can see, the Russian standard does not consider steering committee as a mandatory governance body for project management.
In comparison, PRINCE-2 (picture below) recommends more comprehensive project management structure with additional roles (OCG, 2009):
• Steering Committee (Project Board) with consideration of three roles:
• Senior User
• Senior Supplier
• Executive (the analogue of Curator with some elements of Sponsor role in the Russian standard)
• Project Assurance (PMO can play this role depending on the maturity of the organizational unit; Project Assurance is independent from the Project Manager according to PRINCE-2)
• Project Support.
• Change Authority (appeared in recent PRINCE2 edition).
Pic 3 PRINCE2 Project organisation structure
Roles: Project Manager (PM)
The discussed standards explain PM’s competencies or at least basic duties he or she needs to perform. The Russian document does not refer to manager’s competencies directly. It is a question whether to include competencies or not to the standard methodologically, for example technical ICB competencies can be mapped to processes description so competencies can be explained in terms of ability to run processes. Nevertheless it’s highlighted that ICB 15 behavioral competences enhance PMBoK and process oriented standards (Ghosh S, and others, 2012):
“• Leadership
• Engage & Motivate
• Self-control
• Assertiveness
• Relaxation
• Openness
• Creativity
• Results Orientation
• Efficiency
• Consultation
• Negotiation
• Reliability
• Values Appreciation
• Ethics”
The 4th edition of PMBoK also refers to 8 interpersonal skills (PMI, 2009, p.417-421):
“• Leadership
• Team building
• Motivation
• Communication
• Influencing
• Decision making
• Political and cultural awareness
• Negotiation”
The Russian standard does not have any requirement to skills or competencies of a successful project manager.
PMBoK Knowledge areas and processes
Main processes in the Russian standard correlates with PMBoK’s process groups: “5.1 … Project management includes initiation, planning, execution, control, and closure processes”. Also PMBoK has so called «knowledge areas» (PMI, 2008) which are named “functional areas” in the Russian project management standard (read clause 5.1 in the attachment). Here I’d like to mention the following differences between the standards.
The Russian standard does not have quality planning process among other planning processes (see clause 5.3 of the attachment) and also does not refer directly to the quality requirements in the standard.
The Russian standard does not have Integration management functional area, PMBoK does have.
The Russian standard introduces Change Management planning (in terms of ITIL change management process)
Table 2. Comparison PMBoK and Russian GOST
|
PMBoK “knowledge areas” |
Russian GOST “functional areas” |
|
4. Project Integration Management |
- |
|
5. Project Scope Management |
5.3.1. Project scope planning process |
|
6. Project Time Management |
5.3.2. Project schedule development process |
|
7. Project Cost Management |
5.3.3. Project budget planning process |
|
8. Project Quality Managemen |
- |
|
9. Project Human Resource Management |
5.3.4. Project HR planning process |
|
10. Project Communications Management |
5.3.7. Project communications planning process |
|
11. Project Risk Management |
5.3.6. Project risk reaction planning process |
|
12. Project Procurement Management |
5.3.5. Project procurement planning process |
|
- |
5.3.8. Project change management planning process |
PWS vs WBS or tasks vs results (benefits)
The working group aimed to focus reader’s attention mainly to the results by listing outputs of the processes only and documenting the results of a project (Pavlova O., 2012). Nevertheless PMBoK is a process oriented project standard and GOST is derived from PMBoK having the same logic. Process (task) oriented way of thinking is different from result oriented way of thinking. PRINCE-2 is considered as business case driven standard. It solves the goal to achieve results in more elegant way in my opinion. First, PRINCE considers Product Breakdown Structure (result oriented) in contrast with Work Breakdown Structure (task oriented). Then all work packages should be completed within boundaries of stages. “Control is exercised by authorizing and by dividing the project into manageable stages and milestones. PMBoK does not cover it.” Gate reviews are very often used for this aim. PMI’s “The Standard for Program Management” (PMI, 2008) also refers to the programme governance through Phase-Gate Review. “Technical stages are overcoming technical tasks and challenges while management stages are commitments to stakeholders. PMBoK does not make this distinction. Stages and phases are used interchangeably in PRINCE2.” (Ghosh S., 2012).
Conclusions
The first edition of the Russian standard in project management is derived from PMI PMBoK conceptually. It briefs 5 main processes with reference to outputs of 8 sub-processes having similar to PMBoK knowledge areas titles in the planning process except integration management and quality management, these areas do not have special requirements in the Russian standard.
At the same time other standards like ICB, PRINCE-2, or P2M can bring benefits to Russian professional community by applying best practises based on knowledge of cultural specific in CIS. Some of the recommended improvement can include
• Considering a Steering Committee as the mandatory governance body in a project organization structure;
• Specifying additional roles as Senior User, Senior Supplier, Project Assurance, Project Office, and Change Authority;
• Listing project managers’ competencies;
• Having more specific statements aiming on the result achievements.
My other articles are devoted to new Russian program management standard and change management issues and cultural gaps in CIS and how the recommendations from this article were used in projects/programs for recovering them from troubles and achieving successfully the objectives of business.
References
Ghosh S.; Forrest D.; DiNetta T.; Wolfe B.; Lambert D; 2012, “Enhance PMBOK® by Comparing it with P2M, ICB, PRINCE2, APM and Scrum Project Management Standards”. January 2012, Vol. XIV, Issue I. “PM World Today”.
Office of Government Commerce (OGC), 2009, “Managing successful projects with PRINCE-2”.
Pavlova O., 2012, “В России появился свой стандарт по управлению проектами”. PCWeek.ru, 20 Feb 2012. http://www.pcweek.ru/idea/article/detail.php?ID=137054
“Project management. Requirements for project management”, 2011. GOST R 54869―2011. Translated from «ГОСТ Р 54869―2011: Проектный менеджмент. ТРЕБОВАНИЯ К УПРАВЛЕНИЮ ПРОЕКТОМ.»
“Project management. Requirements for program management”, 2011. GOST R 54871―2011. Translated from «ГОСТ Р 54871―2011: Проектный менеджмент. ТРЕБОВАНИЯ К УПРАВЛЕНИЮ ПРОГРАММОЙ.»
“Project management. Requirements for projects portfolio management”, 2011. GOST R 54870―2011. Translated from «ГОСТ Р 54870―2011: Проектный менеджмент. ТРЕБОВАНИЯ К УПРАВЛЕНИЮ ПОРТФЕЛЕМ ПРОЕКТОВ.»
Project management Institute (PMI), 2008, “A Guide To The Project Management Body Of Knowledge” (PMBOK), 4th edition.
Project management Institute (PMI), 2008, “The Standard for Program Management”.
Appendix 1. Translation of main statements of the Russian Project management standard
The section links refers to another standard used in this document: “GOST R ISO 9000 — 2008 Quality management systems. Fundamentals and vocabulary.”
Terms and definitions section defines terms “project archive”, “project baseline”, “project budget”, “tolerance” (or “allowance” depending on translation and standard used for translation), “stakeholders”, “project change”, “deadline”, “corrective action”, “restriction”, “preventive action”, “product” or “project result”, “project”, “process”, “project activity”, “calendar plan” or “schedule”, “risk”, “project management”.
The main statements of the standard are below:
“5 Project management
5.1 Project management areas and sequence of project management processes
Project management includes initiation, planning, execution, control, and closure processes.
Inside project management processes activities are performed from the following functional areas:
- scope project management ;
- time project management;
- cost project management ;
- risks project management ;
- HR project management;
- stakeholders project management;
- procurement project management;
- quality project management;
- communications project management;
- integration project management.
Sequence of project management processes defined by conditions of concrete project, at the same time:
- project must start with initiation process;
- project must finish with closure process;
- execution and control processes start not earlier than planning.
5.2 Project initiation process
Aim of the process: formal project start.
Output of the process are determined and documented by the following project characteristics:
- Project name;
- Reasons for project initiation;
- Goals and products of the project;
- Project initiation date;
- Project sponsor;
- Project manager;
- Project curator.
5.3 Project planning processes
5.3.1 Project scope planning process
Aim of the process: to define project requirements and work breakdown structure.
Output of the process:
а) Requirements for the project from Sponsor and other stakeholders, including regulations requirements are determined, feasibility analysed, requirements agreed with sponsor and documented;
б) key product data defined, agreed and documented:
1) purpose, properties and characteristics of the product;
2) criteria and acceptance methods of the product and it’s components;
3) assumptions and exceptions regarding product;
в) project activities, assumptions and exceptions regarding product are defined, agreed and documented.
5.3.2 Project schedule development process
Aim of the process: start and end of project activities dates, milestones dates and other dates are determined.
Output of the process:
- interdependencies between project activities are defined;
- project activities durations are estimated;
- required project resource plan is defined and approved;
- project schedule is defined and documented;
- project base calendar plan is approved.
5.3.3 Project budget planning process
Aim of the process: to determine the order and amounts needed to provide the project financial resources.
Output of the process:
- project budget structure allowing to control expenses during project realisation is defined and documented;
- planned costs of all project resources (HR and materials) including all known restrictions for their use is defined;
- project activities cost is defined;
- project base budget is approved;
- the order for budgeting project is defined and documented.
5.3.4 Project HR planning process
Aim of the process: to determine the order for providing HR resources.
Output of the process:
- roles of project participants, their functions and authorities are determined and documented;
- project team, team members’ qualifications and work conditions are determined;
- key team members are determined by persons.
5.3.5 Project procurement planning process
Aim of the process: to determine procurement rules and volume of products and services purchased from third parties.
Output of the process:
а) analysis of procurement requirements for products and services needed for achieving project goals is done;
б) in cases when a decision about procurement of products and/or services for project is made based on the result of analysis, then:
1) requirements for purchased products and services including limitations on cost and dates for delivery are determined;
2) acceptance criteria for purchased products/services are determined;
3) vendor selection and evaluation activities based on defined criteria are planned.
5.3.6 Project risk reaction planning process
Aim of the process: to determine main project risks and the procedure to work with them.
Output of the process:
- project risks are identified and documented;
- all identified risks are evaluated and ranked based on probability and impact to project results;
- activities for changing probability and impact of most important risks are elaborated, and also response plans in case of realisation of those risks is created;
- all results of work on preventive actions for risks are taken into account and included in linked plans.
5.3.7 Project communications planning process
Aim of the process: to determine communication between project team members and project stakeholders.
Output of the process:
- all participants of communications and their needs in information are defined;
- all methods and information channels are defined;
- project document development, alignment, approve and distribution procedures are determined;
- place and rules for information are defined.
5.3.8 Project change management planning process
Aim of the process: to determine rules for change management.
Output of the process:
а) change management process defined and documented,
specifically:
1) identifying changes;
2) alignment and approve of changes;
3) establishment of document and products version control;
4) sharing information about changes with stakeholders.
5.4 Project execution process
Aim of the process: to execute of the project according to developed plans.
Output of the process:
- planned work completed;
- project products elaborated;
- changes are done according to agreed project;
- identified corrective and preventive actions are done;
- project management documents are actual.
5.5 Project control process
Aim of the process: to check an accordance of project processes and products to defined requirements.
Output of the process:
- regular project audits results are documented, particularly, and discrepancy between plans and facts are analysed to define the reasons;
- estimation of conformity of the product to it’s requirements is done;
- corrective and preventive actions are formed based on the audit results;
- project work reports correspond to approved project reporting rules.
5.6 Project closure process
Aim of the process: to formally close the project.
Output of the process:
- acceptance of the project product is done and documented by Customer;
- all project contracts are closed (if any);
- project finish is documented;
- project archive is created;
- project team and stakeholders are informed about the end of the project.
6 Requirements to project management documents
The form, title and content of documents can be different in projects and this depends on specific project, contract agreements or organisation requirements where the project is to be implemented.
The one must manage documents in accordance with the following requirements:
- documents (i.e. templates) must be approved before using;
- it’s necessary to provide analysis of documents actuality and regular updates when required;
- it’s necessary to provide current versions of documents at the places where they are applied to;
- it’s necessary to provide documents archiving during defined periods and ability to restore them;
- it’s necessary to provide documents confidentiality according to requirements of the customer and other stakeholders;
- it’s necessary to prevent using old documents and appropriate identification of old documents remaining for purpose.”