CC BY
32
12. Великий, Ю.В. 1нновацмна дiяльнiсть пщприемств машинобудiвного комплексу: [Електронний ресурс] / Ю.В. Великий. - Режим доступу: http://www.nbuv.qov.ua/portal/Soc Gum/Vchnu ekon/2011 2 2/146-149.pdf
13. Мильнер, Б.З. Теория организации [Текст] : учеб.для студентов вузов по экон.спец. / Б.З. Мильнер. -2 изд., перераб. и доп. -М. : ИНФРА-М, 1999. - 478с.
14. Балацький, О.Ф. УправлЫня швести^ями [Текст] : навч. поаб. для студ. вищих навч. закл. / О.Ф. Балацький [та ш.]. - Суми : Уыверситетська книга, 2004. - 231с.
15. Бочаров, В.В. Инвестиционный менеджмент [Текст] : учеб. пособие / В.В. Бочаров. -СПб. : Питер, 2000. - 152 с.
16. Макконнелл Кэмпбелл Р. Экономикс: принципы, проблемы и политика [Текст] : учебник / Макконнелл К.Р., Брю С.Л. ; пер. с англ. - 13-е изд. - М. : ИНФРА-М, 1999. - 974 с.
Рецензент статп Стаття рекомендована до
д.емн., проф. Заблодська 1.В. пуб™ац" ^«^б р.
UDC 005.83
Nnaji A. Chidimma
VALUE AS A CORE CONCEPT IN CONSIDERING THE SYSTEM OF THE PROJECT QUALITY MANAGEMENT
Existing approaches to the project quality management are analyzed. It's shown that traditionally they focus on commitment with requirements and specifications. The need and importance to consider stakeholders' value system as a core of the effective project quality management is highlighted. Fig. 2, tabl. 3, ref. 19.
Key words: quality management, requirements, value, project process quality, project product quality.
Problem statement and actuality. Project in its unique nature can be said to be impossible to realize without an appropriate management and even when an appropriate management is in place, a little slack in quality management of an aspect of the project process can spell disaster for the project product and result. Project is any temporary enterprise that is aimed at achieving the mission of a consumer to create value via the unique properties of the project product within a given constraint of time, resources and quality. From this definition we can see that to fulfill such non-negotiable and demanding characteristics of a project there ought to be an effective "Management Process" - serious continual planning, controlling, monitoring and reviewing of the whole process involved, including the project product till the consumer's mission is achieved.
In such a methodical business world like ours it is almost impossible to see any organization that does not at least know about the concept and or even the practice of project management. In other words, more than two-third of project performing organizations have a constant project management structure, whilst less than one-third at least have the head-knowledge of project management axiom.
According to one of the articles published by PMI, about 74% of projects fail, that is to say that only about 26% of all projects succeed, and if so, "then having a failed project is not a remote possibility" [1]. Having known this fact about project performing organizations, some foods for thought are then - why do projects fail to realize the expected results? Why do project managers and team fail to meet the stipulated stakeholders' requirements? Why do project deliverables fail to yield expected satisfaction even after stipulated requirements were met? Why are there many records
"Управлшня проектами та розвиток виробництва", 2016, №2(58) 65
of low level of project quality and high level of customer dissatisfaction...? To fully assimilate these foods for thought, we will have to take some time to analyze some of the identified reasons why projects fail.
There are tons of reasons why projects (irrespective of types and kinds) fail; the number can be endless. Howbeit, employing the 80/20 rule we can list the following as the most prevalent reasons for the failures (tabl. 1, constructed basing on [1]).
Table 1
Core reasons why projects fail
Failure reason Relation to project parameter Failure reason Relation to project parameter Failure reason Relation to project parameter
Poorly PrQ Undefined PrQ Lack of PrQ
managed objectives and goals management commitment
Lack of a solid PrQ Lack of user PrQ PdQ Lack of PrQ
project plan input organizational support
Centralized PrQ Enterprise PrQ Provides PrQ
proactive management initiatives to management of budget resources universal templates and documentation
combat project risk
Poorly defined PrQ Inadequate or PdQ Stakeholder PrQ
roles and vague conflict
responsibilities requirements
Team PrQ Unrealistic PrQ Competing PrQ
weaknesses timeframes and tasks priorities
Poor PrQ Insufficient PrQ Business politics PrQ
communication resources (funding and personnel)
Overruns of PrQ Estimates for PrQ Lack of PrQ
schedule and cost cost and schedule are erroneous prioritization and project portfolio management
Scope creep PrQ No change control process PrQ Meeting end user expectations PdQ
Ignoring project PrQ Inadequate PrQ Bad decisions PrQ
warning signs testing processes
From the table above, we can observe lots of reasons that have been recorded as the major causes of project failure. However, encapsulating these reasons in few words, we can simply say that projects fail because of lack of adequate quality management of projects processes and product. At this point one cannot but wonder what quality management actually is, and why these specified reasons of project failures are attributed to inadequacy of project quality management.
Quality has been generally defined as the ability of any given product to meet its spelt out requirements, as well as satisfy the intended needs of the consumers. Quality management is the process of skillfully, resourcefully and timely coordinating,
66
"ynpaBniHHA npoeKTaMM Ta po3BMTOK BMpo6HM|TBa", 2016, №2(58)
controlling and monitoring all the project activities and processes with the aim of providing project products that satisfy the intended needs of the customers. It is the process for ensuring that all project activities needed for the designing, planning and implementation of projects are effective and efficient in line with the requirement, objective and performance of the project [2]. Relating the above definition to the various reasons listed in table 1, we can clearly see that PQM will include and cover all the phases of project life cycle, which includes project initiation, its development, implementation, realization and project product exploitation. A critical account of these phases will take into consideration the different aspects of planning, documentation, organizational structure, communication style and leadership, resource management, stakeholders, decision making processes, et al. It would not be an over statement to say that project that fails to meet stakeholder's expectations as a result of inadequate or vague requirements, insufficient resources, unrealistic timeframes and tasks or overruns of schedule and cost, simply did not apply the necessary quality management in the area of defining the project scope, the necessary time, resources and budget needed for the project realization. The project manager and his team may have been overexcited about the project that they became too careless to take into account (while carrying out the feasibility study) the fact that the project might never be executed within the stipulated constraints of time, cost and resources, or maybe they were not careful enough in the planning, collecting of data and definition of the project scope or in the creation of the project WBS. Any of the reasons above comprehensibly point to just one thing - inadequacy of quality management of both the project processes and product.
An effective project quality management is one that starts from the initialization phase of the project, takes into consideration all the project management processes (project integration management, scope, time, cost, human resource, communication, risk, procurement, and stakeholder management), and ends with the project product exploitation. Negligence on any of these aspects in quality management can have a dire consequence on the total quality of the project product.
Main findings. In an attempt to ensure a good understanding and implementation of project quality management, different quality researchers and specialists have come out with different definitions and approaches to quality management. Though generally, quality to them simply means 'meeting customer requirements', however, their perceptions of customer requirements were expressed differently:
1) 'the total composite product and service characteristics of the organization to meet the expectation by the customer' - Feigenbaum (1983);
2) 'quality should be aimed the needs of the consumer' - Deming (1986);
3) ' fitness for use' - Juran (1989);
4) ' conformance to requirements' - Crosby (1992);
5) 'the totality of characteristics of an entity that bear on its ability to satisfy stated and implied need' - ISO 9000:2000.
In like manner, different organizations such as Project Management Institute (PMI), Organization for Standardization (ISO), Australian Institute of Project Management (AIPM), International Project Management Association (IPMA), Association of Project Managers Group (APMG) et al., have set up various standards, principles, guidelines and practices that will aid project managers in their endeavor to achieve the general project quality objectives. ISO for example, has set up and published about five versions of quality standards evolving from ISO 9001:1987, ISO 9000:1994, ISO 9001:2000, ISO 9001:2008, and ISO TC 176, while PMI has released up to sixth edition of its guide and standard to facilitate project quality management. PMI for instance, considers project quality management as one of the nine knowledge
"ynpaBniHHA npoeKTaMM Ta po3BMTOK BMpo6HMqTBa", 2016, №2(58) 67
areas of project management, and under a "three-process-management" of - Plan Quality, Perform Quality Assurance, and Perform Quality Control, including the varied inputs, tools and outputs involved in each of the processes, AIPM delineate it as a unit of competence with its corresponding elements, performance criteria, necessary background knowledge, and evidence of demonstrated competence. Also similarly to AIPM, quality for IPMA is one of the elements of technical competence, whereas ISO dedicated the entire pages of the document for the establishment of guidelines for quality in management of projects.
However, similarly to aforementioned quality experts, there are some similitude among all the standards under review. Quality according to them means the degree to which inherent or assigned characteristics of project management and its product(s) fulfill stakeholders' requirements, needs, and specifications. Quality management is defined as the activities carried out in order to direct and manage a project with regard to quality. Some of the main similarities are summarized in the table 2 below.
Table 2
Commonalities of project quality management represented by different
standards
PQM Knowledge Area Process group
Initiating Planning Executing Monitoring & controlling Closing
PQ process - Plan quality Perform quality assurance Perform quality control -
PMI's PMBOK - + + + -
HERMES - + + -
APM's PMBOK - + + + -
ISO 10006:2003 - + -
NSQHS STANDARDS - -
PM4DEV - + + + -
PRINCE2 - + + + -
IPMA Competence Baseline - + + + -
As shown in the tabl. 2, we can see that there is an agreement between most of the standards about the elements of quality management: quality planning, quality control, and quality assurance. This is not to say that there are no differences at all in the various project management standards on quality management, but rather to emphasize the similarities in their essence and processes. Sure there are some discrepancies, nonetheless these can be said to be rooted in the various approaches -targets, focus, and structures of standards.
Tabl. 3 elucidates core differences in some of the project (quality) management standards. Based on table 3, we can conclude that there are generally three basic approaches used in exploring project quality management, and they are as follows: (1) Process approach, (2) System approach and (3) Integral approach.
Process approach is used by majority of the standards whereby project quality management is viewed in three distinct processes of plan quality, quality assurance and control quality. A Process approach surmises that a desired result can only be achieved more effectively and efficiently when activities and related resources are managed as a process. According to this approach, projects that adhere to the principles of plan the quality, perform quality assurance and quality control
68
"ynpaBniHHA npoeKTaMM Ta po3BMTOK BMpo6HM|TBa", 2016, №2(58)
PMBOK Guide 4th, ISO 21500 processes and PMBOK Guide 5th on PQM
Table 3
<
~a 0)
CD ^
x'
I
a
~a o
CD 0)
T3
o
0
01
CD 0)
|\J O
en oo
CD CD
Process ISO 21500 processes | PMBOK Guide 4- PMBOK Guide 5'
Plan quality Entails s et out guidelines, principles and practices on quaiiy management throughout the project, as well as how and who will use the resources. Applicable to projects of different categories, complexities, size and length.
Covers 9 basic tools for managing quality in project cost-benefit analysis, cost of quality, control chart, benchmarking, design of experiments, statistical sampling, proprietary QM methodologies, additional quality planning tools, flowcharting
Did not specify possible tools tor this process Quality management plan refers to the quality policy set by the permanent organization-ANSI (or derivedfrom it), and cover the multiple outputs of the ANSI Introduces new tools ('Seven basics quality tools': cause & effect diagrams, flowcharts check sheets Pareto diagrams, histograms, control charts and scatter diagrams) and removes flowcharting and proprietary quality management
Perform Quality Assurance standard (quality metrics, quality checklists, process improvement plans, etc.). methodologies
Different activities and processes tha are implemented to ensure that quality requirements and standards are conformed to
- 'Process of auditing quality requirements & results from control measures to ensure that the appropriate standards & operational definitions are used' - Enumerates 3 varyingtools and techniques for the process: quality management & control tools, quality audit, process analysis, and explained especiaDyQMCT in detailed compared with the precedrg editions
- 'Uuahty assurance activities ensure that product quality conforms to project quality requirements and standards". - Deals with communicating and understanding (by the means of established procedures) quality requirements
- The process is prncipaiiy handled in the quality control process of the ANSI standard
Perform quality contro] Monitoring and evaluation of quality activities with the aim of seeking means to continually improve the quality
Suggests and explains tools: seven basic quality tools, statistical sampling, inspection, approved change requests review, formanagmgthisprocess. but does not particularly spot the importance of management in ensuring the success of the project
includesthecreation and maintenance of quality culture by both the top management of both the originating and project organizations Identifies formal inspection reports as the core outputs of the process
respectively have a high propensity to be of acceptable quality. To ensure a good project quality management the project manager has to first define and understand what quality means to the stakeholders and based on that, plan the project quality, including creating criteria for its measurement. Afterwards, a constant practice that will assure the stakeholders of the quality requirements conformance, as well as consistence control and monitoring of the level of quality adherence will be carried out. A system approach postulates that Identifying, understanding and managing interconnected processes as a system facilitates the effective and efficient achievement of an organization's objectives. System approach accent the responsibility of the top management for the achievement of quality objectives through a systematic process that ensures the commitment of all the necessary stakeholders at all levels within the project executing organization, in order to ensure that the customer's stated and implied needs, as well as that of other interested parties', including the originating organization's quality policy are fully incorporated, understood evaluated, and met. This could be achieved by deploying the following eight principles of quality management:
- customer focus;
- leadership;
- involvement of people;
- process approach;
- system approach to management;
- continual improvement;
- factual approach to decision making;
- mutually beneficial supplier relationships.
For the integral approach, the main principle is that of continuous improvement. This is focused on the use of inspections and other statistical techniques to continuously identify reduce or eliminate deviations from quality requirements.
The truth still remains that despite the enormous amount of quality principles and guidelines accessible to project managers, projects in most cases still have a higher record of failure (poor quality) than success (good quality). But why is that so? Could that mean that the information contained in the standards are erroneous? Or could it be because of the insufficiency of relevant information? Maybe there is more to project quality management than that which is contained in the standards? Probably they are methodically and abstractively based, that they forget to consider the actuality of projects and their environment? In as much as we cannot speak of the erroneousness of the prevalent standards, principles, guidelines and practices, yet we can undoubtedly say that there is something wrong with how quality is been seen and managed in our time.
Discussion. Having analyzed some of the aforementioned project management standards' attitude towards quality, we can affirm that most, if not all of them basically have one deficiency in common, that is to say, there are little or no peculiarities of specific projects taken into account. Practically all the currently used project quality management guidelines are too generalized and abstractive to be effective. Prevalently, quality as afore mentioned is seen as the ability of any given product to meet certain requirements, while project quality management is considered as activities or processes that allow for the satisfaction of these requirements. In other words, the yardstick for measuring any given quality is requirements. Moreover, requirements from the customer's viewpoint are basically feeling based- assumptions of how they feel project product will be, in order to satisfy their needs. It is not strange to state that in most cases, customers though being aware of their needs may not know how to communicate them to the project managers. This makes it even more complicated to speak about requirements when addressing the issue of quality. If a
70
"ynpaBniHHA npoeKTaMM Ta po3BMTOK BMpo6HMqTBa", 2016, №2(58)
customer cannot be able to lucidly communicate his needs to the project manager, maybe because of the fact that he doesn't even know what and how he feels, then his specifications/requirements should not be considered as the main and only determining factor of the project quality.
Quality is subjective in nature, and this simply means that it is only the owner of a given problem, that is, the user of a project product, that can determine the result of the project. The project manager, his team, the form of the project product, the level of set requirements met, while realizing the project most likely do not determine the quality of a project. This is one of the main flaws of project quality management; everything about quality seems to be ultimately connected to "meeting requirements". Certainly, seeking and understanding stakeholder's requirements is an indispensable aspect of quality management, nonetheless, using it as an ultimate indicator of quality has not been able, and might never be able to provide the maximum expected quality satisfaction. Let's consider some cases where requirements though fully met could not amount to customer quality satisfaction.
The first case study is a situation where a client works up to a project executing organization with his problem, with the intention of seeking solution that will resolve the problem. The project manager assuming to understand the customer's problem and to have the solution to the problem goes ahead to compile (possibly with the project team experts) lists of complicated requirements and specifications for the clients to sign up in approval. Here we can see that quality criteria for the project manager are all about technical specifications, which might be contrary to clients'. Though the client in some cases might sign on the requirements, however, the end result of the project might be client's dissatisfaction of the project deliverables.
In this instance, the project manager met all the requirements and specifications signed on by the client, yet the client's needs were still not met. Why? Simple, -quality is subjective- what it means to the project manager/project team expert might be completely different from what it means to the project user.
Another instance is the case where project managers compile project requirements secretly without the interference of the clients, as they believe that requirements assemblage is better and efficiently done by some project experts without much involvement of the clients. Project managers especially follow this path when they don't want to lose control of the project to the clients by allowing them to specify their own requirements; they feel they have the necessary experience (technical expertise) to execute the project, and therefore, wouldn't want to waste much time on paperwork and meetings with the client. Project managers may argue that the clients do not know much about the latest technology at heart of the project, yet it did not rule out the fact that he-the client, wants what he wants and will know when he sees what he wants.
Here the project manager with the experts (most likely technical) quickly develop the project requirements and then explain to the clients, who being convinced will accept and sign off on the requirements. The end product of this approach, however, is that the project manager might produce a project that meets its specified requirements but the project might not meet the intended quality-needs of the clients.
The most common scenario is where the project managers gather and treat customer's requirements as if they were mere grocery list. Project managers go around gathering and making a long list of project requirements by different stakeholders and then using the list as a benchmark for measuring quality. The negatives to this approach are the possibility of missing necessary details/ requirements out, and only realizing that after the project implementation has set out or even be completed; and possibility of adding things that might appear to be a good idea but are not requisite for the project scope. Irrespective of the case, the project still
"ynpaBniHHA npoeKTaMM Ta po3BMTOK BMpo6HMqTBa", 2016, №2(58) 71
yields similar result - poor project quality: scope creep, unrealistic change requests, overruns of budget, time and resources- client dissatisfaction.
Having considered these instances, we can attest to the fact that quality is a bit higher than what it is considered to be today. Quality in a broader context has many meanings depending on customers, ranging from luxury and merit to excellence, good value for money or convenience and even practicality. If we can't find a comprehensive definition of project quality, we can't assess its efficacy and therefore we can't apply it effectively to deliver successful projects [3]. In different words, the first step to resolving these project quality management issues of our time is to define and understand what quality actually is to the customers/users of the project product; and this can only be done by looking beyond the norm to see what's outside the box.
In [15] author stated that nowadays value becomes a core concept within project management activity. And in [16] he exposed that quality as a concept should be applied to consider stakeholders' values in explicit way. Then "...system of the quality assessment indicators becomes a base to make decisions through the project life circle, including project closing. On this particular phase the whole activity devoted to values delivering meets the time of their appearance". On the suggested model (fig. 1) author showed that during the project life circle quality concept changes its context.
Fig. 1. Pyramid of values transformation into the assessment indicators system
through the "quality" concept
One can notice it by changes in terms. On the initialization phase it's expedient to talk about quality of the business-idea, and on the development phase - about quality of developed documents. The most important is quality of the project product exploitation. During this stage wanted quality is supported on the level of consumers' requirements. And consumers' requirements traditionally differ from that ones agreed on development and implementation phases of the project.
For the purpose of this work, we will consider project quality in two different aspects to project quality: (1) project process quality and (2) project product quality.
Project process quality is the ability of a project to meet specified stakeholders' requirements through the means of a skillful, resourceful and timely coordination, control and monitoring of all the activities and processes involved. This aspect of
72
"ynpaBniHHA npoeKTaMM Ta po3BMTOK BMpo6HMqTBa", 2016, №2(58)
quality can be met by the project manager gathering necessary requirements from the various interested parties to ensure that all their interests are thoroughly considered and included. At this juncture, the project manager can measure the extent of adherence to the set requirements- quality- by using different approaches:
(1) Expected-planned review, which involves the participation of internal customers (project owners, sponsors, clients and project management team) in project activities such as expectation identification, requirements definition, layout planning and decisions, documentation, customer satisfaction ascertainment, etc.
(2) Planned-factual review - a cumulative planning of the incremental review of every step within the project phase, and a punctilious analysis of the results to identify any deviations from the original plans.
Project product quality can be defined as a consistent conformity of a product to the client's value system. Value here is defined as one's principles, standards, judgment or ideas about what is right and wrong, or what is important in life; is an internal motivator that drives a stakeholder to engage in project. According to Business Dictionary, value system is a coherent set of values adopted and/or evolved by a person, organization, or society as a standard to guide its behavior in preferences in all situations.
When we think of values, the first thing that comes to mind are things that are of great importance to use. These, however, can be situational-based, as the level of importance can vary depending on the given situation. Values are desirable, trans-situational goals, varying in importance, that serve as guiding principles in people's lives. There are various sides and feature of value, however, the crucial content aspect that distinguishes among values is the type of motivational goal they express [17, 18]. Based on these definitions, we can affirm that knowing user's/client's value and value system is weightier than just the requirements, as requirements are only partial reflection of their value system. Differently put, a project manager that strives to understand what the value system of his client(s) is, is more likely to produce and deliver project that meets the client's quality standard than a project manager that tend to focus on just requirements and specifications.
From the two aspects and definitions of quality, we can draw a conclusion that virtually all the project quality management experts, including standards focus more on project process quality, that is to say, on fulfilling certain stated requirements. Project managers pay so much attention on identifying and meeting stakeholders' requirements and little or no attention on knowing the system of values that drives their behavior and judgment of what is of quality and what is not.
Like the popular saying goes: it is insane to do the same thing over and over and expect a different result. Project managers should know that holding on to the same old celebrated "requirement-oriented approach" in managing project quality will most likely yield the same quality result they so much loathe. Therefore, trying a different approach like "value-oriented approach" might go a long way in ensuring the production of expected project quality. Let's consider this approach using conceptual model "3M pyramid" [19] (fig. 2). Following the logic of this model, we place parameters of project management process and parameters of product configuration on the lowest (methodic) level, wich is the most close to the space of pratice. Two steps of further reflection allows to place requirements/specifications and stakeholders' value system on the middle (method) and the highest (methodological) level appropriately. And according to results of our research we can conclude that conventional project qualty management approach ebraces space by the method level of requirements/specificatons, but recommended approach covers the highest methodological level.
In reality, the most efficient way to tackle any problem is to know the root of the problem. For example, when a patient goes to a psychotherapist with certain challenges and complains, one of the first things he-the psychotherapist does is to "Управлшня проектами та розвиток виробництва", 2016, №2(58) 73
endeavor to really know the patient's make-up, his value system which reflects in his interest and behavior. Likewise, project managers should understand the stakeholders' value system and treat quality as an explicit representation of their value. With this in mind, project managers, as well as project quality management specialist will have a different attitude toward the system of "quality assessment indicators", as it will serve as the basis for making any quality related management decision in all the phases of the project life cycle, including exploitation phase.
Undoubtedly, the contextual meaning of quality might not be the same in the different phases of the project life cycle. For example, in the initialization phase, one can talk about the quality of business idea, while in the development phase we talk about the quality of the documents' content. However, knowing the stakeholders' requirements and ultimately the customer's value system will lead to a better quality management of the entire project processes, as well as the project product.
Thus project managers should endeavor to identify the unspoken requirements (value system) of their clients, as eventually they are what will determine the extent to which they are satisfied with the project deliverables. Sure, to know one's value system is not easy, and will not happen by mere communication, which is mostly conducted with the aim of making "shopping list" of what the client's says. It can only be known by an intricate "observational conversation" between the client and the project manager, a type of conversation that will continue and last through the period of the project lifecycle, that will require an activation of the inner eyes and ears, to see and hear what the clients mean to say, and not just what they say.
Conclusion and prospect. Based on the analysis of the works of different quality experts, different standards and guidelines, as well as their impacts on project success with regards to quality, we will affirm that lots have been said and done. However, the number of projects succeeding (meeting the user's quality level) is less proportional to the efforts made on them to succeed. The core reason for such situation is an exaggeration: an over-focus on "meeting requirements", which is only a part of project quality management.
Stakeholder's value system
Requirements/ specifications
Parameters of project management process and parameters product configuration
Fig. 2. Metrics of the project quality management on the base of "3M pyramid"
74
"ynpaBniHHA npoeKTaMM Ta po3BMTOK BMpo6HM|TBa", 2016, №2(58)
Value system is a very important factor that helps determine the level of user's satisfaction with the project quality, and so understanding a customer's value system is more important than trying to define his requirement. Hence to ensure a better project quality management, project managers should learn to look beyond stakeholder's listed specifications and requirements to understand what the values of the clients really are because that is what will be used to judge the quality of the project deliverables.
REFERENCES
1. Carlos, T. Reasons Why Projects Fail. Retrived from: https://www.projectsmart.co.uk/pdf/reasons-why-projects-fail.pdf.
2. Indelicato, Greg. (2009). A Guide to the Project Management Body of Knowledge (PMBOK ® Guide), Fourth Edition. Proj Mgmt Jrnl Project Management Journal 40, no. 2(2009): 104. doi:10.1002/pmj.20125.
3. Rose, K. (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide)-Fifth Edition. Proj Mgmt Jrnl, 44(3), e1-e1. Retrived from: http://dx.doi.org/10.1002/pmj.21345.
4. Ehsan Zafarani (2011). Project Quality Management Approaches: A Comparative Evaluation of International Standards. Retrived from: http://www.ipedr.com/vol15/8-ICCPM2011A00014.pdf.
5. Diaz, P. (2008). Project Quality Management. Project Management for Development Organizations. Retrived from:http://www.classtoolkit.or g/sites/default/files/documents/PM4DEV Project Quality Management .pdf.
6. Basu, R. Managing Quality in Projects (Advances in Project Management). New Edition. Retrived from: http://www.gpmfirst.com/books/managing-quality-projects.
7. Iman, A. and Siew, H. O (2008). Project Management Practices: The Criteria for Success or Failure. Retrived from: http://www.ibimapublishing.com/journals/CIBIMA/volume1/v1n28.pdf.
8. Bureau of indian standards (2003). IS/ISO 10006 (2003): Quality Management Systems -Guidelines for Quality Management in Projects. Retrived from: https://law.resource.org/pub/in/bis/S07/is.iso.10006.2003.pdf.
9. Dick, B. (2015). Requirements Gathering Blunders and Best Practices. Retrived from: http://4pm.com/requirements-gathering-4pm-com-2/.
10. Ryan Nelson, R. (2007). IT Project Management: Infamous Failures, Classic Mistakes, and Best Practices. Retrived from: http://www2.commerce.virginia.edu/cmit/Research/MISQE%206-07.pdf.
11. Jeffrey K.P. and Samuel J.M., JR. (1990). The Causes of Project Failure. Retrived from: https://www.researchgate.net/publication/3076218 The Causes of Project Failure.
12. Juran, J.M. and De Feo, J.A. (2010) Juran's quality handbook: The complete guide to performance excellence - 6th edn. New York: McGraw-Hill.
13. Kenneth, R.H. Project Quality Management: Why, What and How. Boca Raton, FL: J. Ross Pub., 2005.
14. Anthony van der Wiele (2006). International journal of quality and reliability management: innovative quality management cases. Retrived from: https://books.google.com.ua/books?id=2jGHW57-pgIC&pg=PT25&lpg=PT25&dq= quality+management+approach+HERMES&source=bl&ots=STq9Fbrxmc&sig=aJYumLqi4k2-saR TxZ0Esb6j-E&hl=ru&sa=X&ved=0ahUKEwigxdui6ubNAhWGCywKHVfL BccQ6AEIVzAI#v=onepage&q=quality%20management%20approach%20HERMES&f=false
15. Рач, В.А. Цшнють як базова категорiя сучасноТ методологи управлЫня проектами [Текст]/ В.А. Рач // УправлЫня проектами у розвитку сусптьства. УправлЫня цЫнютю проек^в та програм розвитку оргашзацй тез. доп. VII мiж. конф. 20-21 травня 2010 р. - К.: КНУБА, 2010. - С.167-168.
16. Рач, В.А. Качество - центральная категория проектной деятельности / В.А. Рач // УправлЫня проектами: стан та перспективи: мат. Х мiжнар. науково-практ. конф., 16-19 вересня, 2014 р., Микола'1'в - Микола'1'в: НУК, 2014. - С.240-242.
17. Shalom, H.S. (2012). An Overview of the Schwartz Theory of Basic Values. Retrived from: http://scholarworks.gvsu.edu/cgi/viewcontent.cgi?article=1116&context=orpc.
"Управлшня проектами та розвиток виробництва", 2016, №2(58) 75
18. Shalom, S. A value priorities and behavior: applying the theory of integrated system. Retrived from:
http://www.palermo.edu/cienciassociales/psicologia/publicaciones/pdf/Psico2/2Psico%2007.pdf.
19. Rach, V., Rach, D., 2000, Risk management in project implemented in transitional economy: financial products for the real sector in Ukraine. Proc. of international conference, Kyiv, 25-26.
,-, Стаття рекомендована до
Рецензент статт _ " ... „ _ _
, .. „ .. публ1каци 13.06.2016 р.
д.т.н., проф. Медведева О.М. ' ^ г
УДК 330.16+658.310.7
О.М. Ляшенко
БЕЗПЕЧНА СИНЕРГ1Я В УПРАВЛ1НН1 ПЩПРИСМСТВОМ
Сформульоваы 6a30Bi положення безпечноТ синерги в управляй пiдприeмством. Здiйснено iнтерпретацií безпечноТ синерги на прикладi управлiння економiчною безпекою пiдприeмства, показано особливостi такоТ iнтерпретацií на прикпадi контентноТ пари «ефективнють-результативнють». Дж. 4.
Кпючовi слова: синерпя, пiдприeмство, управлiння, ефективнiсть, результативнють, економiчна безпека.
Постановка проблеми та видшення нерозв'язано! ii частини.
Проблематика управлшня п1дприемствами належить до класу задач, вир1шення яких, з одного боку, е безперервним, з ¡ншого таким, що перебувае у процеа пост1йного удосконалення. Ц1льов1 установки такого удосконалення час вщ часу зазнають суттевих зм1н, як1 нараз1 скерован на убезпечення економ1чних 1нтерес1в. У найбтьш узагальненому вигляд1 таку семантичну конструкцш називають управлянням економ1чною безпекою.
Виходячи з того, що управлшня економ1чною безпекою шдприемства е штегрованою системою, головн1 ц1л1 якоТ стосуються сталого розвитку шдприемства в поточному та майбутых перюдах, постановка проблеми ц1еТ статт1 буде стосуватися достатньо поширеного у науц1 явища синерги, але 1нтерпретовану визначення впливу економ1чноТ безпеки п1дприемства на досягнення його загальних цтей.
Отже, управл1ння економ1чною безпекою п1дприемства е достатньо складним процесом. G дек1лька головних причин, ям зумовлюють таку складн1сть: по-перше, к1льк1сть 1нтерес1в, як1 мають шдлягати узгодженню, е достатньо великою та вкрай неоднородною, по-друге, узгодження штереав е не одномоментним актом, а складною i тривалою д1ею, яка мае, виходячи з авторського розумшня економiчноТ безпеки та тлумачення акмеобезпекологи, досягти гармонiйного стану [1].
Новий, рашше не дослiджений аспект такого управлшня виходить з припущення, що синерпчш ефекти iманентно притаманнi економiчнiй безпецi, якщо IT розглядати як мiру економiчноТ свободи. Проте, осктьки царина економiчноТ безпеки як жодна з шших царин пов'язана iз загрозами, такi ефекти можуть бути як позитивними (принаймш, найчастiше таю ефекти i розглядаються «за замовчаанням», без припущення, що можуть бути якюь iншi), так i негативними. Очевидно, що припущення щодо нейтрально!' синерги [2, с. 32] не некоректним. Водночас, «латеральне» використання принципа 3S (safety, security, safeguards), запозичене з лексикону МАГАТЕ [3], у цьому дослщження
цтком може стат в нагодк_
76 "Управлшня проектами та розвиток виробництва", 2016, №2(58)
