Manajemen Proyek

Kemajuan dan perkembangan dalam perindustrian telah mendorong untuk melakukan beberapa aspek pengelolaan dan manajemen yang dituntut memiliki kinerja, kecermatan, ekonomis, kecepatan, ketepatan, ketelitian serta keamanan yang tinggi dalam mengelola harapan . Manajemen suatu kegiatan baik investasi kecil maupun besar  dalam skala proyek memerlukan suatu metode yang sudah teruji, sumber daya yang berkualitas dan penerapan ilmu pengetahuan yang tepat.
Proyek merupakan gabungan seperti sumber daya manusia, material, machine dan modal/biaya dalam suatu wadah organisasi sementara untuk mencapai tujuan dalam sasaran dan tujuan. Sifat dari suatu proyek adalah bersifat sementara dan dalam kurun waktu yang dibatasi. Suatu proyek biasanya terjadi karena suatu keperluan yang mendesak karena tuntutan pengembangan dari suatu lokasi tertentu.
Jenis proyek  dikelompokkan berdasarkan komponen kegiatan utama dan hasil akhirnya, yaitu :

1. Proyek konstruksi. Hasilnya berupa pembangunan jembatan, gedung, jalan raya, dsb.
2. Proyek Industri Manufaktur. Kegiatannya mulai dari merancang hingga terciptanya suatu produk baru.
3. Proyek Penelitian dan Pengembangan. Melakukan penelitian dan pengembangan hingga tercuptanya sebuah produk tertentu dengan tujuan untuk memperbaiki atau meningkatkan suatu produk, pelayanan atau suatu metode tertentu.
4. Proyek Padat modal. Suatu proyek yang memerlukan modal yang besar. Misalnya pembebasan tanah, pembelian dan pengadaan suatu barang, pembangunan suatu fasilitas produksi dsb.
5. Proyek Pengembangan Produk Baru. Merupakan gabungan dari proyek penelitian dan pengembangan dengan proyek padat modal.
6. Proyek Pelayanan Manajemen. Berhubungan dengan fasilitas nonfisik atau jasa dari perusahaan. Misalnya pengembangan sistem informasi perusahaan, Peningkatan produktivitas dari karyawan, dsb.
7. Proyek Infrastruktur. Penyediaan kebutuhan masyarakat luas dalam hal prasarana transportasi, Waduk, pembangkit listrik, instalasi telekomunikasi dan penyediaan sumber air minum.

Definisi dari manajemen proyek yaitu penerapan ilmu pengetahuan, keahlian dan ketrampilan, cara teknis yang terbaik dan dengan sumber daya yang terbatas untuk mencapai sasaran yang telah ditentukan agar mendapatkan hasil yang optimal dalam hal kinerja, waktu, mutu dan keselamatan kerja. Dalam manajemen proyek, perlunya pengelolaan yang baik dan terarah karena suatu proyek memiliki keterbatasan sehingga tujuan akhir dari suatu proyek bisa tercapai. Yang perlu dikelola dalam area manajemen proyek yaitu biaya, mutu, waktu, kesehatan dan keselamatan kerja, sumberdaya, lingkungan, resiko dan sistem informasi.
Ada tiga garis besar yang dibahas dalam buku ini untuk menciptakan berlangsungnya sebuah proyek, yaitu :

1. Perencanaan
Untuk mencapai tujuan, sebuah proyek perlu suatu perencanaan yang matang. Yaitu dengan meletakkan dasar tujuan dan sasaran dari suatu proyek sekaligus menyiapkan segala program teknis dan administrasi agar dapat diimplementasikan.Tujuannya agar memenuhi persyaratan spesifikasi yang ditentukan dalam batasan waktu, mutu, biaya dan keselamatan kerja. Perencanaan proyek dilakukan dengan cara studi kelayakan, rekayasa nilai, perencanaan area manajemen proyek (biaya, mutu, waktu, kesehatan dan keselamatan kerja, sumberdaya, lingkungan, resiko dan sistem informasi.).
2. Penjadwalan
Merupakan implementasi dari perencanaan yang dapat memberikan informasi tentang jadwal rencana dan kemajuan proyek yang meliputi sumber daya (biaya, tenaga kerja, peralatan, material), durasi  dan progres waktu untuk menyelesaikan proyek. Penjadwalan proyek mengikuti perkembangan proyek dengan berbagai permasalahannya. Proses monitoring dan updating selalu dilakukan untuk mendapatkan penjadwalan yang realistis agar sesuai dengan tujuan proyek. Ada beberapa metode untuk mengelola penjadwalan proyek, yaitu Kurva S (hanumm Curve), Barchart, Penjadwalan Linear (diagram Vektor), Network Planning dan waktu dan durasi kegiatan. Bila terjadi penyimpangan terhadap rencana semula, maka dilakukan evaluasi dan tindakan koreksi agar proyek tetap berada dijalur yang diinginkan.
3. Pengendalian Proyek
Pengendalian mempengaruhi hasil akhir suatu proyek. Tujuan utama dari utamanya yaitu meminimalisasi segala penyimpangan yang dapat terjadi selama berlangsungnya proyek. Tujuan dari pengendalian proyek yaitu optimasi kinerja biaya, waktu , mutu dan keselamatan kerja harus memiliki kriteria sebagai tolak ukur. Kegiatan yang dilakukan dalam proses pengendalian yaitu berupa pengawasan, pemeriksaan, koreksi yang dilakukan selama proses implementasi.

Manajemen Risiko
Risiko  dapat  bermunculan dimana-mana,  dapat  muncul  kapansaja,  dan  sulit  untuk  dihindari.  Jika risiko  tersebut menimpa  suatu proyek, maka  proyek  tersebut  bisa mengalami kerugian  yang  signifikan.  Dalam beberapa  situasi,  risiko  tersebut  bisa mengakibatkan  terbengkalainya proyek  tersebut.  Karena  itu  risiko penting  untuk  dikelola.  Manajemen risiko  bertujuan  untuk  mengelola risiko  sehingga  proyek  tersebut  dapat bertahan,  atau  barangkali mengoptimalkan risiko (Hanafi, 2006). Selain  itu  manajemen  risiko  dapat diartikan  sebagai  suatu  sistem pengelolaan  risiko  yang  digunakan  di dalam  suatu  organisasi,  atau perusahaan,  yang  pada  dasarnya merupakan  suatu  proses  atau rangkaian  kegiatan  yang  dilakukan secara  menerus  (continue),  untuk mengendalikan  kemungkinan timbulnya  risiko  yang  membawa konsekuensi  merugikan  organisasi, atau  perusahaan  yang  bersangkutan (Saptodewo  & Soedarsono, 2000). Dan  secara  objektif, manajemen risiko  proyek  adalah bagaimana  meningkatkan kemungkinan  dan  dampak  dari kegiatan  positif  dan  mengurangi kemungkinan dan dampak dari sesuatu yang  merugikan. Manajemen  risiko pada  dasarnya  dilakukan  melalui proses-proses  tersebut  di  bawah  ini, yaitu : (PMBOK, 2004)
1.       Rencana  manajemen  risiko (Risk management planning)
2.       Identifikasi  risiko  (Risk identification)
3.        Analisa risiko secara kualitatif (Qualitative risk analysis)
4.        Analisa  risiko  secara kuantitatif  (Quantitative  risk analysis)
5.       Rencana  respon  risiko  (Risk response planning)
6.       Pengawasan dan kontrol risiko (Risk monitoring and control)
Proses Manajemen Risiko
a. Identifikasi  Risiko  (Risk Identification)
Identifikasi  risiko  adalah aktivitas  yang  dilakukan  untuk mempelajari  dan  memperkirakan potensi-potensi risiko yang terkandung dalam  suatu  proses  kegiatan. Sedangkan  potensi  risiko  adalah  sifat atau  karakteristik  yang  dapat menimbulkan  kerugian  terhadap perusahaan pada saat risiko itu terjadi. Tujuan  dari  identifikasi  risiko  adalah untuk  memastikan  bahwa  sumber risiko  dan  potensi  risiko  telah diidentifikasi  dan  dievaluasi  sesuai dengan  kepentingan  dan  prosedur yang ada (PT. Waskita Karya, 2004).
Sedangkan  menurut  Soeharto (1995)  identifikasi  risiko  adalah  suatu proses  pengkajian  risiko  dan ketidakpastian  yang  dilakukan  secara sistematis  dan  terus  menerus.  Agar risiko  dapat  dikelola  secara  efektif maka  langkah  pertama  adalah mengidentifikasi  jenis  risiko,  yaitu mana  yang  bersifat  risiko  usaha (business risk) dari mana yang bersifat risiko  murni,  kemudian diidentifikasikan  lagi  berdasar  potensi sumber  risiko  atau  dapat  pula berdasarkan  dampak  terhadap  sasaran proyek. Sumber  risiko dapat diartikan sebagai  faktor  yang  dapat menimbulkan  kejadian  yang  bersifat positif atau negatif.
b. Analisa Risiko
Setelah  dilakukan  tahap identifikasi  terhadap  risiko,  maka dilakukan penilaian  atau  analisis yang bertujuan  sebagai  berikut  :  (PT. Waskita Karya, 2004)
1.        Mengklasifikasikan  risiko  ke dalam  kategori  tinggi,  sedang maupun rendah
2.        Sebagai  dasar  dalam merencanakan  tindakan pengendalian yang akan dilakukan
3.       Meyakinkan bahwa ketidakpastian dan  risiko  telah  dipertimbangkan dan  telah  dimasukkan  dalam perencanaan  dan  proses pelaksanaan.
c. Rencana Respon Risiko
Rencana  respon  risiko adalah  proses  untuk  mengembangkan pilihan  dan  menentukan  tindakan untuk  memperbesar  kesempatan  dan mengurangi  tanda-tanda  akan terjadinya bahaya pada  tujuan proyek. Berikut  ini  adalah  beberapa  strategi untuk menghadapi risiko-risiko negatif atau ancaman :
a.        Menghindari (Avoid)
Menghindari  risiko  (risk avoidance)  meliputi  perubahan rencana manajemen  proyek  untuk mengurangi  ancaman-ancaman yang diakibatkan oleh risiko-risiko yang  buruk,  untuk  mengasingkan tujuan  awal  proyek  dari  dampak risiko.
b.       Memindahkan (Transfer)
Ketika seseorang atau suatu badan mentransfer  atau  mengalihkan risiko  ke  pihak  lain, mereka  akan mengalihkan  tanggung  jawab finansialnya  untuk  suatu  risiko kepada  pihak  lain  dengan membayar  jasa  tersebut, contohnya adalah asuransi.
c.        Mengurangi (Mitigate)
Mengurangi  risiko  (risk mitigation)  adalah  mengadakan pengurangan  dalam  hal kemungkinan  dan/atau  dampak dari  risiko  yang  dapat  merugikan sampai  ke  batas  yang  dapat diterima.

Manajer Proyek - Kunci Produktif Dalam Pengawasan Proyek

manajer proyek

Apa kunci untuk menangani proyek? Ada banyak cara untuk gagal dalam sebuah proyek, namun, jika manajer proyek adalah sesuai untuk menentukan penting dari manajemen proyek yang sukses, ia pasti akan muncul penuh kemenangan. Selain mengetahui bentuk siklus manajemen proyek yang Penciptaan, Merancang Proyek, Pelaksanaan dan Penutupan dan definisi semua fase dan fungsi, direktur proyek, pemimpin dalam proyek tersebut, harus mengetahui kebutuhan berikutnya.
Meskipun proyek adalah sebuah kolaborasi dari berbagai orang dengan akuisisi sendiri teknis dan spesialisasi, direktur proyek adalah orang yang memiliki mungkin untuk membawa setiap orang bersama-sama untuk bekerja dalam satu lingkungan terpadu yang utama bertujuan untuk mencapai dan melaksanakan proyek sesuai dengan spesifikasi pelanggan. Dari sudut persiapan proyek, pengendali proyek telah bertugas dan untuk menentukan keberhasilan ia harus mampu memiliki keterampilan penting tercantum di bawah ini:
Seorang penangan proyek harus menjadi pemimpin. Pada awal dari proyek tersebut, direktur proyek harus bisa mengatur rentang proyek, mengintegrasikan tujuan pembeli dan selesai menjadi rencana, membangun tim, dorongan kelompoknya, menetapkan tanggung jawab, memimpin dengan contoh dan efisien untuk mengelola tim untuk membuat hasil. kemampuan komunikasi esensial tertentu harus sebagai direktur proyek adalah suara dan jantung proyek. Dia memiliki kekuatan tunggal untuk mengikat pembeli dengan rencana, desain untuk tim, dan kelompok ke properti. Mengekspresikan tujuan dengan benar, toleransi untuk komunikasi yang terbuka mengalir akan memungkinkan sebuah tempat untuk sebuah perubahan yang diperlukan baik dan non-berisiko.
Setelah benda ini diteruskan ke tim, merancang proyek yang datang berikutnya. Seorang manajer proyek harus memiliki kemampuan dan keterampilan untuk membuat program yang sesuai dengan maksud dan tujuan. Kemampuan untuk membedakan bagian mana dari lingkup dan makna proyek primer dan apa yang tidak adalah pengetahuan tumbuh dari waktu ke waktu, pengalaman dan melimpah. Seorang direktur proyek juga harus mendengarkan kontribusi dari tim yang teknis keahlian adalah sesuatu yang selalu diambil.
Pengetahuan penting lain adalah pengetahuan organisasi. Manajer proyek harus dapat menyiapkan semua nilai, properti dan peralatan, orang, jadwal dan prosedur. Hal ini pasti akan membawa seluruh banyak prosedur dan konsentrasi dan manajer proyek harus terorganisir dengan baik akan mampu untuk mendokumentasikan semua ini. Penerapan menangani proyek perangkat lunak yang akan menyediakan aplikasi proyek pelacakan yang akan membantu penjadwalan dan jadwal acara, penganggaran, melacak dan contromanaginging, komunikasi dan proses sertifikasi harus digunakan. Bukan hanya akan ini membantu dalam mengatur semua khusus, prosedur dan dokumen, itu juga dapat dilakukan sebagai sumber lain untuk pelanggan dan kelompok untuk mengenali apa yang sedang terjadi, apa yang harus dikembangkan dan apa yang tidak lagi diperlukan. Saat ini, ada banyak kualitas perangkat lunak manajemen proyek yang tersedia di pasar bahwa seorang penangan proyek dapat memilih dari. Jika seseorang memutuskan untuk menerapkan ini sebagai salah satu alat-Nya, kemudian membuat tertentu ke dalam nama turun apa adalah aplikasi yang seharusnya mempunyai yang akan memenuhi klaim khusus Anda.
Terakhir namun tidak sedikit, seorang direktur pengelola proyek harus memiliki akuisisi untuk memeriksa dan melacak keseluruhan proyek. Ini berarti bahwa penangan proyek harus selalu sadar akan keadaan desain untuk menghindari kesalahan fatal. Modifikasi, perubahan dalam metode dan anggaran, perjuangan dalam tim, kekhawatiran klien, dan seorang direktur pengelola proyek harus mampu terampil menangani dan karena itu menangani dengan. Seorang penangan proyek yang melakukan penelusuran proyek terus akan diberikan gambaran tentang perkembangan proyek.
Jason Westland telah berada di industri manajemen proyek selama 15 tahun terakhir berurusan dengan proyek senilai lebih dari 2 miliar dolar. Dia saat ini telah menerbitkan buku baru yang disebut "Sebuah Proyek Manajemen Siklus Hidup" dan fitur proyek sendiri perusahaan manajemen software. Jika Anda ingin mengamati lebih lanjut tentang Manajemen Proyek Web kunjungi website di www.gbaconsultant.co.id

Tips Menggunakan Waktu bagi Manajer

Dalam dunia yang penuh kesibukan, musuh seorang manajer adalah pemborosan waktunya sendiri. Sering seorang manajer kehilangan kendali pada waktunya. Waktu dan hari terasa berlalu demikian cepat. Banyak pekerjaan yang tidak kunjung selesai. Inilah beberapa poin penting bagi seorang manajer untuk mengefektifkan penggunaan waktunya:

* Buat daftar pekerjaan hari ini, Hasilnya apa, bukan kegiatannya. Misalnya \"Menyelesaikan draf kontrak dengan PT.A.\" bukan \"Membuat draft kontrak \" yang belum tahu selesainya dan hasilnya kapan. Kalau bisa daftar pekerjaan besok disusun hari ni sebelum pulang.
* Sentuh suatu pekerjaan sekali saja seminimal mungkin. Menulis sesuatu usahakan selesai. Terima email baca sekali langsung disimpan, direspon, dimasukkan daftar penting, atau dihapus. Yang tidak perlu dihapus.
* Sisihkan waktu cukup beberapa jam untuk pekerjaan-pekerjaan serius. Ada pekerjaan yang lebih baik demikian daripada sambil kerja lain dan tidak kunjung selesai.
* Rapat - Susun agenda, pilih yang datang selektif supaya diskusi tidak kemana-mana, pilih tempat dan waktu yang baik, misalnya rapat jam 11 sebelum makan ataui sebelum jam pulang biasanya lebih cepat selesai daripada yang dijadwalkan jam 8 pagi. Hasilnya juga sering sama.
* Bagi yang beruntung punya, asisten atau sekretaris bisa diminta membantu penyusunan jadwal harian sekaligus mengingatkan. Diingatkan sering lebih baik daripada dibiarkan dengan kegiatan sendiri.

IT Project Governance and PRINCE2 Project Management

In today's fast-changing information economy, IT project governance has emerged as one of the most vital corporate responsibilities. The relentless pressure to innovate whilst simultaneously driving down costs means that organisations are increasingly "betting the farm" on the successful development and deployment of new IT systems. However, the business environment now evolves so quickly that the original assumptions on which projects were based can often become fatally undermined prior to the projects completion. With technology at the heart of most businesses, the ability to maintain tight executive and board control over such projects throughout their lifecycle has become a deciding factor in determining which businesses thrive and which founder. In response to this challenge, PRINCE2 project management has emerged as the world's leading methodology for ensuring that IT projects stay on track and deliver real value.
No large scale or business critical project should ever be managed on a standalone basis. The need to involve and secure buy-in from functions right across the organisation means that a project governance approach is essential. While project management is the key discipline within this, project governance is broader in scope and has six interlinked objectives:

1. Ensuring real business value through project and business alignment.
2. Controlling costs through centralisation.
3. Maximising resource allocation, particularly of high value resources.
4. Risk management through portfolio balancing.
5. Uniform application of best practice.
6. Organisational coherence.

IT decisions expose an organisation to significant risks - financial, operational and competitive - so it is essential that project governance be a concern for the board as a whole, rather than any one individual. The board must insist that project risks are assessed within the organisation's strategic planning and risk management framework and ensure that the right investment and management decisions are made, so that competitive advantage can be enhanced and measurable business value delivered.
The board's project governance responsibilities can be summarised as follows:

• To approve product initiation, manage the project portfolio and pull the plug on any underperforming projects.
• To make one or more non-executive board members specifically responsible for overseeing project governance. They must have independent and informed oversight of progress on all business IT projects - including attending program (or large project) board meetings.
• To ensure clear accountability at all levels, with detailed, rigorously tested project plans based on a critical path analysis with clearly identified critical success factors, regular milestones and "go/no go" checkpoints.
• To ensure that every project proposal contains a full business case with a fully costed estimate that can stand up to independent audit, with clearly stated assumptions that can withstand rigorous analysis.
• To manage all IT related projects as part of a portfolio.
• To adopt and deploy a recognised project management methodology.
• To adopt a clearly defined risk management plan at programme and project level that reflects corporate level risk treatment requirements.
• To institute a monitoring framework to inform the board of progress and provide an early alert of divergence or slippage in any of the critical success factors.
• To commit funding only on a phased basis.
• To ensure that internal audit is capable and accountable directly to the board for providing regular, timely and unambiguous reports on project progress, slippage, budget, requirements specification and quality requirements. Where there is project divergence the board should not release further funds until the cause of the divergence has been fully dealt with.

In selecting a project management methodology the organisation needs to choose an approach that is appropriate to its project objectives and development environment. By far the most popular methodology is PRINCE2, the successor to PRINCE (Projects in Controlled Environments), which was developed by the UK Office of Government Commerce. While PRINCE was originally developed for IT projects, PRINCE2 project management has incorporated substantial feedback and is now a generic, best-practice approach for all types of projects. Since its introduction in 1989, PRINCE2 project management has become widely used in both the public and private sectors and is now a de facto global standard.
PRINCE2 project management uses a structured methodology, which means managing a project in a logical and organised way, following clearly defined steps and well-understood roles and responsibilities. It perfectly matches the requirements of a project governance regime by delivering the following attributes to any project:

• A controlled and organised start, middle and end
• Regular reviews of progress against plan and against the business case
• Flexible decision points
• Automatic management control of any deviations from the plan
• The involvement of management and stakeholders at the right time and in the right place during the project
• Good communications channels between the project, project management and the rest of the organisation.

The effectiveness of PRINCE2 project management results from its four cornerstones, which define what a successfully managed project should be:
Planned: PRINCE2 has a series of processes that cover all of the activities needed on a project from starting up to closing down. This process-based approach provides an easily tailored and scalable method for the management of all types of project. Each process is defined with its key inputs and outputs together with the specific objectives to be achieved and activities to be carried out.
Controlled: PRINCE2 project management divides a project into manageable stages, enabling efficient control of resources and regular progress monitoring throughout. The various roles and responsibilities for managing a project are fully described and are adaptable to suit the size and complexity of the project and the skills of the organisation.
Results-driven: Project planning using PRINCE2 is product-based, which means the project plans are actually focused on delivering results and are not simply about planning when the various activities on the project will be done.
Measured: Any project using PRINCE2 is driven by the business case, which describes the organisation's justification, commitment and rationale for the deliverables or outcome. The business case is regularly reviewed during the project to ensure the business objectives, which often change during the lifecycle of the project, are still being met.
There are clear reasons why PRINCE2 project management has become the world's leading methodology. In addition to its best practice approach for the management of all project types, around 800 people per week take PRINCE2 project management examinations, with all training carried out by accredited organisations. It is widely used and popular in both public and private sectors and can easily be tailored to all varieties of projects in many different markets and businesses. For any organisation that is serious about managing its IT investment, PRINCE2 project management is the natural choice.
management consulting management consultant

Getting Work Done: The Human Side of Project Management

Project management is defined as the art and science of getting work done with the active co-operation of individuals and organisations who are directly or indirectly involved with the project. This includes Senior Management, Project Sponsors(s), Customers, End-users, Stakeholders, Team Members, Sub-contractors, Vendors and Consultants.
Given the reality of minimal authority and total responsibility for the outcome of the project, the Project Manager's biggest challenge consists of "Getting Work Done."
Professional project management today is subject to increased industry pressures from accelerated implementations, restructuring and downsizing, mergers and acquisitions, faster technology obsolescence, and the use of new and unproven technologies. Furthermore, the project environment itself is rapidly changing with the use of distributed and virtual teams as organisations implement new "Projectized" cultures.
The challenge for the Project Manager consists of attracting the right resources, forming a cohesive team, keeping the team motivated, meeting individual aspirations and getting the work done - all within scope, cost, time, and customer satisfaction! How should we meet the challenge of dealing with the human side of project management? Here is a checklist with the "Ten Golden Rules" to help you assess the maturity level of project management and team effectiveness in your projects. Place a check mark against each question, only if you can answer it with a confident "Yes."

Golden Rule #1: Develop a Project Organisation

1. Are there specific individuals who are identified as the Sponsor and the Customer or Client for the project?
2. Does everyone know who has the single source of responsibility for the project?
3. Is there a Project Organisation Chart with individuals identified for each role including team members and internal/external stakeholders?
4. Are the roles, responsibilities and expectations clearly defined for each individual?
5. Have the responsibilities and commitments been formally accepted by the individuals?

Golden Rule #2: Formulate a Team Purpose

1. Is there a common understanding of project objectives and deliverables among all players?
2. Are the "Vision, Purpose, Goals" of the project documented and supported by a scope definition with SMART objectives (i.e. Specific, Measurable, Achievable, Realistic and Target-driven)?
3. Is there an agreed baseline schedule with resource commitments and intermediate milestones and deliverables for the project?
4. Are the functional organisations that are impacted by the project on board with the project objectives and project plans?
5. Did team members have input into the norms, rules and processes to be followed for smooth functioning of the team?

Golden Rule #3: Scope and Sell the Project

1. Do you know who your clients are and do you have their enthusiastic support?
2. Do you have a presentation that explains the business benefits of the project, its major components, how the project will be implemented and why it takes as long as it does?
3. Do you have a Risk Management plan that you can execute if and when a major risk event occurs?
4. Do you keep your client(s) positively engaged in the project and hold regular update/review meetings with your client(s) and project team?
5. Does the Project Sponsor understand the complexity of the project and support the Project Manager in resolving problems that are outside his/her control?

Golden Rule #4: Insulate Team from Management Issues

1. Is there a process for escalating problems to management and resolving issues?
2. Does the Project Manager resolve internal team conflicts expeditiously, and stand up for the team when dealing with external influences, management and stakeholders?
3. Is the Project Manager experience/trained to effectively delegate work, coach and support the team?
4. Is the Project Manager experienced in exercising various communication tools and soft skills?
5. Is there a well defined process for decision-making within the project team and is the process working?

Golden Rule #5: Teams Optimise, Individuals Maximise

1. Does every team member clearly understand his/her deliverables, acceptance criteria, and the individuals who will be approving or accepting the deliverable?
2. Is there an agreed facilitation process for team discussion and issue resolution?
3. Are decisions arising from team meetings based on a decision making process primarily driven by consensus?
4. Are the team members excited about the project experience? Do they see it as a learning opportunity for improving their competency, knowledge and skills?
5. Is there a regularly published newsletter to communicate project and team achievements to all clients, stakeholders and the project team?

Golden Rule #6: Encourage & Facilitate Open Communication

1. Is there a formal and structured communication process in place consisting of reviews, status reports, minutes of meetings and management updates etc.?
2. Does the Communication Plan include weekly "One on One" reviews with team members?
3. Does the review process allow for discussion of potential problems and possible solutions?
4. Does the team environment genuinely believe in and encourage sharing and trust-building?
5. Do team members believe that the team is empowered to make decisions relevant to how the work is to be done (as opposed to being micro-managed)?

Golden Rule #7: Institutionalise Positive Mindset

1. Do your team members believe that their meetings are generally productive?
2. Do you invite team members to provide feedback on the content and process of the meeting so that you can continually improve the management and performance of meetings?
3. Are meeting participants willing to interact and listen effectively during your project meetings?
4. Do your meetings focus on problem resolution as opposed to assignment of blame?
5. Do you proactively ascertain the confidence and commitment of team members regularly?

Golden Rule #8: Remember the Five "R"s

1. Does the project team practice and follow through the 5Rs - Respect, Recognition, Rewards, Rest and Recreation?
2. Is the project baseline schedule realistic and based on reasonable assumptions?
3. Do the team members believe that the project goal is both challenging and achievable?
4. Do you celebrate significant achievements and milestones throughout the project life cycle?
5. Do you formally thank, congratulate and recognise team members for their specific contribution on the project?

Golden Rule #9: Implement Consistent & Predictable Processes

1. Are team members trained in the fundamentals of project management and are they familiar with the organisation's business terminology and project management methodology?
2. Do team members clearly understand the differences and context of the various methodologies used for project management, system design, systems development, proprietary solutions and IT operations, etc.?
3. Is there a clear understanding of work packages, milestones, critical path and related project dependencies among the team members?
4. Are team members trained to provide meaningful, clear and concise weekly status report?
5. Do team members have the opportunity to develop their communication and soft skills as part of the project experience?

Golden Rule #10: Transition the Team Graciously

1. Do you get a formal sign-off from the client whenever a project deliverable is approved and accepted?
2. Do you take the time to provide feedback to team members on their project performance?
3. Do team members know their responsibilities with respect to Change Requests, Enhancements, Support, Warranty and Maintenance regarding the project deliverables.
4. Do you hold formal debrief sessions including a post-implementation "Lessons Learned" review with the team following project completion?
5. Will your team members enthusiastically volunteer to be a part of your next project?

Creating successful teams requires conscious and deliberate investment of time and effort. Teams are built around four basic principles that recognise the importance of Team Structure, Team Process, Team Culture and Team Influence. Structure provides leadership and organisation. Process provides discipline and predictability for team interaction. Culture provides foundation for the team's norms and values for successful interdependence and relationships. Influence helps the team to leverage internal and external politics in a constructive way to drive the project to a successful outcome.
Teams must embrace a common purpose, and develop and follow a set of common processes based on a set of values and culture adopted by the team. The Project Manager's role in team building is to guide, coach, mentor, facilitate and direct as required to achieve the intended project outcome. The success and survival of project teams depends on understanding the human side of project management.

management consultant management project

Project Management - Risk Management

In many projects, risks are identified and analysed in a random, brainstorming, fashion. This is often fatal to the success of the project, as unexpected risks arise, which have not been assessed or planned for and have to be dealt with on an emergency basis, rather than be prepared for and defended against in a planned, measured, manner. Very early in the preparation and planning stage, it is essential that potential risks are identified, categorized and evaluated. Rather than look at each risk independently and randomly, it is much more effective to identify risks and then group them into categories, or, to draw up a list of categories and then to identify potential risks within each category. This way, common influences, factors, causes, potential impacts and potential preventative and or corrective actions, can be discussed and agreed on.
Categorising risks is a way to systematically identify the risks and provide a foundation for awareness, understanding and action. Each project will have its own structure and differences, but here are some categories that are common to most projects (to which you can add your own local, sector, or project specific, categories). I have not given deep detail here, but your project team and sponsors should be able to relate to these categories and use them in the risk assessment process. For example, with "operational resources" your team can discuss issues such as, availability, delivery timing, cost, capability, necessary conditions for operation (eg. ground, weather, light); with "stakeholder resources" your team can identify all stakeholders and list potential risks that these stakeholders may generate, such as bad publicity from the media, delays caused by community or environmental groups, delays caused by utility companies, problems with trade unions. Related risks and potential actions, must then be documented in the risk management plan and discussed at all the key stages as the project progresses. All the details and the actual action taken and the outcomes, must then be recorded and reviewed during the closure and review stage, for lessons to be learned and applied to future projects.
Here the question that most project managers ask: "how do we know if we can manage the risk, if it arises?" Often, sadly, no evaluation is carried out to determine the expertise, experience, capabilities of the team, individuals, organisations that would be required to deal with, manage that risk, if it occurred. As a result, if it did, the team may not be able to deal with it effectively, even though the initial forecast was that the risk could be managed. This happens frequently when the planning team is not the project team that manages the project and/or when key individuals in the original project team leave the team during the project and are replaced by individuals with different skills, experience and capabilities. The clear message here is that setting a risk tolerance level is a dangerous business. Each potential risk needs to be carefully, rigorously, analysed and the project team, the supporting teams and individuals, the organisation(s) involved in managing the project, all need to be evaluated to determine whether there is the capability to manage that risk successfully, should it arise. Where gaps in capability are identified, then appropriate corrective action must be taken. During the project itself, this capability must be constantly monitored and, where necessary, action taken to return the level of capability to the required level.
Conflict over resources often arise during the middle to later stages of a project, because, often unexpected other, newer demands arise which are seen as being of higher priority. This can lead to resources that were originally allocated to the project being taken away, or reduced in quantity or quality, almost certainly to the detriment of the project. The answer to this dilemma is not easy, but in essence, the project management team must include "conflict over resources during the life of the project" as a major potential risk and plan for it accordingly by securing agreements and then monitoring the situation continuously. If a dispute does arise, there is a role here for the project champion and or the client to ensure that the allocated resources are not taken away.
Fundamental to many of the issues that we discuss here is the question of who should be responsible for risk assessment and management. Too often the responsibility for risk identification, assessment and management, are left to the project team, especially once the project has started. But there are other individuals and groups, including some external stakeholders, who should be continuously monitoring particular activity and feeding back regularly to the project team leader. Some are easy to identify. They include of course, the client, the sponsor, key specialists in the project team's organisation, or organisations, the major external participants, such as emergency services, local authorities and contractors.
The easy way to identify other individuals and groups is to look at your list of stakeholders. Each one has a responsibility, to a greater or lesser degree, to help identify potential risk and give information on this to the project team. Again, the answer to managing the question of risk responsibility is to build discussion, planning and action, on this into the project planning and operational activity.
management consultant management project

ISO 31000 : 2009 Risk Management International Standard

Time until Events:

Materi
ISO Manajemen Risiko akan menjadi standar internasional untuk proses manajemen risiko. Workshop ini membantu manajemen untuk mengkaji kembali kesiapan dan kesesuaian praktik dan proses Manajemen Risiko perusahaan.
ISO (the International Organization for Standardization) adalah federasi badan standar nasional di seluruh dunia. Tugas mempersiapkan standar internasional biasanya dilaksanakan oleh ISO Technical Committee.
Standar Internasional untuk [...]
Materi ISO Manajemen Risiko akan menjadi standar internasional untuk proses manajemen risiko. Workshop ini membantu manajemen untuk mengkaji kembali kesiapan dan kesesuaian praktik dan proses Manajemen Risiko perusahaan.
ISO (the International Organization for Standardization) adalah federasi badan standar nasional di seluruh dunia. Tugas mempersiapkan standar internasional biasanya dilaksanakan oleh ISO Technical Committee.
Standar Internasional untuk manajemen risiko (ISO 31000) dimaksudkan untuk digunakan oleh berbagai stakeholders.
Banyak organisasi yang telah menerapkan praktik dan proses manajemen risiko termasuk komponen-komponen manajemen risiko dan banyak organisasi yang telah mengadopsi proses manajemen risiko formal untuk jenis-jenis risiko tertentu.

SESSI I : Improving Decision Making and Activities with Risk Management

• Pengantar
• ISO 31000: 2009 ‘RM Objectives’ (1)
• ISO 31000: 2009 ‘RM Objectives’ (2)
• Standart ini untuk siapa?
• Risiko menurut ISO 31000: 2009
• Faktor Pemicu Ketidakpastian
• Manajemen Risiko Organisasi
• Manajemen Risiko sebagai input

SESSI II: Risk Management Principles

• Value creation and value protection
• Risk Management and organizational processes
• Risk Management and decision making
• Risk Management and uncertainty
• Tailoring risk management align with
• Risk Management and cultural and people issues
• Risk Management and transparancy
• Risk Management and eksternal and internal changes

SESSI III: Risk Management System

• Pengantar
• Framework implementasi
• Framework continues improvement cycle
• Risk Management Process menurut ISO 31000
• Risk Management Information system
• Risk Management System
• Mandate and Commitment
• Peran penting dalam manajemen risiko
• Critical success factors
• Continual Improveme

1. From crisis management to risk management
2. From traditional organization to learning organization
3. From compliance to strategic tool/enabler

SESSI IV: Process for Managing Risk

• Risk management system
• Risk management process ISO 31000
• Communication and Consultation
• Establishing the Context
• Risk Assessment technic
• Swot Analysis
• Risk Register
• Risk Analysis
• Graphical presentation
• Value-at-Risk]
• Earning-at-Risk
• Peta Risiko
• Risk Evaluation
• ALARP Principle
• Risk Treatment
• Proses iterasi untuk risk treatment plan
• Types of treatment
• Type of Unpredictable risk
• Treatment plan
• Risk monitoring and review process
• Risk Evaluation

Construction Management Project Management

Using a PMO to Achieve Results in Your Agency

Government agencies continually strive to produce better results. With regular mandates and quarterly score keeping by the President's Management Agenda, agencies are constantly working to become more efficient and better spenders of taxpayer dollars. Distressingly, recent surveys have found that half of all projects exceed budget, are completed past scheduled deadlines and do not meet original business objectives. One solution to this problem that has been slow to gain popularity in the public sector is the implementation of a Project Management Office (PMO). By incorporating a successful PMO into the overall project management strategy, government agencies can reduce delivery costs, improve the quality of project deliverables, improve resource management and produce more effective results.
The Project Management Office is a unique and critical tool for the success of any agency. The PMO provides oversight for the overall management of projects and programmes within an organisation. Even though responsibilities and services will vary between agencies, the unification of all projects within one overall standard will help to improve efficiency, costs and execution of project deliverables. Currently, government employees are frustrated with the variance in project policies, standards and procedures that shift from project to project. Establishing a Project Management Office would curb this frustration and unite standards, procedures and policies to make them uniform, thus improving project processes.
  Diagram A

A. Reduce Risk	B. Keep Projects on Budget	C. Keep Projects on Time	D. Ensure Improved Project Quality
Centralised repository for shared risk	Coordinates overall resources	Sets overall policies and procedures	Operates and manages overall project tools
Centralised proactive management initiatives to combat project risk	Enterprise management of budget resources	Provides universal templates and documentation	Centralised communication management
		Enterprise management of project timelines	Provides mentoring and skill development
			Repository of best practice information

There are four common characteristics that define a Project Management Office. Diagram A highlights which benefits are directly produced from each characteristic. For example, a PMO can aid in keeping projects on budget because they coordinate the enterprise management of budget resources.
Agreeing that PMO implementation is vital to the overall future success of an agency, the next question one would ask is, "How can a Project Management Office be created within a governmental agency?"
Following the lead of the private sector, most experts agree that there is a three-step process in order to successfully implement a Project Management Office into any organisation. These three steps, which will be further analysed, are the assessing, planning and implementing.
  Diagram B

Assessing		Planning		Implementing
Define the goals of the organisation.		Define the function of the PMO and its responsibility.		Establish corporate project management methodologies.
Understand how the organisation view the PMO.		Define the staffing of the PMO.		Establish quality metrics and tools which will be the guidelines for PMO assessment.
Identify what project management methodologies, procedures and systems exist or are already planned.		Create a Project implementation plan.		Define PMO internal procedures.

Diagram B illustrates the flow path of the three phases and breaks down the actions inherent to each.
The assessment phase is the shortest phase of implementing a Project Management Office; during this phase the agency confirms its goals and understands where the PMO will lay within the organisational structure. Agency leaders should affirm the logistics of the Project Management Office by asking such questions as: "Who will the PMO report to?" "What types of project management methodologies are currently being employed in the enterprise?" or "What support does the enterprise see providing the PMO in five years?" It is important to understand that establishing a Project Management Office is a project within itself.
After making a proper assessment of the PMO within the agency, officials then begin deliberation concerning the role and responsibility of the Project Management Office. Often times dictated by tight budgets and limited resources, agencies would need to illustrate the staffing needs for the PMO. From this information a "project implementation plan" will be created. This plan will serve as the key transition from phase two to phrase three. The "project implementation plan" defines the project scope using the work breakdown structure (WBS). The plan also describes the work which needs to be performed and estimates the resources will be needed to execute that work. Using these descriptions, the plan proposes a project schedule and a budget. When this is completed, the organisation can easily transfer into the last phase, implementation.
The final phase of PMO implementation strives to guarantee success of the Project Management Office by establishing long-term measures and metrics by which results will be measured. These results will guide officials to determine the future role of the PMO and whether or not to encourage its growth and facilitate organisational adaptation. The project management methodology implemented during this phase should include language and practices that illustrate the value derived from the Project Management Office and should highlight the organisation's goal of improving deliverables and minimising risk.
Project Management Offices are an untapped tool that government agencies need to improve quality and produce better and more efficient results. Implementing PMOs can open up agencies to be beneficiaries of improved budget estimations and successful project execution. Both of which will ensure that taxpayer dollars are not being wasted. The Performance Institute understands the values that Project Management Offices can bring to any organisation and has planned the 2006 Project Management Office Summit in Arlington, VA to further the exchange of best-practices surrounding this tool.consultant management Construction Management

Project Planning in a Nutshell

Improvement happens one project at a time. But often projects fail because they are poorly planned, or even completely unplanned. This article provides an overview of why it is important to prepare a project plan. It also shows what elements a good project plan will include.

Why Create a Project Plan?

There are several reasons why one should plan carefully before starting a project:

1. The plan is a simulation of prospective project work, which allows flaws to be identified in time to be corrected.
2. The plan is a vehicle for discussing each person's role and responsibilities, thereby helping direct and control the work of the project.
3. The plan shows how the parts fit together, which is essential for co-ordinating related activities.
4. The plan is a point of reference for any changes of scope, thereby helping project managers deal with their customers.
5. The plan helps everyone know when the objectives have been reached and therefore when to stop.

Elements of a Good Project Plan

The project plan shows the "why" and the "how" of a project. A good project plan will include the following elements:

• Statement of the goal.
• Cost/benefit analysis.
• Feasibility analysis.
• Listing of the major steps to be taken.
• Timetable for completion.
• Description of the resources required (including human resources) to carry out the project.

The plan will also identify objective measures of success that will be used to evaluate the effectiveness of the proposed changes, these are sometimes called the "deliverables" of the project.

Project Decomposition

Most projects important enough to have a significant impact on quality are too large to tackle all at once. Instead, large projects must be broken down into smaller projects and, in turn, into specific work elements and tasks. The process of going from project objectives to tasks is called decomposition. Project decomposition begins with the preparation of a preliminary plan. A preliminary project plan will identify, in broad high-level terms, the objectives of the project and constraints in term of time and resources. The work to be performed should be described and precedence relationships should be sketched out. Preliminary budgets and schedules will be developed. Finally, subplans will be developed for each subproject for the following:

• Control plans.
• Quality control plans.
• Cost control plans.
• Schedule control plans.
• Staffing plans.
• Material plans.
• Reporting plans.
• Other plans as deemed necessary.

These subplans are developed in parallel for the various subprojects.
Improvement happens one project at a time, but without proper planning these project may well fail to deliver their objectives.
consultant management Construction Management

The Beginning of the End: Defining Project Closure

How do you know when your part of the development race is over? Learn how to establish a clear finish line for your project!
When undertaking a software development project, an effectively designed closure plan serves as an outline of required tasks that must be carried out appropriately in order to result in successful project delivery, and adequate preparation is one significant element when it comes to ensuring a smooth transition to implementation. The closure plan must be considered at the outset of the project, as the client outlines their specific software requirements. With a detailed description of the desired end result communicated and understood, the expected capabilities and deliverables of the software are established. But as you enter the final stages of a software development project, what can be done in order to ensure that the program is completely suitable and fully primed for implementation?

Key Components

According to Joe Coley [1], "Projects that I've been involved with have been very much subject to additional needs and desires of the user community." In effect, this means that the end deliverable becomes the focus of the closure plan, that is, to ensure a high level of end user satisfaction with the software requested and therefore created. Coley has 20 years of experience in the information technology industry and offers much insight on the subject. When it comes to key components for successful closure plans, he highlights three main aspects to consider, presented below:

• Assess the project requirements. In order to determine the best course of action throughout the cycle of a project, it is necessary to first consider the scope of the project. Establishing a clear outlook and complete understanding as to the required deliverables will greatly improve the ability to adequately determine exactly what tasks must be carried out in order to meet these deliverables in an efficient and timely manner.
• Communication. While communication is always essential throughout the cycle of any project or initiative, it is imperative to establish a specific plan for obtaining end-user input, as needed and where feasible. Therefore, a key component to a successful close is establishing and maintaining open lines of communication with the appropriate groups. The end users comprise the group of those who will be utilising the software in real-time business applications; they have the critical business knowledge as to ways in which the software can be created or functionality that can be incorporated so that the result will be a valuable tool with the capability to enhance their business functions.
• Offer continuing support. When it comes to considering a focus on the continuing support needs of the end-user community, Coley cites a specific reason to do so, "There is always an expectation of continuing support in the form of application tweaks, bug fixes, and enhancements." By extending continuing support to the end users, they have more confidence in the software program as well as in their chosen developer.

What Impacts Implementation?

Each project has its own specific design layout and requirements, thereby making every delivery unique. In creating a closure plan, a key initial imperative is to clearly define the client's objectives in relation to their software needs, which should include key elements from the earlier discussion regarding the functionality and other requirements communicated by the end user. Client communication is essential from the beginning in order to have an appropriately formed program structure, ensuring that no important features are overlooked. Establishing and maintaining strong and regular communication during the early phases of the project can help to prevent last-minute additions that the client may want or later decide are necessary to incorporate into the software.
Many of these last-minute additions or necessary changes can be uncovered during the building and testing phases of the software development project. Not only can the exact capabilities of the software be established, but limitations will be identified as well. Often, it is ultimately the end user who will have the best perspective when it comes to specifying the software requirements where implementation and daily application use are concerned. It is the responsibility of the chosen software development company to determine the most effective approaches to fixes and additions, as well as to implement project resources effectively in order to do so in the most efficient and timely manner possible.
Coley highlights that another main challenge to overcome is to ensure that the technology meets the real needs of the end users, which can be addressed by having a method in place to obtain feedback from the end users regarding the software's capabilities. "Happy users a successful project makes! It's not over until the end user sings!" he says. The focus should continually be on the needs of the clients.
Writing software specific to the needs of a client can have a dramatic impact on the timeline for the program building phase. The tasks demanded of the software can become great, especially as the client delves further into their detailed notes as to individualised performance expectations. More often than not, a client may find that as the development phases continue and as they come to further understand the program's capabilities, they will want it to do more than originally expected.
Each individual program developed will present unique, specific challenges. While some of these are visible immediately, others will be uncovered throughout the process of development. The results that will be delivered at the close of the project are those that were seeded from the beginning, which is why it is so critical that effective lines of communication be established before, during, and even after the project's completion to ensure the satisfaction of the end users following implementation.

Right Resources, Right Words, Right Time

One element to consider in ensuring the development of an effective closure plan is that the employees assigned to critical tasks within the organisation must be those who are best suited for their respective positions, with appropriate, applicable knowledge and experience and necessary resources. Also, by displaying strong, confident leadership continually throughout the project cycle, a valuable manager can keep the entire staff focused on the ultimate goal of satisfying the client's requirements. This is where the communication aspect of any development plan comes into play. Project managers act as diplomats; they must establish and maintain ongoing effective communication with the client about their needs and relay this critical information to their own workers who are responsible for meeting the requirements of the software build.
The demands of the client can potentially present its own set of challenges-another reason why it is imperative to keep lines of communication open and clear. The client must feel confident that their needs are being met, and it is monumentally important for the staff creating the program to be made aware of needed changes immediately as they arise. A first-rate leader will find the appropriate balance of communications on both sides of the conference room. As Coley emphasises, "Communicate, communicate, communicate! When developing as a team, effective communication among those working on a project as well as effective communication with the customer is crucial. It's elementary, my Dear Watson."
Scheduling of appropriate tests, the build phases based on the project's demands, and the client's expectations of delivery are all important areas where an effective leader should be communicating and reacting as the circumstance dictate. It is through these efforts that the project may maintain its proper flow toward the delivery deadline.

Test...Test...Test

If appropriate testing is not carried out in accordance with end-user requirements, delivery of a project may be severely hindered. Overlooking even a seemingly simple test can lead to poor software performance. Testing the software is the most critical of the phases in a closure plan, and it must be done throughout the build of the software.
As with any project, there's always a degree of variable or unknowns that will occur and must be overcome. By testing regularly, from the early stages through to the end of the project, you are addressing the risk of potential errors and ensuring a timely delivery for a satisfied client.
When it comes to determining the degrees and stages of testing to be carried out throughout a project, Coley encourages first considering the nature of the project itself. "Is the project the result of a detailed specification prepared well in advance of coding and basically a design pretty much cast in stone? If there is pretty much a hard and fast design to which you must adhere, then certainly as one enters the closing phases of the project, testing to determine adherence to all specifications is critical," he asserts. "I believe this often is not the case, perhaps because there is too much to test, so testing is not performed completely , with reliance instead placed on the testing done throughout the creative process and only minimal 'final' testing."
In an environment where a client requests the creation of software suited specifically to their unique business structure, Coley uses his experience to suggest, "This kind of project requires the most extensive testing. Testing throughout the creative process should be applied consistently, and the affects of the changes/additions of new or newly coded functionality should be tested thoroughly as the project progresses. This extensive testing often conflicts with unrealistic schedules and often is not completed," Coley notes.
"I believe that all too often, the challenges of testing incorporated changes and/or additions becomes more than a development team can handle effectively. In my opinion, the best testers are the end users themselves. Closing phases of a project are smoother with more user input," he adds. "I realise that not all projects can include user input and that getting user input itself can be a huge challenge." However, obtaining their input during any project that allows for it makes such communication an invaluable resource.

Success from Beginning to End

It is essential to be prepared throughout the entire life cycle of a software development project, and an important element of preparation is to have established an insightful closure plan. In order to create a successful closure plan, key components to consider include communication both among the team and with the client, testing throughout the life of the project, and clearly defined expected results from the client at the outset as to how they wish the software to perform.
These components, however, are unique to each project and must be considered on a individual basis; while there may be similarities among projects, what may have worked well during a project in the past might not be best suited for a current project. Establishing and maintaining a plan with the end user in mind makes for a smoother transition and successful close of a software development project.
consultant management manajemen konstruksi

10 Golden Rules of Project Risk Management

The benefits of risk management in projects are huge. You can gain a lot of money if you deal with uncertain project events in a proactive manner. The result will be that you minimise the impact of project threats and seize the opportunities that occur. This allows you to deliver your project on time, on budget and with the quality results your project sponsor demands. Also your team members will be much happier if they do not enter a "fire fighting" mode needed to repair the failures that could have been prevented.
This article gives you the 10 golden rules to apply risk management successfully in your project. They are based on personal experiences of the author who has been involved in projects for over 15 years. Also the big pile of literature available on the subject has been condensed in this article.

Rule 1: Make Risk Management Part of Your Project

The first rule is essential to the success of project risk management. If you don't truly embed risk management in your project, you can not reap the full benefits of this approach. You can encounter a number of faulty approaches in companies. Some projects use no approach whatsoever to risk management. They are either ignorant, running their first project or they are somehow confident that no risks will occur in their project (which of course will happen). Some people blindly trust the project manager, especially if he (usually it is a man) looks like a battered army veteran who has been in the trenches for the last two decades. Professional companies make risk management part of their day to day operations and include it in project meetings and the training of staff.

Rule 2: Identify Risks Early in Your Project

The first step in project risk management is to identify the risks that are present in your project. This requires an open mind set that focuses on future scenarios that may occur. Two main sources exist to identify risks, people and paper. People are your team members that each bring along their personal experiences and expertise. Other people to talk to are experts outside your project that have a track record with the type of project or work you are facing. They can reveal some booby traps you will encounter or some golden opportunities that may not have crossed your mind. Interviews and team sessions (risk brainstorming) are the common methods to discover the risks people know. Paper is a different story. Projects tend to generate a significant number of (electronic) documents that contain project risks. They may not always have that name, but someone who reads carefully (between the lines) will find them. The project plan, business case and resource planning are good starters. Another categories are old project plans, your company Intranet and specialised websites.
Are you able to identify all project risks before they occur? Probably not. However if you combine a number of different identification methods, you are likely to find the large majority. If you deal with them properly, you have enough time left for the unexpected risks that take place.

Rule 3: Communicate About Risks

Failed projects show that project managers in such projects were frequently unaware of the big hammer that was about to hit them. The frightening finding was that frequently someone of the project organisation actually did see that hammer, but didn't inform the project manager of its existence. If you don't want this to happen in your project, you better pay attention to risk communication.
A good approach is to consistently include risk communication in the tasks you carry out. If you have a team meeting, make project risks part of the default agenda (and not the final item on the list!). This shows risks are important to the project manager and gives team members a "natural moment" to discuss them and report new ones.
Another important line of communication is that of the project manager and project sponsor or principal. Focus your communication efforts on the big risks here and make sure you don't surprise the boss or the customer! Also take care that the sponsor makes decisions on the top risks, because usually some of them exceed the mandate of the project manager.

Rule 4: Consider Both Threats and Opportunities

Project risks have a negative connotation: they are the "bad guys" that can harm your project. However modern risk approaches also focus on positive risks, the project opportunities. These are the uncertain events that beneficial to your project and organisation. These "good guys" make your project faster, better and more profitable.
Unfortunately, lots of project teams struggle to cross the finish line, being overloaded with work that needs to be done quickly. This creates project dynamics where only negative risks matter (if the team considers any risks at all). Make sure you create some time to deal with the opportunities in your project, even if it is only half an hour. Chances are that you see a couple of opportunities with a high pay-off that don't require a big investment in time or resources.

Rule 5: Clarify Ownership Issues

Some project managers think they are done once they have created a list with risks. However this is only a starting point. The next step is to make clear who is responsible for what risk! Someone has to feel the heat if a risk is not taken care of properly. The trick is simple: assign a risk owner for each risk that you have found. The risk owner is the person in your team that has the responsibility to optimise this risk for the project. The effects are really positive. At first people usually feel uncomfortable that they are actually responsible for certain risks, but as time passes they will act and carry out tasks to decrease threats and enhance opportunities.
Ownership also exists on another level. If a project threat occurs, someone has to pay the bill. This sounds logical, but it is an issue you have to address before a risk occurs. Especially if different business units, departments and suppliers are involved in your project, it becomes important who bears the consequences and has to empty his wallet. An important side effect of clarifying the ownership of risk effects, is that line managers start to pay attention to a project, especially when a lot of money is at stake. The ownership issue is equally important with project opportunities. Fights over (unexpected) revenues can become a long-term pastime of management.

Rule 6: Prioritise Risks

A project manager once told me "I treat all risks equally." This makes project life really simple. However, it doesn't deliver the best results possible. Some risks have a higher impact than others. Therefore, you better spend your time on the risks that can cause the biggest losses and gains. Check if you have any showstoppers in your project that could derail your project. If so, these are your number 1 priority. The other risks can be prioritised on gut feeling or, more objectively, on a set of criteria. The criteria most project teams use is to consider the effects of a risk and the likelihood that it will occur. Whatever prioritisation measure you use, use it consistently and focus on the big risks.

Rule 7: Analyse Risks

Understanding the nature of a risk is a precondition for a good response. Therefore take some time to have a closer look at individual risks and don't jump to conclusions without knowing what a risk is about.
Risk analysis occurs at different levels. If you want to understand a risk at an individual level it is most fruitful to think about the effects that it has and the causes that can make it happen. Looking at the effects, you can describe what effects take place immediately after a risk occurs and what effects happen as a result of the primary effects or because time elapses. A more detailed analysis may show the order of magnitude effect in a certain effect category like costs, lead time or product quality. Another angle to look at risks, is to focus on the events that precede a risk occurrence, the risk causes. List the different causes and the circumstances that decrease or increase the likelihood.
Another level of risk analysis is investigate the entire project. Each project manager needs to answer the usual questions about the total budget needed or the date the project will finish. If you take risks into account, you can do a simulation to show your project sponsor how likely it is that you finish on a given date or within a certain time frame. A similar exercise can be done for project costs.
The information you gather in a risk analysis will provide valuable insights in your project and the necessary input to find effective responses to optimise the risks.

Rule 8: Plan and Implement Risk Responses

Implementing a risk response is the activity that actually adds value to your project. You prevent a threat occurring or minimise negative effects. Execution is key here. The other rules have helped you to map, prioritise and understand risks. This will help you to make a sound risk response plan that focuses on the big wins.
If you deal with threats you basically have three options, risk avoidance, risk minimisation and risk acceptance. Avoiding risks means you organise your project in such a way that you don't encounter a risk anymore. This could mean changing supplier or adopting a different technology or, if you deal with a fatal risk, terminating a project. Spending more money on a doomed project is a bad investment.
The biggest category of responses are the ones to minimise risks. You can try to prevent a risk occurring by influencing the causes or decreasing the negative effects that could result. If you have carried out rule 7 properly (risk analysis) you will have plenty of opportunities to influence it. A final response is to accept a risk. This is a good choice if the effects on the project are minimal or the possibilities to influence it prove to be very difficult, time consuming or relatively expensive. Just make sure that it is a conscious choice to accept a certain risk.
Responses for risk opportunities are the reverse of the ones for threats. They will focus on seeking risks, maximising them or ignoring them (if opportunities prove to be too small).

Rule 9: Register Project Risks

This rule is about bookkeeping (however don't stop reading). Maintaining a risk log enables you to view progress and make sure that you won't forget a risk or two. It is also a perfect communication tool that informs your team members and stakeholders what is going on (rule 3).
A good risk log contains risks descriptions, clarifies ownership issues (rule 5) and enables you to carry our some basic analyses with regard to causes and effects (rule 7). Most project managers aren't really fond of administrative tasks, but doing your bookkeeping with regards to risks pays off, especially if the number of risks is large. Some project managers don't want to record risks, because they feel this makes it easier to blame them in case things go wrong. However the reverse is true. If you record project risks and the effective responses you have implemented, you create a track record that no one can deny. Even if a risk happens that derails the project. Doing projects is taking risks.

Rule 10: Track Risks and Associated Tasks

The risk register you have created as a result of rule 9, will help you to track risks and their associated tasks. Tracking tasks is a day-to-day job for each project manager. Integrating risk tasks into that daily routine is the easiest solution. Risk tasks may be carried out to identify or analyse risks or to generate, select and implement responses.
Tracking risks differs from tracking tasks. It focuses on the current situation of risks. Which risks are more likely to happen? Has the relative importance of risks changed? Answering this questions will help to pay attention to the risks that matter most for your project value.
The 10 golden risk rules above give you guidelines on how to implement risk management successfully in your project. However, keep in mind that you can always improve. Therefore rule number 11 would be to use the Japanese Kaizen approach: measure the effects of your risk management efforts and continuously implement improvements to make it even better.
Success with your project!
manajemen konstruksi

manajemen proyek

Manajemen Proyek

Manajemen

Aktivitas yang meliputi perencanaan, pengorganisasian, pelaksanaan dan kepemimpinan, serta pengawasan terhadap pengelolaan sumber daya yang dimiliki suatu organisasi untuk mencapai tujuan yang telah ditetapkan.

Proyek

Suatu kegiatan sementara yang dilakukan atau yang berlangsung dalam waktu terbatas dengan alokasi sumber daya tertentu dan dimaksudkan untuk menghasilkan produk (deliverable) yang kriterianya telah digariskan dengan jelas.

Ciri-ciri proyek

• Bertujuan menghasilkan lingkup (scope) tertentu berupa produk akhir ayau hasil kerja akhir.
• Dalam proses mewujudkan lingkup diatas, ditentukan jumlah biaya, jadwal, serta kriteria mutu.
• Bersifat sementara dalam arti umurnya dibatasi oleh selesainya tugas. Titik awal dan akhir ditentukan dengan jelas.
• non rutin, tidak berulang-ulang. Macam dan intensitas kegiatan berubah sepanjang proyek berlangsung

Sasaran proyek dan tiga kendala (Triple Constraint)
Batasan yang harus dipenuhi yakni :

• Besar Biaya (anggaran) yang dialokasikan.
• Jadwal.
• Mutu yang harus dipenuhi.
  
  

Perbedaan Kegiatan Proyek Dan Operasional :

Proyek :

• Bercorak dinamis, nonrutin
• Siklus proyek relatif pendek
• Intensitas kegiatan dalam periode siklus proyek berubah-ubah (naik-turun)
• Kegiatan harus diselesaikan berdasarkan anggaran dan jadwal yang telah ditentukan
• Terdiri dari macam-macam kegiatan yang memerlukan berbagai disiplin ilmu
• Keperluan sumber daya berubah, baik macam maupun volumenya

Operasional :

• Berulang-ulang, rutin
• Berlangsung dalam jangka panjang
• Intensitas kegiatan relatif sama
• Batasan anggaran dan jadwal tidak setajam proyek
• Macam kegiatan tidak terlalu banyak
• Macam dan volume keperluan sumber daya relatif konstant.

Manajemen Proyek

Proses aktivitas manajemen yang dilakukan dalam periode tertentu dan tidak bersifat rutin untuk mengelola sumber daya untuk mencapai tujuan proyek yang telah ditetapkan sebelumnya

Hal-hal yang menyebabkan timbulnya suatu proyek :

• Rencana Pemerintah
• Permintaan Pasar
• Dari dalam Perusahan yang bersangkutan
• Dari kegiatan Penelitian dan Pengembangan

Tiga hal yang berpengaruh besar berkaitan erat dengan konsep manajemen proyek:

• Manajemen Klasik atu manajemen fungsional (General Management)
• Pemikiran Sistem
• Pendekatan Contigency

Manajemen Klasik atau Manajemen Fungsional

Manajemen Klasik menjelaskan tugas-tugas manajemen berdasarkan fungsinya, yaitu merencanakan, mengorganisir, memimpin, dan mengendalikan.

Pemikiran Sistem

Pemikiran yang memandang segala sesuatu dari wawasan totalitas.

Pendekatan Contigency

Pendekatan yang erat hubungannya dengan situasi dan kondisi yang berarti bahwa tidak ada satupun pendekatan manajemen terbaik yang dapat dipakai untuk mengelola setiap macam kegiatan.

Macam-macam Proyek dari Segi Pekerjaan

• Proyek Engineering – Konstruksi
• Proyek Engineering – Manufaktur
• Proyek Penelitian dan Pengembangan
• Proyek Pelayanan Manajemen
• Proyek Kapital
• Proyek Radio – Telekomunikasi
• Proyek Konservasi Bio – Diversity

Tipe Organisasi Proyek:

• Fungsional
• Produk dan Area
• Matriks

Ciri organisasi proyek:

• Arus horizontal disamping vertikal
• Penanggung jawab tunggal atas berlangsungnya proyek
• Pendekatan sistem dalam perencanaan dan implementasi

Subjek : Manajemen Proyek