A Guide To The Project Management Body Of Knowledge (BAB 2)

 The Project Management Context



Projects and project management operate in an environment broader than that of the project itself. The project management team must understand this broader context—managing the day-to-day activities of the project is necessary for success but not sufficient. This chapter describes key aspects of the project management context not covered elsewhere in this document. The topics included here are:

2.1 Project Phases and the Project Life Cycle
2.2 Project Stakeholders
2.3 Organizational Influences
2.4 Key General Management Skills
2.5 Social-Economic-Environmental Influences


2.1 PROJECT PHASES AND THE PROJECT LIFE CYCLE




Because projects are unique undertakings, they involve a degree of uncertainty. Organizations performing projects will usually divide each project into several project phases to improve management control and provide for links to the ongoing operations of the performing organization. Collectively, the project phases are known as the project life cycle.

2.1.1 Characteristics of Project Phases

Each project phase is marked by completion of one or more deliverables. A deliverable is a tangible, verifiable work product such as a feasibility study, a detail design, or a working prototype. The deliverables, and hence the phases, are part of a generally sequential logic designed to ensure proper definition of the product of the project.
The conclusion of a project phase is generally marked by a review of both key deliverables and project performance to date, to a) determine if the project should continue into its next phase and b) detect and correct errors cost effectively. These phase-end reviews are often called phase exits, stage gates, or kill points.

Each project phase normally includes a set of defined deliverables designed to establish the desired level of management control. The majority of these items are related to the primary phase deliverable, and the phases typically take their names from these items: requirements, design, build, test, startup, turnover, and others, as appropriate. Several representative project life cycles are described in Section 2.1.3.

2.1.2 Characteristics of the Project Life Cycle

The project life cycle serves to define the beginning and the end of a project. For example, when an organization identifies an opportunity to which it would like to respond, it will often authorize a needs assessment and/or a feasibility study to decide if it should undertake a project. The project life-cycle definition will determine whether the feasibility study is treated as the first project phase or as a separate, standalone project.
The project life-cycle definition will also determine which transitional actions at the beginning and the end of the project are included and which are not. In this manner, the project life-cycle definition can be used to link the project to the ongoing operations of the performing organization.
The phase sequence defined by most project life cycles generally involves some form of technology transfer or handoff such as requirements to design, construction to operations, or design to manufacturing. Deliverables from the preceding phase are usually approved before work starts on the next phase. However, a subsequent phase is sometimes begun prior to approval of the previous phase deliverables when the risks involved are deemed acceptable. This practice of overlapping phases is often called fast tracking.
Project life cycles generally define:
_ What technical work should be done in each phase (e.g., is the work of the architect part of the definition phase or part of the execution phase?).
_ Who should be involved in each phase (e.g., implementers who need to be involved with requirements and design).
Project life-cycle descriptions may be very general or very detailed. Highly detailed descriptions may have numerous forms, charts, and checklists to provide structure and consistency. Such detailed approaches are often called project management methodologies.
Most project life-cycle descriptions share a number of common characteristics:
_ Cost and staffing levels are low at the start, higher toward the end, and drop rapidly as the project draws to a conclusion. This pattern is illustrated in Figure 2-1.
_ The probability of successfully completing the project is lowest, and hence risk and uncertainty are highest, at the start of the project. The probability of successful completion generally gets progressively higher as the project continues.
_ The ability of the stakeholders to influence the final characteristics of the project’s product and the final cost of the project is highest at the start and gets progressively lower as the project continues. A major contributor to this phenomenon is that the cost of changes and error correction generally increases as the project continues.
Care should be taken to distinguish the project life cycle from the product life cycle. For example, a project undertaken to bring a new desktop computer to market is but one phase or stage of the product life cycle.

Although many project life cycles have similar phase names with similar deliverables required, few are identical. Most have four or five phases, but some have nine or more. Even within a single application area, there can be significant variations— one organization’s software development life cycle may have a single design phase while another’s has separate phases for functional and detail design.
Subprojects within projects may also have distinct project life cycles. For example, an architectural firm hired to design a new office building is first involved in the owner’s definition phase when doing the design, and in the owner’s implementation phase when supporting the construction effort. The architect’s design project, however, will have its own series of phases from conceptual development through definition and implementation to closure. The architect may even treat designing the facility and supporting the construction as separate projects with their own distinct phases.

2.1.3 Representative Project Life Cycles

The following project life cycles have been chosen to illustrate the diversity of approaches in use. The examples shown are typical; they are neither recommended nor preferred. In each case, the phase names and major deliverables are those described by the author for each of the figures.
Defense acquisition. The United States Department of Defense Instruction 5000.2 in Final Coordination Draft, April 2000, describes a series of acquisition milestones and phases as illustrated in Figure 2-2.
_ Concept and technology development—paper studies of alternative concepts for meeting a mission need; development of subsystems/components and concept/ technology demonstration of new system concepts. Ends with selection of a system architecture and a mature technology to be used.
_ System development and demonstration—system integration; risk reduction; demonstration of engineering development models; development and early operational test and evaluation. Ends with system demonstration in an operational environment.
_ Production and deployment—low rate initial production (LRIP); complete development of manufacturing capability; phase overlaps with ongoing operations and support.


_ Support—this phase is part of the product life cycle, but is really ongoing management. Various projects may be conducted during this phase to improve capability, correct defects, etc.
Construction. Adapted from Morris (1), describes a construction project life cycle, as illustrated in Figure 2-3.
_ Feasibility—project formulation, feasibility studies, and strategy design and approval. A go/no-go decision is made at the end of this phase.
_ Planning and design—base design, cost and schedule, contract terms and conditions, and detailed planning. Major contracts are let at the end of this phase.
_ Construction—manufacturing, delivery, civil works, installation, and testing. The facility is substantially complete at the end of this phase.
_ Turnover and startup—final testing and maintenance. The facility is in full operation at the end of this phase.
Pharmaceuticals. Murphy (2) describes a project life cycle for pharmaceutical new product development in the United States, as illustrated in Figure 2-4.
_ Discovery and screening—includes basic and applied research to identify candidates for preclinical testing.
_ Preclinical development—includes laboratory and animal testing to determine safety and efficacy, as well as preparation and filing of an Investigational New Drug (IND) application.
_ Registration(s) workup—includes Clinical Phase I, II, and III tests, as well as preparation and filing of a New Drug Application (NDA).
_ Postsubmission activity—includes additional work as required to support Food and Drug Administration review of the NDA.


Software development. There are a number of software life-cycle models in use such as the waterfall model. Muench, et al. (3) describe a spiral model for software development with four cycles and four quadrants, as illustrated in Figure 2-5.
_ Proof-of-concept cycle—capture business requirements, define goals for proof of concept, produce conceptual system design and logic design, and construct the proof of concept, produce acceptance test plans, conduct risk analysis, and make recommendations.
_ First-build cycle—derive system requirements, define goals for first build, produce logical system design, design and construct the first build, produce system test plans, evaluate the first build, and make recommendations.
_ Second-build cycle—derive subsystem requirements, define goals for second build, produce physical design, construct the second build, produce subsystem test plans, evaluate the second build, and make recommendations.
_ Final cycle—complete unit requirements and final design, construct final build, and perform unit, subsystem, system, and acceptance tests.


2.2 PROJECT STAKEHOLDERS


Project stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion; they may also exert influence over the project and its results. The project management team must identify the stakeholders, determine their requirements, and then manage and influence those requirements to ensure a successful project. Stakeholder identification is often especially difficult. For example, is an assembly-line worker whose future employment depends on the outcome of a new product-design project a stakeholder?
Key stakeholders on every project include:
_ Project manager—the individual responsible for managing the project.
_ Customer—the individual or organization that will use the project’s product. There may be multiple layers of customers. For example, the customers for a new pharmaceutical product may include the doctors who prescribe it, the patients who take it, and the insurers who pay for it. In some application areas, customer and user are synonymous, while in others customer refers to the entity purchasing the project’s results and users are those who will directly use the project’s product.
_ Performing organization—the enterprise whose employees are most directly involved in doing the work of the project.
_ Project team members—the group that is performing the work of the project.
_ Sponsor—the individual or group within or external to the performing organization that provides the financial resources, in cash or in kind, for the project.
In addition to these, there are many different names and categories of project stakeholders—internal and external, owners and funders, sellers and contractors, team members and their families, government agencies and media outlets, individual citizens, temporary or permanent lobbying organizations, and society at large. The naming or grouping of stakeholders is primarily an aid to identifying which individuals and organizations view themselves as stakeholders. Stakeholder roles and responsibilities may overlap, as when an engineering firm provides financing for a plant that it is designing.



Managing stakeholder expectations may be difficult because stakeholders often have very different objectives that may come into conflict. For example:
_ The manager of a department that has requested a new management information system may desire low cost, the system architect may emphasize technical excellence, and the programming contractor may be most interested in maximizing its profit.


_ The vice president of research at an electronics firm may define new product success as state-of-the-art technology, the vice president of manufacturing may define it as world-class practices, and the vice president of marketing may be primarily concerned with the number of new features.
_ The owner of a real estate development project may be focused on timely performance, the local governing body may desire to maximize tax revenue, an environmental group may wish to minimize adverse environmental impacts, and nearby residents may hope to relocate the project.
In general, differences between or among stakeholders should be resolved in favor of the customer. This does not, however, mean that the needs and expectations of other stakeholders can or should be disregarded. Finding appropriate resolutions to such differences can be one of the major challenges of project management.

2.3 ORGANIZATIONAL INFLUENCES

Projects are typically part of an organization larger than the project—corporations, government agencies, health-care institutions, international bodies, professional associations, and others. Even when the project is the organization (joint ventures, partnering), the project will still be influenced by the organization or organizations that set it up. The maturity of the organization with respect to its project management systems, culture, style, organizational structure, and project management office can also influence the project. The following sections describe key aspects of these larger organizational structures that are likely to influence the project.

2.3.1 Organizational Systems

Project-based organizations are those whose operations consist primarily of projects. These organizations fall into two categories:
_ Organizations that derive their revenue primarily from performing projects for others—architectural firms, engineering firms, consultants, construction contractors, government contractors, nongovernmental organizations, etc.
_ Organizations that have adopted management by projects (see Section 1.3).
These organizations tend to have management systems in place to facilitate project management. For example, their financial systems are often specifically designed for accounting, tracking, and reporting on multiple simultaneous projects.
Nonproject-based organizations often lack management systems designed to support project needs efficiently and effectively. The absence of project-oriented systems usually makes project management more difficult. In some cases, nonproject- based organizations will have departments or other subunits that operate as project-based organizations with systems to match.
The project management team should be acutely aware of how the organization’s systems affect the project. For example, if the organization rewards its functional managers for charging staff time to projects, then the project management team may need to implement controls to ensure that assigned staff members are being used effectively on the project.




2.3.2 Organizational Cultures and Styles

Most organizations have developed unique and describable cultures. These cultures are reflected in their shared values, norms, beliefs, and expectations; in their policies and procedures; in their view of authority relationships; and in numerous other factors. Organizational cultures often have a direct influence on the project. For example:
_ A team proposing an unusual or high-risk approach is more likely to secure approval in an aggressive or entrepreneurial organization.
_ A project manager with a highly participative style is apt to encounter problems in a rigidly hierarchical organization, while a project manager with an authoritarian style will be equally challenged in a participative organization.

2.3.3 Organizational Structure

The structure of the performing organization often constrains the availability of or terms under which resources become available to the project. Organizational structures can be characterized as spanning a spectrum from functional to projectized, with a variety of matrix structures in between. Figure 2-6 shows key projectrelated characteristics of the major types of enterprise organizational structures. Project organization is discussed in Section 9.1, Organizational Planning.
The classic functional organization, shown in Figure 2-7, is a hierarchy where each employee has one clear superior. Staff members are grouped by specialty, such as production, marketing, engineering, and accounting at the top level, with engineering further subdivided into functional organizations that support the business of the larger organization (e.g., mechanical and electrical). Functional organizations still have projects, but the perceived scope of the project is limited to the boundaries of the function: the engineering department in a functional organization will do its work independent of the manufacturing or marketing departments.


For example, when a new product development is undertaken in a purely functional organization, the design phase is often called a design project and includes only engineering department staff. If questions about manufacturing arise, they are passed up the hierarchy to the department head, who consults with the head of the manufacturing department. The engineering department head then passes the answer back down the hierarchy to the engineering project manager.
At the opposite end of the spectrum is the projectized organization, shown in Figure 2-8. In a projectized organization, team members are often collocated. Most of the organization’s resources are involved in project work, and project managers have a great deal of independence and authority. Projectized organizations often have organizational units called departments, but these groups either report directly to the project manager or provide support services to the various projects.
Matrix organizations, as shown in Figures 2-9 through 2-11, are a blend of functional and projectized characteristics. Weak matrices maintain many of the characteristics of a functional organization, and the project manager role is more that of a coordinator or expediter than that of a manager. In similar fashion, strong matrices have many of the characteristics of the projectized organization—full-time project managers with considerable authority and fulltime project administrative staff.
Most modern organizations involve all these structures at various levels, as shown in Figure 2-12. For example, even a fundamentally functional organization may create a special project team to handle a critical project. Such a team may have many of the characteristics of a project in a projectized organization. The team may include full-time staff from different functional departments, it may develop its own set of operating procedures, and it may operate outside the standard, formalized reporting structure.


2.3.4 Project Office

There is a range of uses for what constitutes a project office. A project office may operate on a continuum from providing support functions to project managers in the form of training, software, templates, etc. To actually being responsible for the results of the project.

2.4 KEY GENERAL MANAGEMENT SKILLS

General management is a broad subject dealing with every aspect of managing an ongoing enterprise. Among other topics, it includes:
_ Finance and accounting, sales and marketing, research and development, and manufacturing and distribution.
_ Strategic planning, tactical planning, and operational planning.
_ Organizational structures, organizational behavior, personnel administration, compensation, benefits, and career paths.
_ Managing work relationships through motivation, delegation, supervision, team building, conflict management, and other techniques.
_ Managing oneself through personal time management, stress management, and other techniques.
General management skills provide much of the foundation for building project management skills. They are often essential for the project manager. On any given project, skill in any number of general management areas may be required. This section describes key general management skills that are highly likely to affect most projects and that are not covered elsewhere in this document.




These skills are well documented in the general management literature, and their application is fundamentally the same on a project.
There are also many general management skills that are relevant only on certain projects or in certain application areas. For example, team member safety is critical on virtually all construction projects and of little concern on most software development projects.

2.4.1 Leading

Kotter (4) distinguishes between leading and managing while emphasizing the need for both: one without the other is likely to produce poor results. He says that managing is primarily concerned with “consistently producing key results expected by stakeholders,” while leading involves:
_ Establishing direction—developing both a vision of the future and strategies for producing the changes needed to achieve that vision.
_ Aligning people—communicating the vision by words and deeds to all those whose cooperation may be needed to achieve the vision.
_ Motivating and inspiring—helping people energize themselves to overcome political, bureaucratic, and resource barriers to change.
On a project, particularly a larger project, the project manager is generally expected to be the project’s leader as well. Leadership is not, however, limited to the project manager: it may be demonstrated by many different individuals at many different times during the project. Leadership must be demonstrated
at all levels of the project (project leadership, technical leadership, and team leadership).

2.4.2 Communicating

Communicating involves the exchange of information. The sender is responsible for making the information clear, unambiguous, and complete so that the receiver can receive it correctly. The receiver is responsible for making sure that the information is received in its entirety and understood correctly. Communicating has many dimensions:
_ Written and oral, listening and speaking.
_ Internal (within the project) and external (to the customer, the media, the public, etc.).
_ Formal (reports, briefings, etc.) and informal (memos, ad hoc conversations, etc.).
_ Vertical (up and down the organization) and horizontal (with peers and partner organization).
The general management skill of communicating is related to, but not the same as, Project Communications Management (described in Chapter 10). Communicating is the broader subject and involves a substantial body of knowledge that is not unique to the project context, for example:
_ Sender-receiver models—feedback loops, barriers to communications, etc.
_ Choice of media—when to communicate in writing, when to communicate orally, when to write an informal memo, when to write a formal report, etc.
_ Writing style—active versus passive voice, sentence structure, word choice, etc.
_ Presentation techniques—body language, design of visual aids, etc.
_ Meeting management techniques—preparing an agenda, dealing with conflict, etc.
Project Communications Management is the application of these broad concepts to the specific needs of a project—for example, deciding how, when, in what form, and to whom to report project performance.

2.4.3 Negotiating

Negotiating involves conferring with others to come to terms with them or reach an agreement. Agreements may be negotiated directly or with assistance; mediation and arbitration are two types of assisted negotiation.
Negotiations occur around many issues, at many times, and at many levels of the project. During the course of a typical project, project staff is likely to negotiate for any or all of the following:
_ Scope, cost, and schedule objectives.
_ Changes to scope, cost, or schedule.
_ Contract terms and conditions.
_ Assignments.
_ Resources.

2.4.4 Problem Solving

Problem solving involves a combination of problem definition and decision-making.
Problem definition requires distinguishing between causes and symptoms. Problems may be internal (a key employee is reassigned to another project) or external (a permit required to begin work is delayed). Problems may be technical (differences of opinion about the best way to design a product), managerial (a functional group is not producing according to plan), or interpersonal (personality or style clashes).
Decision-making includes analyzing the problem to identify viable solutions, and then making a choice from among them. Decisions can be made or obtained (from the customer, from the team, or from a functional manager). Once made, decisions must be implemented. Decisions also have a time element to them—the “right” decision may not be the “best” decision if it is made too early or too late.

2.4.5 Influencing the Organization

Influencing the organization involves the ability to “get things done.” It requires an understanding of both the formal and informal structures of all the organizations involved—the performing organization, customer, partners, contractors, and numerous others, as appropriate. Influencing the organization also requires an understanding of the mechanics of power and politics.
Both power and politics are used here in their positive senses. Pfeffer (5) defines power as “the potential ability to influence behavior, to change the course of events, to overcome resistance, and to get people to do things that they would not otherwise do.” In similar fashion, Eccles et al. (6) say that “politics is about getting collective action from a group of people who may have quite different interests. It is about being willing to use conflict and disorder creatively. The negative sense, of course, derives from the fact that attempts to reconcile these interests result in power struggles and organizational games that can sometimes take on a thoroughly unproductive life of their own.”

2.5 SOCIAL-ECONOMIC-ENVIRONMENTAL INFLUENCES

Like general management, socioeconomic influences include a wide range of topics and issues. The project management team must understand that current conditions and trends in this area may have a major effect on its project: a small change here can translate, usually with a time lag, into cataclysmic upheavals in the project itself. Of the many potential socioeconomic influences, several major categories that frequently affect projects are described briefly below.

2.5.1 Standards and Regulations

The International Organization for Standardization (ISO) differentiates between standards and regulations as follows (7):
_ A standard is a “document approved by a recognized body, that provides, for common and repeated use, rules, guidelines, or characteristics for products, processes or services with which compliance is not mandatory.” There are numerous standards in use covering everything from thermal stability of hydraulic fluids to the size of computer diskettes.
_ A regulation is a “document, which lays down product, process or service characteristics, including the applicable administrative provisions, with which compliance is mandatory.” Building codes are an example of regulations.
Care must be used in discussing standards and regulations since there is a vast gray area between the two; for example:
_ Standards often begin as guidelines that describe a preferred approach, and later, with widespread adoption, become de facto regulations (e.g., the use of the Critical Path Method for scheduling major construction projects).
_ Compliance may be mandated at different levels (e.g., by a government agency, by the management of the performing organization, or by the project management team).
For many projects, standards and regulations (by whatever definition) are well known, and project plans can reflect their effects. In other cases, the influence is unknown or uncertain and must be considered under Project Risk Management (described in Chapter 11).

2.5.2 Internationalization

As more and more organizations engage in work that spans national boundaries, more and more projects span national boundaries as well. In addition to the traditional concerns of scope, cost, time, and quality, the project management team must also consider the effect of time-zone differences, national and regional holidays, travel requirements for face-to-face meetings, the logistics of teleconferencing, and often volatile political differences.

2.5.3 Cultural Influences

Culture is the “totality of socially transmitted behavior patterns, arts, beliefs, institutions, and all other products of human work and thought” (8). Every project must operate within a context of one or more cultural norms. This area of influence includes political, economic, demographic, educational, ethical, ethnic, religious, and other areas of practice, belief, and attitudes that affect the way that people and organizations interact.

2.5.4 Social-Economic-Environmental Sustainability

Virtually all projects are planned and implemented in a social, economic, and environmental context, and have intended and unintended positive and/or negative impacts. Organizations are increasingly accountable for impacts resulting from a project (e.g., accidental destruction of archeological sites in a road construction project), as well as for the effects of a project on people, the economy, and the environment long after it has been completed (e.g., a roadway can facilitate the access to and destruction of a once pristine environment).

sumber :

Project Management Institute, “A Guide To The Project Management Body Of Knowledge”, Newton Square, USA, 1996.

Read More

A Guide To The Project Management Body Of Knowledge (terjemahan BAB 2) )

Bab 2
Konteks Manajemen Proyek
                Proyek dan manajemen proyek beroperasi dalam lingkungan yang lebih luas daripada proyek itu sendiri. Tim manajemen proyek harus memahami hal ini lebih luas konteks-mengelola sehari-hari kegiatan dari proyek ini adalah diperlukan untuk sukses tetapi tidak cukup. Bab ini menjelaskan aspek-aspek kunci dari manajemen proyek konteks tempat lain yang tidak tercakup dalam dokumen ini. Topik yang termasuk di sini adalah
2.1 Proyek Tahapan dan Siklus Hidup Proyek
2.2 Proyek Stakeholder
2.3 Pengaruh Organisasi
2.4 Kunci Keterampilan Manajemen Umum
2.5 Pengaruh Sosial-Ekonomi-Lingkungan


2.1 PROYEK DAN TAHAPAN SIKLUS HIDUP PROYEK

Karena proyek adalah usaha yang unik, mereka melibatkan tingkat ketidakpastian.Organisasi yang melakukan proyek biasanya akan membagi proyek menjadi beberapa tahapan proyek untuk meningkatkan kontrol manajemen dan menyediakan link ke beberapa operasi organisasi yang sedang berlangsung. Secara kolektif, proyek fase dikenal sebagai siklus hidup proyek

2.1.1 Karakteristik Tahapan Proyek
Setiap tahapan proyek ditandai dengan selesainya satu atau lebih Proyek. Sebuah penyampaian adalah nyata kerja diverifikasi produk seperti studi kelayakan, detail desain, atau prototipe bekerja. Para kiriman, dan karenanya fase, adalah bagian dari logika umum sekuensial dirancang untuk memastikan definisi yang tepat dari produk proyek.
Kesimpulan dari tahapan proyek umumnya ditandai dengan tinjauan dari kedua kunci kiriman dan kinerja proyek, untuk a) menentukan apakah proyek harus berlanjut ke tahap berikutnya dan b) mendeteksi dan memperbaiki kesalahan biaya efektif. Fase-end ini sering disebut fase keluar, gerbang panggung, atau point penentu.
                Setiap tahapan proyek biasanya mencakup satu set kiriman yang idefinisikan, dirancang untuk menetapkan tingkat yang diinginkan kontrol manajemen.Sebagian besar barang-barang yang terkait dengan fase primer deliverable, dan fase biasanya mengambil mereka dari item ini: persyaratan, desain, membangun, pengujian, memulai, omset, dan orang lain, yang sesuai. Siklus proyek perwakilan kehidupan. Beberapa dijelaskan dalam Bagian 2.1.3.

2.1.2 Karakteristik dari Siklus Hidup Proyek
Siklus hidup proyek berfungsi untuk menentukan awal dan akhir proyek. Misalnya, ketika sebuah organisasi mengidentifikasi kesempatan yang diinginkan untuk merespon, sering akan mengotorisasi penilaian kebutuhan / atau studi kelayakan untuk memutuskan apakah itu harus melaksanakan suatu proyek. Proyek daur-hidup definisi akan menentukan apakah studi kelayakan diperlakukan sebagai tahap proyek pertama atau sebagai proyek terpisah mandiri.
Proyek daur-hidup didefinisikan juga akan menentukan tindakan transisi pada awal dan akhir .Proyek daur-hidup didefinisikan dapat digunakan untuk menghubungkan proyek yang sedang berlangsung dengan  operasi organisasi yang sedang melakukan. Urutan fase didefinisikan oleh siklus proyek yang paling hidup pada umumnya melibatkan beberapa bentuk transfer teknologi atau hand off seperti persyaratan untuk desain, konstruksi operasi, atau desain untuk manufaktur. Deliverables dari sebelumnya fase biasanya disetujui sebelum pekerjaan dimulai pada fase berikutnya. Namun, sub-fase berturut kadang-kadang dimulai sebelum persetujuan dari fase sebelumnya deliverables ketika risiko dianggap diterima. Fase praktek ini sering  tumpang tindih disebut pelacakan cepat.
Proyek siklus hidup secara umum didefinisikan:
•         Apa pekerjaan teknis yang harus dilakukan dalam setiap fase (misalnya, adalah karya arsitek bagian dari tahap definisi atau bagian dari fase eksekusi).
•         Siapa yang harus terlibat dalam setiap tahap (misalnya, pelaksana yang perlu terlibat dengan persyaratan dan desain).
          Proyek siklus hidup deskripsi mungkin sangat umum atau sangat rinci. deskripsi  sangat rinci mungkin memiliki berbagai bentuk, grafik, dan daftar periksa untuk memberikan struktur dan konsistensi. Pendekatan rinci seperti ini sering disebut proyek pengelolaan metodologi.
               Kebanyakan proyek siklus hidup deskripsi berbagi beberapa karakteristik umum:
•         Biaya  dan tingkat staf yang rendah pada awal, lebih tinggi menjelang akhir, dan drop cepat sebagai proyek menarik suatu kesimpulan. Pola ini diilustrasikan dalam gambar 2-1.
•        Kemungkinan berhasil menyelesaikan proyek ini adalah terendah, dan karenanya risikodan ketidakpastian yang tinggi, di awal proyek. Kemungkinan sukses selesai umumnya akan semakin tinggi sebagai proyek terus.
•          Kemampuan para pemangku kepentingan untuk mempengaruhi karakteristik akhir dari produk proyek dan biaya akhir dari proyek ini adalah tertinggi pada awal dan akan semakin rendah sebagai proyek . Seorang kontributor utama untuk Fenomena  ini adalah bahwa biaya perubahan dan koreksi kesalahan umumnya meningkat sebagai proyek terus.

                Perawatan harus diambil untuk membedakan siklus hidup proyek dari hidup produk siklus. Misalnya, proyek dilakukan untuk membawa komputer desktop baru untuk pasar hanyalah salah satu fase atau tahapan siklus hidup produk.
              Meskipun siklus hidup proyek banyak memiliki nama yang sama dengan penilaian setara fase deliverables diperlukan, hanya sedikit yang identik.  kebanyakan memiliki empat atau lima fase, tetapi beberapa memiliki sembilan atau lebih. Bahkan dalam area aplikasi tunggal, akan ada variasi yang signifikan pengembangan perangkat lunak satu organisasi siklus hidup yang mungkin memiliki satu desain fase sementara yang lain yang memiliki fase terpisah untuk desain fungsional dan detail.
               Subproyek dalam proyek juga mungkin memiliki siklus hidup proyek yang berbeda.Sebagai contoh, sebuah perusahaan arsitektur disewa untuk merancang sebuah bangunan kantor,  pertama terlibat dalam fase definisi ketika melakukan desain, dan dalam pemilik tahap implementasi ketika mendukung upaya pembangunan. proyek desain arsitek, bagaimanapun, akan memiliki serangkaian fase dari konsep pembangunan melalui definisi dan pelaksanaan penutupan. Arsitek bahkan dapat mengobati, merancang fasilitas dan mendukung pembangunan sebagai proyek terpisah dengan fase mereka sendiri yang berbeda.

2.1.3 Siklus Hidup Proyek Perwakilan
Siklus hidup proyek berikut telah dipilih untuk menggambarkan keragaman pendekatan yang digunakan. Contoh-contoh yang ditunjukkan khas, mereka tidak direkomendasikan atau disukai. Dalam setiap kasus, nama fase dan point utama yang yang dijelaskan oleh penulis untuk masing-masing tokoh.Pertahanan akuisisi. Amerika Serikat Departemen Pertahanan Instruksi 5.000,2 di Draft Koordinasi Akhir, April 2000, menggambarkan serangkaian akuisisi tonggak dan fase seperti yang diilustrasikan pada Gambar 2-2.
•          Konsep dan studi teknologi kertas pengembangan konsep alternatif untuk memenuhi kebutuhan misi, pengembangan subsistem / komponen dan konsep kecuali bahwa demonstrasi / teknologi konsep sistem baru. Berakhir dengan pilihan dari arsitektur sistem dan teknologi dewasa untuk digunakan.
•          Sistem pengembangan dan integrasi sistem demonstrasi, pengurangan risiko; demonstrasi model pengembangan rekayasa, pengembangan dan awal operasional pengujian dan evaluasi. Berakhir dengan demonstrasi sistem dalam operational lingkungan.
•          Produksi dan penyebaran tingkat produksi awal yang rendah (LRIP); lengkap dengan pengembangan kemampuan manufaktur, fase tumpang tindih dengan operasional  yang sedang berlangsung negosiasi dan dukungan.
•         Dukungan ini merupakan bagian dari fase siklus hidup produk, tetapi manajemen benar-benar berlangsung. Berbagai proyek dapat dilakukan selama tahap ini untuk meningkatkan kemampuan, yang benar cacat, dll Konstruksi.
Diadaptasi dari Morris (1), menggambarkan kehidupan proyek konstruksi siklus, seperti digambarkan pada Gambar 2-3.
•         Kelayakan proyek formulasi, studi kelayakan, dan desain strategi dan persetujuan. Sebuah keputusan go / no-go yang dibuat pada akhir fase ini.
•         Perencanaan dan desain desain dasar, biaya dan jadwal, kontrak persyaratan dan kondisi baik, dan perencanaan rinci. Kontrak-kontrak besar dibiarkan pada akhir fase ini.
•         Konstruksi manufaktur, pengiriman, pekerjaan sipil, instalasi, dan pengujian. Fasilitas ini telah selesai pada akhir fase ini.
•         Turnover dan pengujian akhir startup dan pemeliharaan. Fasilitas ini secara penuhoperasi pada akhir fase ini.
Farmasi. Murphy (2) menjelaskan siklus hidup proyek untuk farmasi pengembangan produk baru di Amerika Serikat, seperti yang diilustrasikan pada Gambar 2-4.
•         Discovery dan skrining meliputi penelitian dasar dan terapan untuk mengidentifikasi kandididat untuk pengujian praklinis.
•         pengembangan praklinis termasuk laboratorium dan pengujian hewan untuk menentukan keamanan dan kemanjuran, serta persiapan dan pengajuan Investigational New Drug (IND)
•         Registrasi (s) pemeriksaan meliputi Tahap klinis I, II, III dan tes, sertapersiapan dan pengajuan New Drug Application (NDA).
•         Postsubmission s activityincludes pekerjaan tambahan yang diperlukan untuk mendukung Makanan and Drug Administration review NDA.
                Pengembangan perangkat lunak. Ada beberapa perangkat lunak siklus hidup model dalam gunakan seperti model air terjun. Muench, et al. (3) menggambarkan model spiral untuk pengembangan perangkat lunak dengan empat siklus dan empat kuadran, seperti yang digambarkan dalam Gambar 2-5.
•         Bukti-konsep siklus-capture kebutuhan bisnis, menentukan tujuan untuk bukti konsep, menghasilkan desain sistem konseptual dan desain logika, dan membangun bukti dari konsep, menghasilkan rencana uji penerimaan, melakukan analisis risiko, dan membuat rekomendasi.
•         Pertama-membangun siklus-berasal persyaratan sistem, menentukan tujuan untuk membangun pertama, produk sistem desain logis, desain dan membangun pertama membangun, menghasilkan sistem rencana uji, mengevaluasi membangun pertama, dan membuat rekomendasi.
•         Kedua-membangun siklus-berasal persyaratan subsistem, menentukan tujuan untuk kedua
membangun, menghasilkan desain fisik, membangun kedua membangun, menghasilkan subsistem
•         Rencana uji, mengevaluasi membangun kedua, dan membuat rekomendasi. siklus-lengkap s Akhir persyaratan unit dan desain akhir, membangun akhir membangun, dan melakukan tes unit, subsistem, sistem, dan penerimaan

2.2 PROJECT STAKEHOLDERS

Stakeholder proyek adalah individu dan organisasi yang secara aktif terlibat dalam proyek ,atau siapa yang berkepentingan . hasilnya bisa berupa dampak yang positive dan negative tergantung dari eksekusinya atau penyelesaiannya . mereka juga mungkin memiliki pengaruh atas proyek dan hasilnya. Tim manajemen proyek harus mengidentifikasi saham yang di pegangnya , itu menentukan kebutuhan mereka,  kemudian mengelola dan mempengaruhi sahamnya untuk memastikan proyeknya berjalan dengan baik . Identifikasi stakeholder sering sangat sulit. Sebagai contoh, adalah seorang pekerja perakitan yang masa depannya mempekerjakan pemerintah tergantung pada hasil proyek desain produk baru stakeholder?
kunci setiap proyek pada Stakeholder  meliputi:
•         Manajer Proyek-individu yang bertanggung jawab untuk mengelola proyek tersebut.
•         Pelanggan-individu atau organisasi yang akan menggunakan produk proyek. Mungkin ada beberapa lapisan pelanggan. Sebagai contoh, pelanggan untuk produk farmasi baru mungkin termasuk dokter yang meresepkannya, pasien yang menerimanya, dan asuransi yang membayar untuk itu. Dalam beberapa aplikasi daerah, pelanggan dan pengguna adalah sama, sementara di lain pelanggan mengacu pada entitas membeli hasil proyek dan pengguna adalah mereka yang secara langsung akan menggunakan produk proyek.
•         Pertunjukan organisasi-perusahaan yang karyawan yang paling langsung terlibat dalam melakukan pekerjaan proyek.
•         Proyek anggota tim-kelompok yang melakukan pekerjaan proyek.
•         Sponsor-individu atau kelompok dalam atau di luar orga-performingnization yang menyediakan sumber daya keuangan, dalam bentuk tunai atau barang, untuk proyek.
Selain ini, ada banyak nama yang berbeda dan kategori proyek stakeholder-internal dan eksternal, pemilik dan penyandang dana penjual dan kontraktor, anggota tim dan keluarga mereka, instansi pemerintah dan media, indi- vidual warga, organisasi lobi permanen atau temporer, dan masyarakat  besar. Penamaan atau pengelompokan stakeholder terutama bantuan untuk mengidentifikasi yang individu dan organisasi melihat diri mereka sebagai stakeholder. Stake- pemegang peran dan tanggung jawab mungkin tumpang tindih, seperti ketika sebuah perusahaan rekayasa pro- vides pembiayaan untuk pabrik yang adalah merancang

Mengelola harapan pemangku kepentingan mungkin sulit karena para pemangku kepentingan sering memiliki tujuan yang sangat berbeda yang mungkin datang ke dalam konflik. Sebagai contoh:
•         Manajer departemen yang telah meminta manajemen baru infor- Sistem mation mungkin menginginkan biaya rendah, arsitek sistem dapat menekankan-tech keunggulan nical, dan kontraktor pemrograman mungkin paling tertarik memaksimalkan keuntungan.
•         Wakil presiden penelitian di sebuah perusahaan elektronik dapat mendefinisikan produk baru Keberhasilan sebagai negara-of-the-art teknologi, wakil presiden manufaktur dapat mendefinisikannya sebagai kelas dunia praktek, dan wakil presiden pemasaran mungkin terutama berkaitan dengan sejumlah fitur baru.
•         Pemilik proyek pengembangan real estat mungkin terfokus pada tepat waktu per- kinerja, badan lokal dapat keinginan untuk memaksimalkan penerimaan pajak, yang kelompok lingkungan hidup mungkin ingin untuk meminimalkan dampak lingkungan yang merugikan, dan warga sekitar dapat berharap untuk merelokasi proyek tersebut.
Secara umum, perbedaan antara atau di antara para pemangku kepentingan harus diselesaikan dalam mendukung pelanggan. Ini tidak, bagaimanapun, berarti bahwa kebutuhan dan expec-
sultasi pemangku kepentingan lainnya dapat atau harus diabaikan. menemukan yang tepat
resolusi perbedaan tersebut dapat menjadi salah satu tantangan utama dari proyek
manajemen.


2.3 PENGARUH  ORGANISASI

Proyek biasanya bagian dari organisasi yang lebih besar daripada korporasi proyek, instansi pemerintah, institusi layanan kesehatan, badan-badan internasional, asosiasi professional, dan lain-lain. Bahkan ketika proyek ini adalah organisasi (Usaha patungan, kemitraan), proyek tersebut masih akan dipengaruhi oleh organisasi atau organisasi yang mengaturnya. Jatuh tempo dari organisasi dengan hormat untuk sistem manajemen proyek, budaya, gaya, struktur organisasi, dan proyek kantor manajemen juga dapat mempengaruhi proyek. Bagian berikut menggambarkan aspek-aspek kunci dari struktur organisasi yang lebih besar yang mungkin mempengaruhi proyek.

2.3.1 Sistem Organisasi
Organisasi berbasis proyek adalah mereka yang operasi terutama terdiri dari proyek. Organisasi-organisasi ini terbagi dalam dua kategori:
•         Organisasi yang memperoleh pendapatan mereka terutama dari proyek-proyek untuk melakukan lain-arsitektur perusahaan, perusahaan rekayasa, konsultan, konstruksi con-traktor, kontraktor pemerintah, lembaga swadaya masyarakat, dll
•         Organisasi yang telah mengadopsi manajemen oleh proyek-proyek (lihat Bagian 1.3).
Organisasi-organisasi ini cenderung memiliki sistem manajemen di tempat untuk memfasilitasi manajemen proyek. Sebagai contoh, sistem keuangan mereka sering khusus dirancang untuk akuntansi, pelacakan pelaporan, dan simultan proyek.
Nonproyek-organisasi berbasis sering kekurangan sistem manajemen yang dirancang untuk Proyek dukungan perlu efisien dan efektif. Tidak adanya proyek-berorientasi sistem biasanya membuat manajemen proyek lebih sulit. Dalam beberapa kasus, non- berbasis proyek organisasi akan memiliki departemen atau subunit lainnya yang beroperasi sebagai proyek berbasis organisasi dengan sistem untuk mencocokkan.
Tim manajemen proyek harus sadar bagaimana organisasi sistem ini mempengaruhi proyek. Sebagai contoh, jika organisasi imbalan yang fungsi- internasional manajer untuk pengisian waktu staf untuk proyek-proyek, maka manajemen proyek Tim mungkin perlu untuk menerapkan kontrol untuk memastikan bahwa anggota staf yang ditugaskan adalah digunakan secara efektif pada proyek.

2.3.2 Organisasi Budaya dan Gaya
Sebagian besar organisasi telah mengembangkan budaya yang unik dan describable. Ini membangun struktur yang tercermin dalam nilai-nilai bersama mereka, norma, keyakinan, dan harapan, dalam mereka kebijakan dan prosedur, dalam pandangan mereka tentang hubungan otoritas, dan di banyak faktor lainnya. Budaya organisasi sering memiliki pengaruh langsung terhadap proyek. Sebagai contoh:
•         Sebuah tim mengusulkan pendekatan yang tidak biasa atau berisiko tinggi lebih mungkin untuk mengamankan persetujuan organisasi agresif atau kewirausahaan.
•         Seorang manajer proyek dengan gaya yang sangat partisipatif cenderung menghadapi prob- terhindarkan dalam sebuah organisasi hierarkis kaku, sementara manajer proyek dengan gaya otoriter akan sama-sama ditantang dalam sebuah organisasi partisipatif.

2.3.3 Struktur Organisasi
Struktur organisasi melakukan seringkali menghambat ketersediaan atau syarat-syarat yang menjadi sumber daya yang tersedia untuk proyek. Organisatoris struktur dapat dicirikan sebagai mencakup spektrum dari fungsional ke proyektor, dengan berbagai struktur matriks di antara. Gambar 2-6 menunjukkan proyek terkait karakteristik jenis utama dari struktur organisasi perusahaan. Organisasi proyek dibahas dalam Bagian 9.1, Perencanaan Organisasi.
Organisasi fungsional klasik, yang ditunjukkan pada Gambar 2-7, merupakan sebuah hirarki di mana setiap karyawan memiliki satu unggul yang jelas. Anggota staf dikelompokkan oleh khusus, seperti seperti produksi, pemasaran, teknik, dan akuntansi di tingkat atas, dengan insinyur- neering kemudian dibagi lagi menjadi organisasi fungsional yang mendukung bisnis dari organisasi yang lebih besar (misalnya, mekanik dan listrik). Fungsional organisasi- tions masih memiliki proyek, tapi ruang lingkup yang dirasakan proyek ini terbatas pada batas-batas fungsi: departemen teknik dalam fungsional organisasi- tion akan melakukan tugasnya independen dari departemen manufaktur atau pemasaran.
Sebagai contoh, ketika sebuah pengembangan produk baru dilakukan dalam murni fungsi-nasional organisasi, tahap desain sering disebut proyek desain dan termasuk hanya departemen teknik staf. Jika pertanyaan tentang manufaktur muncul, mereka melewatkan hirarki ke kepala departemen, yang berkonsultasi dengan kepala manufaktur departemen. Kepala departemen teknik kemudian melewati menjawab kembali ke hirarki ke manajer proyek rekayasa.
Pada ujung spektrum adalah organisasi projectized, ditampilkan dalam Gambar 2-8. Dalam sebuah organisasi projectized, anggota tim sering collocated. Sebagian besar sumber daya organisasi terlibat dalam pekerjaan proyek, dan proyek manajer memiliki banyak kemerdekaan dan otoritas. Projectized organisasi sering disebut unit organisasi departemen, tetapi kelompok-kelompok baik melapor langsung kepada manajer proyek atau memberikan layanan dukungan kepada berbagai proyek.
Matrix organisasi, seperti yang ditunjukkan pada Gambar 2-9 melalui 2-11, merupakan perpaduan antara karakteristik fungsional dan projectized. Matriks yang lemah mempertahankan banyak karakteristik organisasi fungsional, dan peran manajer proyek lebih yang dari koordinator atau ekspeditur daripada manajer. Dalam cara yang sama, matriks yang kuat memiliki banyak karakteristik projectized organisasi-penuh-waktu manajer proyek dengan otoritas yang cukup dan penuh- waktu administrasi staf proyek.
Sebagian besar organisasi modern yang melibatkan semua struktur di berbagai tingkatan, seperti ditunjukkan pada Gambar 2-12. Misalnya, bahkan fundamental fungsional organisasi-tion dapat membuat sebuah tim proyek khusus untuk menangani sebuah proyek penting. Seperti tim mungkin memiliki banyak karakteristik dari sebuah proyek dalam organisasi projectized. Tim mungkin termasuk penuh-waktu staf dari departemen fungsional yang berbeda, dapat mengembangkan menetapkan sendiri prosedur operasi, dan dapat beroperasi di luar standar, struktur pelaporan formal.

2.3.4 Proyek Kantor
Ada berbagai manfaat untuk apa yang merupakan kantor proyek. Sebuah kantor proyek dapat beroperasi pada kontinum dari menyediakan fungsi dukungan kepada manajer proyek di bentuk pelatihan, software, template, dll untuk benar-benar bertanggung jawab atas hasil proyek.

2.4 KUNCI KETERAMPILAN MANAJEMEN UMUM

Manajemen umum adalah subjek yang luas yang berhubungan dengan setiap aspek yang mengelola
kemajuan perusahaan. Di antara topik lain, meliputi:
•         Keuangan dan akuntansi, penjualan dan pemasaran, penelitian dan pengembangan, dan manufaktur dan distribusi.
•         Strategis perencanaan, perencanaan taktis, dan perencanaan operasional.
•         Organisasi struktur, perilaku organisasi, administrasi kepegawaian, kompensasi, manfaat, dan jalur karir.
•         Mengelola hubungan kerja melalui pengawasan motivasi,, delegasi, team building, manajemen konflik, dan teknik lainnya.
•         Mengelola diri melalui manajemen waktu pribadi, manajemen stres, dan teknik lainnya.
Keterampilan manajemen umum memberikan banyak landasan untuk membangun proyek keterampilan manajemen. Mereka sering penting bagi manajer proyek. Pada setiap proyek yang diberikan, keterampilan dalam sejumlah bidang manajemen umum mungkin dibutuhkan. Bagian ini menjelaskan keterampilan manajemen kunci umum yang sangat mungkin mempengaruhi sebagian besar proyek dan yang tidak tercakup di tempat lain dalam dokumen ini. 

Keterampilan ini didokumentasikan dengan baik dalam literatur manajemen umum, dan mereka aplikasi pada dasarnya sama pada sebuah proyek.
Ada juga keterampilan manajemen umum banyak yang relevan hanya pada cer- pertahankan proyek atau aplikasi dalam bidang tertentu. Misalnya keamanan, anggota tim sangat penting di hampir semua proyek konstruksi dan sedikit perhatian pada kebanyakan soft- gudang proyek-proyek pembangunan.

2.4.1 Leading
Kotter (4) membedakan antara memimpin dan mengelola sementara menekankan perlu untuk kedua: satu tanpa yang lain yang kemungkinan akan menghasilkan hasil yang buruk. Dia mengatakan pengelolaan yang terutama berkaitan dengan "hasil kunci konsisten memproduksi diharapkan oleh para pemangku kepentingan, "melibatkan saat memimpin:
•         Membentuk arah-mengembangkan kedua visi masa depan dan strategi untuk memproduksi perubahan yang diperlukan untuk mencapai visi itu.
•         Menyelaraskan orang-mengkomunikasikan visi dengan kata-kata dan perbuatan kepada semua orang kerjasama yang mungkin diperlukan untuk mencapai visi tersebut.
•         Memotivasi dan menginspirasi-membantu orang energi sendiri untuk mengatasi hambatan politik, birokrasi, dan sumber daya untuk berubah.
           Pada proyek, khususnya proyek yang lebih besar, manajer proyek umumnya diharapkan menjadi pemimpin proyek juga. Kepemimpinan tidak, bagaimanapun, terbatas  kepada manajer proyek: mungkin didemonstrasikan oleh individu yang berbeda pada waktu yang berbeda selama proyek. Kepemimpinan harus ditunjukkan di semua tingkat proyek (proyek kepemimpinan, kepemimpinan teknis, dan tim kepemimpinan).

2.4.2 Berkomunikasi
Berkomunikasi melibatkan pertukaran informasi. Pengirim bertanggung jawab untuk membuat informasi yang jelas, ambigu, dan lengkap sehingga penerima dapat menerima dengan benar. Penerima bertanggung jawab untuk memastikan bahwa informasi yang diterima secara keseluruhan dan dipahami dengan benar. Berkomunikasi memiliki banyak dimensi:
•         Tertulis dan lisan, mendengar dan berbicara.
•         Internal (dalam proyek) dan eksternal (kepada pelanggan, media, masyarakat, dll).
•         Formal (laporan, briefing, dll) dan informal (memo, ad hoc percakapan, dsb).
•         Vertikal (atas dan bawah organisasi) dan horisontal (dengan rekan-rekan dan organisasi mitra).
          Keterampilan manajemen umum berkomunikasi berkaitan dengan, tapi tidak sama dengan, Proyek Manajemen Komunikasi (dijelaskan dalam Bab 10). Berkomunikasi adalah subjek yang lebih luas dan melibatkan tubuh besar pengetahuan yang tidak unik untuk konteks proyek, misalnya:
•         Sender-receiver model-umpan balik loop, hambatan komunikasi, dll
•         Pilihan media-kapan harus berkomunikasi secara tertulis, kapan harus berkomunikasi secara lisan, ketika menulis sebuah memo resmi, kapan harus menulis laporan resmi, dll

2.4.3 Negosiasi
Negosiasi melibatkan berunding dengan orang lain untuk berdamai dengan mereka atau mencapai kesepakatan. Perjanjian dapat dinegosiasikan secara langsung atau dengan bantuan, mediasi dan arbitrase adalah dua jenis negosiasi dibantu.
          Negosiasi terjadi sekitar banyak masalah, di banyak kali, dan di berbagai tingkatan proyek. Selama proyek yang khas, staf proyek cenderung untuk bernegosiasi untuk setiap atau semua hal berikut:
•         Lingkup, biaya, dan tujuan jadwal.
•         Perubahan ruang lingkup, biaya jadwal, atau.
•         Kontrak syarat dan kondisi.
•         Tugas.
•         Sumber daya.

2.4.4 Pemecahan Masalah
Pemecahan masalah melibatkan kombinasi dari definisi masalah dan pengambilan keputusan.
          Definisi masalah memerlukan membedakan antara penyebab dan gejala. Masalah mungkin internal (karyawan kunci dipindahkan ke proyek lain) atau eksternal (izin yang diperlukan untuk mulai bekerja tertunda). Masalah mungkin teknis (perbedaan pendapat tentang cara terbaik untuk merancang produk), manajerial (kelompok fungsional tidak memproduksi sesuai rencana), atau interpersonal (kepribadian atau gaya bentrokan).
          Pengambilan keputusan meliputi analisis masalah untuk mengidentifikasi solusi yang layak, dan kemudian membuat pilihan dari antara mereka. Keputusan dapat dibuat atau diperoleh (dari pelanggan, dari tim, atau dari manajer fungsional). Setelah dibuat, keputusan harus dilaksanakan. Keputusan juga memiliki unsur waktu untuk mereka-yang "benar" keputusan tidak mungkin "terbaik" keputusan jika dibuat terlalu dini atau terlalu terlambat.

2.4.5 Mempengaruhi Organisasi
Mempengaruhi organisasi melibatkan kemampuan untuk Hal ini membutuhkan pemahaman dari kedua struktur formal dan informal dari semua organisasi yang terlibat-organisasi melakukan, pelanggan, mitra, kontraktor, dan banyak lainnya, yang sesuai "menyelesaikan sesuatu.". Mempengaruhi organisasi juga membutuhkan pemahaman tentang mekanisme kekuasaan dan politik.
          Kedua kekuasaan dan politik yang digunakan di sini dalam pengertian positif mereka. Pfeffer (5) mendefinisikan kekuasaan sebagai Dengan cara yang sama, Eccles dkk "kemampuan potensial untuk mempengaruhi perilaku, untuk mengubah jalannya peristiwa, untuk mengatasi resistensi, dan untuk mendapatkan orang untuk melakukan hal-hal yang mereka tidak akan lakukan jika.". (6) mengatakan bahwa "politik adalah tentang mendapatkan tindakan kolektif dari sekelompok orang yang mungkin memiliki kepentingan yang berbeda. Ini adalah tentang menjadi bersedia untuk menggunakan konflik dan gangguan kreatif. Arti negatif, tentu saja, berasal dari kenyataan bahwa mencoba untuk mendamaikan hasil kepentingan dalam perebutan kekuasaan dan permainan organisasi yang kadang-kadang dapat mengambil hidup secara menyeluruh tidak produktif mereka sendiri."

2.5 LINGKUNGAN EKONOMI KEMASYARAKATAN

Seperti manajemen umum, pengaruh ekonomi-sosial meliputi satu jangkauan luas dari topik dan emisi. Tim manajemen proyek harus memahami bahwa kondisi arus dan kecenderungan di dalam area ini mungkin memiliki efek besar pada proyek: kecil perubahan di sini dapat diterjemahkan, biasanya dengan jeda waktu, ke dalam pergolakan dahsyat di dalam proyek itu sendiri. Dari beberapa pengaruh ekonomi-sosial potensial, beberapa kategori utama yang sering mempengaruhi proyek dideskripsikan dengan singkat di bawah.

2.5. 1 Standar dan peraturan
Organisasi Intemasional atas Standardisasi (ISO) dibedakan antara standar dan peraturan sebagai berikut (7 ):
•         standar adalah "disetujuinya dokumen oleh suatu badan yang diakui, yang menyediakan, atas penggunaan umum dan berulang, ketentuan, petunjuk, atau karakteristik atas produk, proses atau jasa yang pemenuhannya tidak wajib." Ada banyak standar yang digunakan meliputi segala sesuatu dari stabilitas termal cairan hidrolik dengan ukuran disket komputer.
•         peraturan adalah satu "dokumen, yang menetapkan karakteristik produk, proses atau jasa, termasuk ketetapan administratif yang diterapkan, dengan kepatuhan yang diberi kekuasaan adalah." Kode membangun adalah contoh dari peraturan.
perawatan harus dipergunakan di dalam mendiskusikan standar dan peraturan sejak terdapat sebuah daerah abu-abu yang luas di antara kedua-duanya; antara lain:
•         Standar sering dimulai sebagai petunjuk yang mendeskripsikan pendekatan yang disukai, dan kemudian, dengan adopsi luas, menjadi peraturan de fakto (misalnya., penggunaan dari Analisa Jalur Kritis untuk menjadwalkan proyek konstruksi utama).
•         Kepatuhan dapat diamanatkan pada taraf berbeda (misalnya., oleh lembaga pemerintah, oleh manajemen dari organisasi pelaksanaan, atau dengan team manajemen proyek).
Bagi kebanyakan proyek, standar dan peraturan (oleh definisi apapun) adalah terkenal, dan proyeksikan rencana dapat mencerminkan pengaruh mereka. Di dalam kasus lain, pengaruh tersebut tidak diketahui atau tidak pasti dan harus dipertimbangkan dalam Manajemen Risiko Proyek (dideskripsikan di dalam Bab 11).

2.5. 2 Internationalisasi
semakin banyak organisasi terlibat dalam pekerjaan yang mencakup batas nasional , semakin banyak proyek mencakup batas nasional juga. Sebagai tambahan terhadap keprihatinan tradisional dari bidang lapangan, biaya, waktu, dan mutu, team manajemen proyek juga harus mempertimbangkan akibat perbedaan zona waktu, libur nasional dan regional, laksanakan perjalanan untuk kebutuhan pertemuan secara langsung , fungsi dari teleconferencing, dan sering mudah menguap perbedaan politis.

2.5. 3 Pengaruh Budaya
Budaya adalah "keseluruhan dari pola perilaku sosial yang terpancar , seni, kepercayaan, institusi, dan semua produk lain dari pekerjaan manusia dan pikiran" (8 ). Setiap Proyek harus beroperasi dalam konteks satu atau lebih norma-norma budaya. Pengaruh dari Area ini meliputi politik, ekonomi, demografis, bidang pendidikan, etika, etnis, agama, dan area lain dari praktek, kepercayaan, dan sikap yang mempengaruhi cara orang dan organisasi saling berinteraksi.

 2.5. 4 Sosial-Ekonomi-Lingkungan Keberlanjutan
Hampir semua proyek yang direncanakan dan diterapakan di dalam masyarakat, ekonomi, dan hubungan lingkungan, dan sengaja dan tidak sengaja memiliki dampak positif dan / atau dampak negatif. Organisasi semakin bertanggungjawab atas dampak akibat proyek (misalnya., hancurnya lokasi arkeologis di dalam satu proyek pembangunan jalan ), seperti halnya atas dampak dari proyek pada orang-orang, ekonomi, dan lingkungan lama setelah ini telah dilengkapi (misalnya., satu jalan kendaraan dapat memudahkan akses dan hancurnya lingkungan yang dulu murni).


 
sumber :
Project Management Institute, “A Guide To The Project Management Body Of Knowledge”, Newton Square, USA, 1996.

Read More