Reading time: 3 minutes In moments of crises, unexpected changes and sincere ...
Project management- in accordance with P2M - a combination of science and art, which are used in the professional areas of the project to create a project product that would satisfy the mission of the project, by organizing a reliable project team, effectively combining technical and management methods, creates the most value and demonstrates effective work results ...
The products of the project can be the products of the enterprise (the results of scientific and marketing research, design and engineering and technological documentation for a new product developed for the customer) and the solution of various internal production problems (improving the quality of products and the efficiency of labor organization, optimizing financial flows, etc.). ).
Project management is part of the enterprise management system.
History
Modern project management methods are based on work structuring and network planning techniques developed in the late 1950s in the United States.
The classic form of Triple Limitation
- Assumption of unlimited resources, only the deadline and quality are critical. PERT Method, Critical Path Method,
- The assumption about the criticality of quality, while the requirements for time and resources are flexible enough (quality here means the completeness of satisfying needs, both known and unknown in advance, often created by the release of a new product). Agile development methodology
- Assumption of invariability of requirements, low risks, tight deadline. Classic PMBOK methods, heavily based on the waterfall model
- Assumption of high project risks. Method Innovative projects (startups)
- Options for neutral (balanced) approaches:
- Emphasis on the interaction of performers. PRINCE2 method
- Emphasis on the interaction of processes. Process-based management method
Roles in the project
In many cases, the project identifies the roles of the customer, the executor (and sometimes the investor or sponsor). Such roles are almost always available for external projects. For internal projects, such a division of roles is also desirable in order to increase efficiency in the division of labor and to eliminate conflicts of interest in the acceptance of results, and to define areas of responsibility.
The customer determines the purpose and limitations of the project and its financing. The contractor carries out the project in accordance with the approved plan.
The customer is responsible for setting goals and the usefulness of the result for the consumer. The project committee is responsible for centralizing the client's functions and managing the project portfolio. In construction organizations, a special service of a single customer is allocated for this.
In the case of a clear division of roles, the customer-executor, the goal of project management is to stabilize the work and minimize deviations from the plan approved by the customer.
If the customer and the contractor are in different organizations, then a contract is drawn up for the execution of the project. If the customer's requirements change, an additional agreement to the contract may be signed within the limits of the total budget of the project program specified in the main contract.
To align the project with the interests of the business, the roles of the curator (usually from the executor) and sometimes the sponsor (curator from the client), who have the greatest awareness of the business interests, are often introduced, have the right to approve key changes in the project.
Project management purpose and project success
The success of the project is assessed in different ways in different methods. Success can be assessed in different ways by different project participants.
Success rating groups:
- Contract-oriented, such as traditional methodologies, including PMBOK: "The project is successful if it is completed according to the approved criteria: volume, time, quality"... That is, the project is successful if the contract between the Customer and the Contractor is executed and closed (regardless of whether it was a legal document in the case of external projects or was determined somehow differently in the case of internal projects). At the same time, the assessment of success is the same for both the customer and the performer.
- Customer-specific, e.g. flexible SCRUM methodologies, partly program management focused on long-term interaction rather than one project / contract: "The project is successful if the customer is satisfied"... Here the emphasis is placed on the continuation of cooperation between the Contractor and the Customer in the framework of subsequent projects and other interactions, or the project can be considered as a program of several small projects. Evaluation of success is considered mainly from the point of view of the customer.
- Balanced, eg PRINCE2: "The project is successful when it is balanced in at least three categories - business, user orientation and technological maturity." It focuses on the financial success of the project, user satisfaction and development (indirect benefits for the performer himself). Success scores can differ from a business, user, and performer perspective. Such assessment techniques are more often used for internal projects when the customer and the contractor are in the same organization.
So, for example, a project that met the agreed time and costs, but did not pay off according to the results of the project (the costs are high, the result is irrelevant to the end of the project, the customer cannot use the result, etc.) will be successful according to the traditional methodology, but not successful according to customer-oriented methodology. Responsibility for the failure of such a project is borne by the customer and, in some cases, the project office or customer service.
In general, the goal of project management can be defined as follows:
"The goal of project (s) management is to achieve predetermined goals with predetermined limitations and appropriate use of opportunities, response to risks."
Even with the achievement of the goals and the feasibility of changes, the project may not meet the expectations of stakeholders. In projects with a high level of change, expectation management is required.
Corporate project management system
In order to solve problems related to conflicts of goals, priorities, deadlines, assignments, resources and reporting in the context of complex work (projects), a corporate project management system is created, which includes organizational changes in the company (project management office), methodological base and information system. project management.
Project management procedures
International Project Management Standard ISO 21500: 2012
In September 2012, Russia, the United States and the EU countries at the state level through the International Standard Organization ISO introduced the ISO 21500 standard, which was built on the basis of the PMBOK model. The adoption of the ISO 21500 standard was accompanied by a de facto transfer of the priority of standardization from PMI to ISO.
In accordance with the civil legislation of most countries of the European Union, as well as Russia, all other standards in Europe are subordinate to ISO 21500: 2012 and in case of any discrepancy with the official standard, the subordinate standards in these differences are "null and void". In Russia, this rule is enshrined in Article 7 of the Civil Code of the Russian Federation.
- Defining project requirements
- Setting clear and achievable goals
- Balancing competing demands for quality, capability, time and cost
- Adaptation of specifications, plans and approaches to the needs and problems of different stakeholders (stakeholders)
IPMA
- System View of IPMA Project Management
Project management procedures according to the PRINCE2 methodology
- Project start (SU).
- Project launch (IP).
- Project Planning (PL).
- Project management (DP).
- Stage control (CS).
- Stage boundary control (SB).
- Product Manufacturing Management (MP).
- Completion of the project (CP).
Other procedures (team management, contracts, etc.) are taken “outside the scope” of the methodology and are called the project manager's toolkit. In addition, the methodology considers the “components”, which consist of the Business Case, organization, planning, risk management, quality management, configuration management, control and change management.
Project management procedures according to MSF methodology
Microsoft Solutions Framework (MSF) was developed by Microsoft Corporation as a methodology for IT projects. MSF presents each phase of the project as:
- Envisioning
- Planning
- Developing
- Stabilizing
- Deploying
Project management plan
The management plan is the main document from which any project should start. The plan is adjusted throughout the project.
The Project Management Plan should reflect:
- Content and boundaries of the project
- Key project milestones
- Planned project budget
- Assumptions and Limitations
- Requirements and standards
Project Management Standards
International standards for project management (management):
National project management standards:
- GOST R 54869-2011 “Project Management. Requirements for project management "(Russia)
- GOST R 54870-2011 “Project Management. Requirements for project portfolio management "(Russia)
- GOST R 54871-2011 “Project Management. Requirements for program management "(Russia)
- NASA Project Management (USA)
- BSI BS 6079 (UK)
- APM Body of Knowledge (UK)
- DIN 69901 (Germany)
- Hermes method (Switzerland)
- CAN / CSA-ISO 10006-98 (Canada)
- South African NQF4 (South Africa)
- CEPM (India)
- PROMAT (South Korea)
Standards with extended geography of application:
- PRINCE2 (PRojects IN a Controlled Environment)
- ISEB Project Management Syllabus
- Oracle Application Implementation Method (AIM)
Project Manager Competency Assessment Standards:
- ICB IPMA Competence Baseline (IPMA)
- NTK (National Requirements for the Competence of Specialists) (Project Management Association "SOVNET", Russia)
- NCB UA (National Competence Baseline, Version 3.0) (Ukraine)
Project management software
- products focused on service automation:
- ARTA Software - ARTA Synergy system
- Epicor Software
- project and task management systems:
- Bontq is a project management and bug tracking system.
- Cerebro is an audiovisual project management system.
- Easy Projects .NET is a project management system written in .NET.
- eGroupWare is free project management software.
- GanttProject is a small free program with Gantt chart and resources. [the significance of the fact?]
- Kommandcore is a paid multi-user web project management service designed primarily for project managers, based on an agile development methodology.
- OpenProj is a free, open source alternative to Microsoft Project.
- Clarizen - cloud-based project, personnel, budget management system
- PayDox is a system for managing documents, tasks and teamwork of employees.
- Project Kaiser is a web-based project and task management system with wiki support and advanced user interaction.
- ProjectMate - Russian PSA-system for automation of professional activities. In addition to the project management module, it has a lot of functions that are in demand in companies in the field of consulting services - from time tracking to invoicing (billing).
- Redmine is a free multi-user web service focused on the specifics of IT projects and developers.
- TeamLab is a system for project, document management and collaboration.
- TrackStudio Enterprise is a task management system. There is an export to MS Project.
- Trac is a project management and software bug tracking tool.
- Web2Project is an open source free web application for project management (the project is based on the dotProject code).
Project management methodologies
PMI methodology, formulated as a PMBOK standard, is based on the concept of project management through a group of standard processes. However, the latest version of the PMBOK standard reflects a significant correction of the methodology towards interactive methods.
IW URM methodology(Unique Reliable Method), was developed and perfected so that success is guaranteed in any project - the client's goals are achieved on time, within a certain budget and with the required quality. For the implementation of different types of projects, a set of different procedures, documents and technologies are used that are most suitable for a particular type of project.
TenStep Project Management Process helps project managers successfully manage projects of all kinds. TenStep offers a step-by-step approach, starting with the simplest things and ending with as sophisticated techniques as required for a specific project, including document templates.
P2M methodology is based on a focus not on the product or processes, but on the improvement of the organization as a result of the implementation of projects. In other words, the methodology describes how to use the experience gained from the implementation of projects for the development of the company.
Literature
- Stanley E. Portney. Project Management For Dummies = Project Management For Dummies. - M .: "Dialectics", 2006. - S. 368. - ISBN 0-7645-5283-X
- Russell D. Archibald. Managing High Technology Programs and Projects = Managing High Technology Programs and Projects. - M .: "IT Academy", 2004. - P. 472. - ISBN 5-98463-002-3
- Newell Michael W. Project management for professionals. Certification Exam Preparation Guide. - "KUDITZ-PRESS", 2008. - S. 416. - ISBN 978-5-91136-009-2
- Tom DeMarco. Deadline. A novel about project management. - "VERTEX" "M", 2006. - S. 143. - ISBN 5-9626-0132-7
- Ashmanov Igor Stanislavovich Life inside the bubble. - M .: Mann, Ivanov and Ferber, 2008 .-- S. 208 .-- ISBN 978-5-902862-79-6
- Kim Heldman. Professional project management. - "Binomial" "Moscow", 2005. - S. 517. - ISBN 5-94774-234-9
- Lapygin Yu. N. Project management: from planning to performance evaluation. - Omega-L "Moscow", 2008. - S. 252. - ISBN 978-5-370-00985-3
Zarenkov V.A.Project management. SPb., 2010.
Project management standards of companies in terms of methodology usually have a basis determined by documents of a general nature, which are called framework documents. These documents include the Project Management Body of Knowledge of the American Project Management Institute, recognized by many de facto international standards, and the 1BO 10006: 1997 standard, the meaning and content of which is specializations and detailing.
Specialization - the inclusion in the company's standard of those provisions that are relevant to project activities. At the same time, the company's standard must contain a description and classification of the company's projects. Organizational structures and project personnel are also subject to specialization. The company standard can not only fix standard project roles, but also define the structure and principles of forming project management bodies. For all permanent divisions, in one way or another related to the execution of projects, the principles of their participation in projects should be determined - the types of work performed, the procedure for allocating and recalling personnel, the forms and amounts of remuneration received. The subject of specialization is and project management processes. We represent the total set of possible processes in the form of a three-dimensional space shown in Fig. 4.23. The coordinate axes are those measurements that are mentioned in the framework standards; others may be suggested, for example, management levels, calendar periods. Each point of this space represents an elementary management process, for example, “risk planning at the stage of system implementation”.
The selected elementary processes form project management procedures that can be built according to the axial principle (here we mean the abscissa, ordinate and applicate, indicated in Fig. 4.23). The description of these procedures constitutes the bulk of the standard, i.e. under the company standard a set of documents is understood that prescribes how, in what sequence, in what time frame, with the use of what templates it is necessary to perform actions in the process of project management.
The number of these documents depends on the level of detail of the standard and can be quite large. The subject of the description in the standard can also be typical situations typical for the company's projects, and recommendations for responding to these situations, i.e. a kind of solution tables, something like a list of possible malfunctions and recommendations for their elimination.
Classification of projects as the first stage in creating a standard
The key point in creating a project management standard is to understand what projects are being carried out in the company, what are their differences, what is in common between them. These issues are related to project management practices and are reflected in the company standard.
The document with which any project should begin is a project management plan that lays down the project management methods recommended by the company for this type of project.
Project life cycle stages
Time, Cost Kyaestvo | Risks Fersonal Communications Contracts Changes
F Control functions
2
I si іа їх
Initialization) Scheduling Execution Control Closing
Control phases
Rice. 4.23.Control process space
Source: Tovb A.S. Tsipes G.L. Enterprise-level project management standard // Director of Information Services. 2002. No. 1-6.
The project management plan reflects:
- the content and boundaries of the project - the goals and objectives of the project, the main results, criteria for assessing the fact that the work or part of it has been completed;
- project milestones - the main project events and a plan to achieve them, possibly using a work breakdown structure;
- the planned budget of the project;
- assumptions and limitations - the preconditions on the basis of which the estimates of the timing, labor intensity and cost of project work were made, including a description of the initial risks;
- requirements and standards - a list of normative and regulatory documents or their individual provisions that should be observed in the course of the project;
- approaches to the implementation of the project - the concept of the proposed solution (several alternative options are possible), development methods and basic information technologies;
- organizational structure - responsibility and order of interaction between participants, names and responsibilities of key figures in the project;
- project documentation management - structure, storage environment and procedure for creating and maintaining a repository of project documents, a list of document templates;
- deviation management - procedures for dealing with risks, with emerging problems and changes in the forms of the corresponding project documents;
- quality assurance - a list and regulations for carrying out activities aimed at ensuring the quality of both the results of the project (product) and the processes of project management and work performance;
- control and reporting - regulations for carrying out activities to analyze the state of the project, the corresponding reporting forms. The advantages of standard templates are obvious - savings on consultants, unification of approaches, reduction of time for preparing project documentation. However, the creation of templates is quite laborious, their presence will constrain the initiative and independence of the project manager. To determine the required number of project management plan templates, it is necessary to build a classification of projects carried out in the company.
Classification by subject area and by product within these areas allows you to specialize sections: Content and Boundaries, Key Milestones, Requirements and Standards. This classification can be built on a hierarchical basis, for example, information technology - system integration projects - the creation of integrated project management systems.
Classification by the scale of the project allows you to specialize sections: "Organizational structure", "Deviation management", "Quality assurance". Various grounds can be used to construct this classification - territorial dispersion or project cost.
Classification by form of payment and accounting of work allows you to specialize: "Control and reporting", "Project documentation management" on the basis of such contract forms as "Time and materials" and "Fixed price". Thus, we can talk, for example, about the template “Project management plan for creating a concept (product) of an information system (subject area) worth over 100 thousand dollars, (scale) with a contract in the form of“ time and materials ”(form of payment and accounting works) ", as a macro template obtained by a simple assembly from several smaller (micro) templates of individual sections of the plan.
Classification of projects by complexity (complexity). According to this classification, projects are divided into regular business projects, standard system integration projects, and complex system integration projects. Moreover, it is this classification that is decisive for the structure and content of the project management plan. At the same time, other classifications retain their significance for the formation of individual sections of the plan.
A project management plan containing a documented concept of the project agreed by all participants is a fundamental document, a fulcrum for all subsequent development of the project (Table 4.18).
Table 4.18
Specialized micro-template "Content and boundaries of the project for creating the IT infrastructure of a bank branch"
|
Paragraph micro |
bank branch |
|
|
Project justification |
Describes the main characteristics of the product and their relationship with business necessity or other incentives |
All branches must have a unified, reliable, flexible and scalable IT infrastructure based on a platform that allows application software to be used as the primary means of processing business transactions |
|
Project product |
Main product features and their relationship to business necessity |
Deliver, install and configure equipment and system software to the newly created branch of the bank, which forms the basis for the subsequent implementation of the banking information system |
|
Project deliverables |
Provides a list of results (subproducts), the achievement (complete and successful creation) of which means the completion of the project |
System software specifications and configuration. Room requirements for equipment installation. List of equipment and software. Technical solution plan. Master copies of system software installation and configuration. Equipment and system software delivered to a bank branch, installed and prepared for the installation of a banking information system |
|
Project objectives 1 |
Description of quantitative criteria that must be met for a project to be considered a success |
The delivery time for hardware and software to Moscow should not exceed XX days. The period for setting up equipment and software in Moscow should not exceed CU days. The period of transportation of equipment and software to a bank branch should not exceed Bb days. The period of installation and adjustment of equipment and software at the branch should not exceed UU days |
Comparing the contents of the sections "Project product" and "Project results" given in the example, you will notice that the project results are the elements of the project product decomposition. That is why, when forming a plan, work breakdown structure (WBS - Work Breakdown Structure) is often used, and many leading companies include standard WBS in their methodologies and standards, both explicitly (Andersen Consulting) and implicitly (IBM).
Work breakdown structure
At the initialization stage of the project, the project manager must answer a number of questions: what needs to be done (define the project products); how to do it (determine the technological stages of the project); who will do it (identify performers, co-performers, subcontractors); who will pay for the work and in what form (determine which contracts will be signed and with whom).
For example, if the work of a project is performed in the interests of various customers and is financed by various investors (Fig. 4.24), the decomposition can be performed either on the basis of the substantive attribute of assigning the work to projects, or on the formal basis of referring the work to financing agreements.
Functional
customer
|
Project P1 |
Project P2 |
PP project |
|
Investor
Agreement D1
Performers
- ---- Content decomposition
- -Decomposition on a formal basis (financial flows)
Rice. 4.24. Decomposition of works on various grounds Source:
Another case is the fixation of the participation of subcontractors in the structure of works. Then, for the stage of the project schedule, groups of work are formally allocated, performed by the main performer (contractor) and other performers (subcontractors). It is advisable to use such a decomposition if subcontractors are assigned large logically interconnected blocks of work that are relatively independent of other project activities.
Therefore, the first thing that needs to be reflected in a custom WBS template is what alternative views of the work breakdown structure should be supported in the project. If decomposition is required on several different grounds, the main thing should be indicated. To support the remaining views, appropriate classifications should be defined, described as characteristics of detailed works. As such features can be used: project code, contract code, subcontractor code.
Project management plan and framework standards
In most cases, the framework standard provides only a conceptual framework and general methodological principles. On the basis of the framework methodology, a corporate methodology should be created, in which the main provisions, requirements, principles and practices of project management are concretized and systematized in relation to project management in a given company based on an analysis of the specific specifics of the projects being executed.
This corporate methodology and specialized document templates form the basis of the company's project management standard. And the process of creating a standard resembles a spiral, at each new stage of which methods become more specialized, and templates - more and more detailed.
Design deviations. Risks, problems, changes
When planning a project, we assume that not everything will turn out exactly as planned. The resulting discrepancies between the initial agreed and fixed idea of the project and what is actually obtained are called deviations. At the same time, another term is adopted in the English-language literature - "exceptions", which means not only the discrepancy between the actual and planned results, but also the reasons for these discrepancies, as well as methods and technologies that allow you to cope with such situations with minimal losses. It is this broader interpretation that we will keep in mind in what follows when speaking about deviations. The traditional areas of project management related to variance are risk, challenge, and change.
Deviation management scenarios. Deviation management basically boils down to dealing with adversity, which in general can involve three stages:
- 1) Management of risks. The troubles have not yet come, but there is the possibility of unwanted and unplanned events occurring that can lead to the fact that the goals of the project will not be achieved. The purpose of this stage- prevent troubles before they occur;
- 2) problem management. Troubles have come and it is necessary to find out their origin, the degree of influence on the project, ways to overcome it. The purpose of this stage is ensure the project is able to go as planned;
- 3) change management. The troubles turned out to be serious, and it was not possible to cope with them without prejudice to the project. The purpose of this phase(what financiers call "fixing losses") - modification of previously agreed products and services, deadlines and cost of work, management and technological processes.
Project events associated with deviations can develop according to various scenarios, some of which are shown in Fig. 4.25. The first scenario corresponds to the full cycle of deviation management, in which a risk was identified during project planning, but work with it did not lead to the desired result. The problem that arose as a result of the occurrence of a risk event was also not successfully resolved, and all this as a result led to the need to amend the project plan. For comparison, consider the second scenario, in which changes in the project are implemented without waiting for problems to arise.
Rice. 4.25.
Source: Tovb A.S. Tsipes G.L. Decree. Op.
This is a rather important decision. Situations where such decisions are justified can be described in the standard indicating specific risk categories and quantitative risk assessments in which this scenario should be implemented.
Of particular interest from the point of view of variance analysis are the fourth and fifth scenarios corresponding to the occurrence of problems not accounted for as risks. The reason for this may be, for example, an atypical situation or simply a “loss” of risk as a result of a lack of qualifications. The analysis of the causes and severity of the consequences may result in a decision that for certain categories of projects it is generally not advisable for the company to deeply engage in risk management, but rather simply solve problems as they arise. While for other categories of the project, on the contrary, it is necessary to sharply strengthen the work with risks.
Management of risks. The simplest, and at the same time necessary, that should be reflected in the standard is the formal side of risk management, namely:
- procedures governing the main stages of working with risks - identification of risks, monitoring and analysis of risks, development, planning and implementation of measures to counter risks;
- templates of documents reflecting the process of working with risks - risk card, project risk log.
From all the variety of risk management methods for the standard, those that are adequate to the projects in which they will be applied (the cost of implementing management procedures) should be selected. Thus, in the analysis of risks, a deliberate coarsening of estimates for some specific categories of projects, for example, for projects of low cost or complexity, may be allowed. So, in table 4.19, the degree of risk threat is used as a generalized risk assessment, calculated through the probability of a risk event and its impact on the course of the project.
Table 4.19
Risk Threat Matrix
|
^ "" "-" ---- ^ Event probability Impact on the project |
Low (less than 20%) |
Medium (20 to 60%) |
High (over 60%) |
|
Weak. There may be questions or problems in the project, but this is unlikely to lead to a violation of the schedule, budget or a deterioration in the quality of the product. |
|||
|
Average. Potential violation of schedule, increase in cost or deterioration in product quality |
|||
|
Strong. Significant schedule disruption, cost increase or product degradation possible |
Source". Tovb A.S. Tsipes G.L. Decree. Op.
The "division price" both on the auxiliary (probability and impact) and on the main scale (degree of threat) should be determined from practical considerations - whether accuracy is achievable and can be used. What scenarios will develop deviation management in the project is largely determined by the adopted strategies for dealing with risks. Everything can be done to avoid risk, and then the second scenario is most likely. You can, on the contrary, accept the risk and not counteract it, allowing the development of events according to the first or third scenario. You can also reduce the risk, and then, with a favorable course of events, the most desirable scenario is realized when the risk event does not occur.
Problem management. A project problem is any functional, technical or business-related issue that arose during the implementation of the project and requires a response - study and solution in order for the project to go as planned. In other words, a problem is an exceptional circumstance that must be under control from the moment it occurs. Usually problems are divided into two categories: 1) problems that can be solved at the point of origin, i.e. at the project management level (problems); 2) escalated issues that need to be raised to the upper levels of management, including those external to the project, in order to resolve them.
The standard should reflect the formal side of problem management (procedures governing the main stages of working with problems: identifying a problem, monitoring and analyzing a problem, making a decision and executing it, closing a problem. Templates of documents reflecting the process of working with problems - problem card, journal For the analysis of problems, special decision tables can be developed, for example, to determine such a characteristic of a problem as the priority of its solution, the priority matrix shown in Table 4.20 can be used.
When incorporating the problem management process into the company's project management standard, keep in mind that although problem management is required for any project, the degree of use of formal procedures should be appropriate for the specifics of the project, its scale and complexity. For small projects, the costs of fully utilizing this process can be prohibitive.
Change management. A change in a project is a modification of previously agreed products and services, deadlines and cost of work, management and technological processes. As traditional measures to change the resources used
Problem solving priority matrix
Table 4.20
|
Urgency Impact on the project |
Non-urgent |
First things first rare |
Urgent |
|
Weak. Unlikely to disrupt schedule, budget, or product degradation |
Carrier |
||
|
Average. Disruption to the schedule, increase in cost or deterioration in product quality is possible |
|||
|
Strong. Possible significant disruption to the schedule, increased cost or deterioration in product quality |
Particularly important |
||
|
Critical issues require an immediate solution with the involvement of all the necessary resources. Important issues require an urgent solution with the involvement of all available resources. Minor issues require solutions within available resources without prejudice to the rest of the project. Minor problems- no action is taken until its priority is changed. |
|||
Source
in the project, for example, an increase in the intensity of work, material incentives, replacement or attraction of additional performers and subcontractors are used. If there is an opportunity to maneuver the deadlines, then we can talk about changing the deadlines for the completion of individual works, shifting milestones within the project, or even increasing the total time for completing the project. Finally, in some cases it is necessary to resort to the least desirable measures associated with reducing the requirements for quality characteristics, replacing and even excluding the product. In terms of the severity of the consequences, changes can be classified, for example, as planned losses.
For each project, the degree of influence of certain changes on the amount of probable losses arising from the implementation of these changes can be initially determined. In fig. 4.26 this information is presented in a diagrammatic form in which changes are associated with loss areas. Of course, both the types of possible changes and their location by regions are a property of specific projects, or rather, of project types. Therefore, such diagrams can be included in the company standard as a characteristic of the project types defined in the project classification.
Limitations on changes in terms of resources, time, products can be severe to varying degrees, and depending on this, fairly typical situations arise in projects, which can also be described in advance. Let's consider some of these situations. Often the strategy of changes is determined by the fact that changes along one of the axes should not lead to an exit from the area of planned losses. And this means the need for displacement in one or two other dimensions at once.
Area of unacceptable losses
A Resources
Products
Rice. 4.26. Loss areas Source: Tovb A., Tsipes G. Decree. Op.
So, if it is known that the customer is focused on maintaining the planned level of product quality, then there should be options for changes related to the manipulation of resources and deadlines (strategy "Stubborn customer"). In other cases, other strategies may be required, for example, "Tight deadlines" or "Limited budget", when in the area of planned losses, accordingly, changes in terms of time and resources must be recorded. The diagram can show both the desired and possible alternative strategies for change (Figure 4.27).
Rice. 4.27.
Source: Tovb A., Tsipes G. Decree. Op.
Now, in order to be able to compare alternatives not only qualitatively, but also quantitatively, it remains only to develop metrics for each of the axes. And then the strategy can be assessed, for example, by the area of the corresponding triangle. Note also that work with changes at the strategic level must necessarily be supported by formal procedures that describe the main change management processes: registration and registration of change requests, consideration and approval of applications, implementation of changes. In addition, monitoring of change management processes should be carried out, which ensures control of their implementation.
Organizational structures in projects
To carry out the project, special temporary organizational structures are formed, called project teams, which include representatives from various departments. To create and operate a project team, certain methods are used to ensure that these processes are carried out efficiently. The methods are not universal and must take into account the specifics of the company - from its organizational structure to the manufactured product. Among the first problems that arise during the formation of the organizational structures of the project and which must be solved at the level of the project management standard, we note the problems, related to the intersection of functions of administration and project management.
Head of department and project manager. Administrative management in the company is implemented through a management system, the key link of which is middle managers. Project management of a company involves the implementation of all commercial activities in the form of projects and making a profit through the execution of these projects. Accordingly, the meaning of the project manager's activity is to “buy” the necessary resources from the heads of departments and with their help to carry out the project.
Based on the constraints of the project budget, the manager will seek to obtain a specialist of higher qualifications and at the lowest cost. For the head of the department, the main priority is the budget of his department, and therefore, on the contrary, he will try to raise the price and offer a less qualified resource. In order to ensure the observance of general corporate interests, it is necessary to build a system of relations that would help to avoid conflicts or, at least, would provide for formal mechanisms for their resolution.
In this case, a number of obligations arise both on the part of the head of departments in relation to projects and on the part of project managers to resource departments, which must be recorded in the relevant regulations and job descriptions, and special cases can be described additionally in project management plans. Table 4.21 provides examples to illustrate the differences in areas where administrative and project management have common ground.
Project team. When forming the organizational structures of projects, two basic principles must be observed: 1) separation of levels of responsibility; 2) separation of areas of responsibility. In this sense, decisions are directly related to the complexity and complexity of projects. For simple projects, two levels of control are usually sufficient. The project manager carries out operational management of the project, ensures the implementation of planned works, prepares proposals for changes in plans, coordinates technical and human resources. The authority to change the timeline, budget, scope and boundaries of a project belongs to the top level of management and belongs to the top manager. Taken as a basis, this scheme can evolve both downward (subproject managers) and upward (multi-project or program steering committees).
Table 4.21
Separation of responsibilities in administrative management
and project management
|
The sphere of answer-rejection Region management |
Responsibility of the head of the department (administrative department) |
Project manager responsibility (project management) |
|
Planning and control |
Formation of a business plan. Department budget planning. Control "by milestones". Reporting to the management of the enterprise |
Detailed project schedule. Project budget planning. Operational control of the project progress. Reporting to management |
|
Human |
Hiring and firing. Centralized resource allocation. DISCIPLINE control. Organization of training |
Formation of the project team. Analysis and evaluation of the work of employees. Application of sanctions and rewards. Conflict management |
|
Products sold (for example, information systems IS) |
IP creation methodology. |
IS design. IS development. IS implementation |
Source: Tovb A., Tsipes G. Decree. Op.
Thus, an important element of the standard is the description of typical organizational structures for various types of projects, for example, in accordance with the accepted classification and templates of instructions for project personnel at the level of project roles. In addition, the subject of the description in the standard can be a variety of aspects of the functioning of the project team - from the processes of its formation and dissolution to the accounting and reporting procedures mentioned above. Obviously, these processes and procedures cannot be confined within the project and should affect the more general context of corporate relations. In fig. 4.28 shows a diagram of the formation of a project team and its interaction with related services, typical for a company - a system integrator.
Inclusion of specialists in the project team О Interaction of the project team with related services
Rice. 4.28. Project team formation scheme Source: Tovb A., Tsipes G. Decree. Op.
Quality Assurance and Project Management Service. The most correct approach for turning a project management standard into a working tool is to include it in the company's unified quality management system. Let's consider some points related to this approach.
Project planning and quality control is carried out to select those provisions of standards and regulations that are advisable and possible to apply to this specific project, as well as activities and work necessary to ensure the requirements of these standards in terms of the quality of the results and processes of the project.
Quality planning is carried out as part of the overall project planning process. The results of the project quality planning should be reflected in the project management plan. The project quality plan determines how the project will ensure the required quality of work in terms of organizational structure, resources, methodological and instrumental support. During the quality planning stage, documents may also be created that govern the quality control activities of the project management, such as the project audit plan, monitoring questionnaire forms and management reporting. Project implementation control should be systematically carried out in the form of various activities such as audit, monitoring and examination.
Ludit the project - this is a check of the compliance of formalized organizational activities for the implementation of the project with the accepted project management standards. It is important to note that the subject of the project audit is not the technical solutions and the content of the technical documentation of the project.
Project monitoring - regularly performed project status assessments, taking into account the various activities within the project. The purpose of monitoring is to provide management with operational aggregated information on the implementation of the project, sufficient to make key decisions on the project.
The maximum completeness and efficiency of the provision of this information can be achieved using a special information system that provides the collection of the necessary information as soon as it appears during the project. In the absence of an automated system, a special project status report can be used as a monitoring tool, which characterizes the state of the project progress, allows detecting a project falling into a risk zone for operational intervention.
The status report can contain integral assessments for key areas of project activity, which allow you to identify areas of project management that negatively affect the progress of work. An example of such an integral assessment is shown in Fig. 4.29.
Communication Management Risk Management Scope and Boundary Management Project Planning Quality Management Financial and Contract Management Resource Management Change Management INTEGRAL PROJECT EVALUATION 7
Rice. 4.29. Current Project Management Status Chart Source: Tovb A., Tsipes G. Decree. Op.
Expertise of the project- detailed analysis of certain areas of activity within the framework of the project and drawing up an overall picture of the project in order to improve the quality of the implementation of both this project and the projects of the company as a whole.
Based on the results of the examination, a conclusion is prepared containing an analysis of the reasons, as well as recommendations on organizational decisions and measures either to overcome the unfavorable development of this project, or, in case of successful development of the project, to systematize and replicate positive experience.
The place of the quality management service and the project management service in the organizational structure and their functions are shown in Fig. 4.30.
Quality Management Service in terms of project management provides:
- integration of the project management standard into the general system of company standards;
- quality control of project management in the form of audits to verify compliance with corporate project management standards.
If such a service exists in the company at the beginning of the creation of a project management standard, then its development should be based on the basic documents of the quality system created by it. An important place in the work of the project management service should be occupied by the development of project management methodology, including the direct participation of its employees in the company's projects as management personnel; technical and informational support of projects using automation tools.
Rice. 4.30.
project execution
It is known that it is very easy to grow a good lawn. You just need to sow and trim - and so a hundred years. The situation is approximately the same with the quality of project management at the enterprise. Someone should create project management standards, someone should constantly monitor its updating and updating.
A quality assurance system for project management is necessary to ensure that the implementation of each project is guaranteed to meet the needs of all stakeholders, and primarily the customer.
Good project management is only possible when relying on appropriate standards. At first glance, the concepts of "project" and "standard" may seem difficult to reconcile. Indeed, even in the definition of a project, the concept of its uniqueness, unrepeatability of goals, implementation conditions, and project results is included. Since this is true, what can be standardized in project management? And if it is possible, then is it necessary? Will this not hinder, shackle the initiative, impose sub-optimal solutions?
While Western managers prioritize the psychological aspects of management and the art of building interpersonal relationships in a project, their domestic colleagues prefer a procedural approach. This really means that working within the framework of certain restrictions and standards is not only habitual for our managers, but also quite comfortable. And then what about the management of the company, for whom the presence and observance of such standards means a guaranteed level of quality in the implementation of projects?
On the other hand, large Western companies (Siemens, IBM, Oracle, Andersen Consulting) have their own project management methodologies and guidelines.
What should an enterprise project management standard contain? It should be based on so-called framework standards, which contain the most general principles of project management. These are documents such as the Project Management Body of Knowledge (PMBOK) of the American Project Management Institute (PMI), ISO 10006: 1997 standard, Russian NTK (National Competence Requirements). Each enterprise is unique in some way, therefore the framework standards must be adapted to the specific conditions of project management. This can be achieved by applying specialization and standards detailing approaches.
Specialization means the inclusion in the enterprise standard of those and only those provisions that are relevant to the project activities at this particular enterprise. This means that the enterprise standard must contain clear classification of enterprise projects, since projects can relate to different professional areas of activity (legal, financial, construction, etc.), and each of these areas has its own characteristics that need to be considered when writing a project management standard.
organizational structures and personnel project. The enterprise standard can not only fix standard project roles, but also determine the structure and principles of forming project management bodies. For all structural divisions, the principles of their participation in projects should be determined - the types of work performed, the procedure for allocating and recalling personnel. For the leadership of these units, their rights and responsibilities in relation to the organizational structures of the project should be defined. For employees involved in the project, rules must be defined that govern their work in the project, governing the issues of dual subordination and material incentives.
Specialization also includes project management processes ... Actually, the description of these processes and procedures occupies the bulk of the standard.
Thus, the enterprise standard is understood as a set of documents prescribing how, in what sequence, in what time frame, and using what templates certain actions must be performed in the project management process. These documents do not belong to any one project and form a regulatory and methodological union of the project management system as a whole.
The standard may describe typical situations specific to enterprise projects, and recommendations for managers to respond to these situations. This can help him in choosing an alternative solution.
The scope of an enterprise project management standard depends on the degree detailing standard and list of basic documents. They can be represented in the form of a pyramid growing from top to bottom - Project Management Guidelines Policy - Project Management Procedures - Detailed instructions for the execution of procedures - Document templates (Figure "Project Management Standard Structure").
Abstract: The article provides a chronological overview of popular standards in the field of information project management, their inherent features, affected areas of knowledge and processes. The role of the International Project Management Association (IPMA) in the formation of national standards of individual countries is presented.
In 1986, the Software Engineering Institute (SEI) began developing a system for assessing the capabilities of software companies "Capability Maturity Model" (CMM) based on the techniques described by Philip B. Grosby, a specialist and renowned lecturer in the field of quality management, in his book " Quality is Free ". The development was initiated by a request from the US Air Force, due to the urgent need to be able to assess the professionalism of contractors.
CMM defines five levels of professionalism:
1. Initial - the development process is not under statistical control, there is no progress in improving the processes.
2. Repeatable - a sustainable process with a renewable level of statistical control achieved through the application of rigorous project management in the areas of labor, costs, timing and change.
3. Established - there is an established development process, internal quality standards, management understands the shortcomings of the applied practices. Successful implementation of advanced technologies is possible.
4. Guided - after a certain stage, you can initiate the analysis process. Management is able to manage quality using developed techniques.
5. Optimized - the organization is in a constant process of improvement.
As the CMM assessment system was a questionnaire of 85 process and 16 technology questions, the standard itself became available to the public in 1988, a complete description of the CMM as a set of processes and practices corresponding to each level was released in 1991, in 1995 it was released in a book version ... Later, the CMM was developed into a set of methodologies for improving processes in organizations: "Capability Maturity Model Integration" (CMMI), the latest (as of the end of 2014) version of CMMI-DEV, V1.3. was released in 2010, the following are the process areas to which attention is paid in this standard:
- Cause Analysis and Resolution (CAR)
- Configuration Management (CM)
- Decision Analysis and Resolution (DAR)
- Project Integration Management (IPM)
- Measurement and Analysis (MA)
- Organization Process Description (OPD)
- Organizational Process Focus (OPF)
- Performance Management (OPM)
- Productive Organizational Process (OPP)
- Organizational Training (OT)
- Product Integration (PI)
- Project Monitoring and Control (PMC)
- Project Planning (PP)
- Product and Process Quality Assurance (PPQA)
- Quantitative Project Management (QPM)
- Requirements Development (RD)
- Requirements Management (REQM)
- Risk Management (RSKM)
- Supplier Contract Management (SAM)
- Development of a technical solution (TS)
- Validation (VAL)
- Verification (VER)
As a methodology, PRINCE2 overlaps a lot and contributes to compliance with the international project management standard, so that it can be applied to any type of project. Among other things, PRINCE employs “variance management” to ensure the efficient use of the time of senior management personnel, and also ensures that roles and responsibilities are clearly assigned so that everyone understands what is expected of them and what to expect from others. PRINCE2 includes: a set of principles, control themes and a process model.
The PRINCE2 principles promote good practice in the implementation of the methodology by preventing excessive or superficial application and are deduced in a practical way:
- Continuous business case
- Learn from experience
- Distribution of roles and responsibilities
- Step-by-step management
- Deviation Management
- Product focus
- Adaptation to the specifics of the project
- Economic justification
- Organization
- Quality
- Plans
- Risks
- Changes
- Progress
- Launch of the project
- Project management
- Project initiation
- Stage Boundary Management
- Stage control
- Product delivery management
- Closing a project
In Russia, IPMA appeared in 1990 as SOVNET. At the moment, the association is engaged in professional project management training, accreditation of project management training programs and international certification of specialists based on its own four-stage system:
A - certified project director;
B - certified senior project manager;
C - certified project manager;
D is a certified project management specialist.
The national representative offices of the association, based on the ICB, develop their own requirements for competence, which should reflect national and cultural differences, following this logic SOVNET has published the standard: "Fundamentals of Professional Knowledge and National Requirements for the Competence of Project Management Specialists" (NTC), last edition from 2010.
NTC considers a systemic project management model consisting of three main components:
1. Objects of management - projects, programs and portfolios;
2. Subjects of management - investor, customer, team, manager and other interested parties.
3. Management processes - are considered as a set of tasks and management procedures and are presented in sections: stages of the management process, functional area of management, time interval, object and subject of management. In STC, the following stages of the management process are distinguished:
- initiation (launch) of the project,
- project planning,
- organization and control of the project work,
- analysis and regulation of the progress of the project,
- closing the project.
- Project Subject Area Management
- Project management by time parameters
- Project cost and financing management
- Quality management in the project
- Project risk and opportunity management
- Human resource management in the project
- Project procurement and contract management
- Project change management
- Project security management
In 1996, the Project Management Institute, Inc. (PMI) published the A Guide to the Project Management Body of Knowledge (PMBOK Guide), which describes the PMBOK project management standard. This standard is compatible with the international project management standard ISO 9000. PMBOK combines a wide range of knowledge and practices in the field of project management, as well as entire programs and project portfolios. It focuses on the project life cycle, the impact of the organization, including its internal culture, on project management.
The standard identifies a set of project management processes that have been shown to increase the likelihood of success for a wide range of different projects, and the manual notes that it is not necessary to use a complete list of processes and it is worth selecting those that will effectively achieve the goals of the selected project. In the standard, processes are divided into the following groups:
- Project Management Process Group
- Initiation process group (2 processes)
- Planning process group (20 processes)
- Execution process group (8 processes)
- Monitoring and control process group (10 processes)
- Completion process group (2 processes)
- Project Integration Management
- Project Scope Management
- Project time management
- Project cost management
- Project quality management
- Project Human Resource Management
- Project communications management
- Project Risk Management
- Project procurement management
In November 2001, the Project Management Professionals Certification Center (PMCC) of Japan, later renamed the Project Management Association of Japan (PMAJ), publishes the P2M project management standard. In the context of the methodology, managers are considered who are called upon to achieve the mission of the project, who must have knowledge from related areas and are divided into three levels of professionalism:
- specialist manager (PMS),
- manager-registered (PMR) and
- manager-architect (PMA).
- Strategic project management
- Project finance management
- Project systems management
- Organizational project management
- Project Goal Management
- Project resource management
- Management of risks
- Information management
- Project Relationship Management
- Project cost management
- Project communications management
The main standards used in the field of project management are considered, the beginning of the development of the first of which dates back to 1986, and the last one in 2010, their inherent processes and features, intersections with international project management standards. The role of the International Project Management Association (IPMA) in the formation of national standards of individual countries is presented, the applied levels for assessing the qualifications of companies and managers are given. The study reviewed the following standards submitted by relevant organizations and countries:
- CMMI - Software Engineering Institute (USA)
- PRINCE - Central Computer and Telecommunications Agency (UK)
- ICB - International Project Management Association (Switzerland)
- NTK - SOVNET (national representative office of IPMA in Russia)
- PMBOK - Project Management Institute (USA)
- ISO 21500 - International Organization for Standardization
- P2M - Project Management Association of Japan (Japan)
Bibliography
1. Crosby P.B., Quality is Free. New York: New American Library, 1979 - ISBN 0-451-62247-22. Humphrey W.S., Characterizing the Software Process. A maturity Framework [Electronic resource] / Software Engineering Institute, 1987 - Access mode: www.sei.cmu.edu/reports/87tr011.pdf
3. Paulk M.C., The Capability Maturity Model: Guidelines for Improving the Software Process. Mass .: Addison-Wesley Pub. Co., 1995 - ISBN 0-201-54664-7
4. CMMI® for Development, Version 1.3 [Electronic resource] / Software Engineering Institute, 2010 - Access mode: www.sei.cmu.edu/reports/10tr033.pdf (access date: 03.11.2014).
5. What is PRINCE2? [Electronic resource] / Office of Government Commerce, UK - Access mode: www.prince2.com/what-is-prince2 (date of access: 03.11.2014).
6. Interstate standard GOST R ISO 21500. Project Management Guide, 2012
7. PRINCE2® in one thousand words [Electronic resource] / Andy Murray and Director of Outperform UK Ltd, 2009 - Access mode: www.best-management-practice.com/gempdf/PRINCE2_in_One_Thousand_Words.pdf (access date: 03.11.2014) ...
8. ICB - IPMA Competence Baseline, Version 3.0 [Electronic resource] / International Project Management Association, 2006 - Access mode: (date of access: 03.11.2014).
9. Soolyatte A.Yu., Project management in the company: methodology, technology, practice. Moscow: MFPU "Synergy", 2012
10. Certify Individuals [Electronic resource] / International Project Management Association - Access mode: ipma.ch/certification/certify-individuals (date of access: 03.11.2014).
11. Project management. Fundamentals of Professional Knowledge, National Requirements for the Competence of Specialists / ed. Doctor of Technical Sciences Voropaeva V.I., M .: JSC "Project PRACTICE", 2010
12. A Guide to the project management body of knowledge / PMI Standards Committee. USA: Project Management Institute, 1996
13. Guide to the Project Management Body of Knowledge (PMBOK® Guide) - Fourth Edition / PMI Standards Committee. USA: Project Management Institute, 2008 - ISBN: 978-1-933890-51-7
14. Gasik S., PhD, Comparison of ISO 21500 and PMBOK®. Guide Version improved after comments of Jesus Guardiola and Francesca Montanari [Internet source] - Access mode: www.sybena.pl/dokumenty/ISO-21500-and-PMBoK-Guide.pdf (date accessed: 03.11.2014).
15. A Guidebook of Project & Program Management for Enterprise Innovation [Internet source] / Project Management Association of Japan, Revision 3, 2005 - Access Mode: Add Labels
