Category Archives: 1. Knowledge

Download : Excel – Summary Pmbok : Project Time Management

Posted on by
Reply

 

Project Time Management includes the processes required to manage the timely completion of the project.

 

download file excel :  project-time-management

Level 0 Level 1 Level 2 Level 3
Project Time

Management
Plan Schedule

Management
Input
Project management plan
Project charter
Enterprise environmental factor
Organizational process asset
tools
Expert judgment
Analytical techniques
Meetings
Output
Schedule management  Plan
Define activities
Input
Schedule management
Scope baseline
Enterprise environmental factor
Organizational process asset
tools
Decomposition
Rolling wave planning
Expert judgment
Output
Activity  list
Activity  attributes
Milestone list
Sequence Activities
Input
Schedule management
Activity list
Activity attributes
Milestone list
Project scope statement
Enterprise environmental factor
Organizational process asset
tools
Precedence diagramming
Dependency  determination
Leads and lags
Output
Project schedule network
Project documents updates
Estimate activity  resource
Input
Schedule management plan
Activity list
Activity attributes
Resource calendars
Risk register
Activity cost estimates
Enterprise environmental factors
Organizational process assets
tools
Expert judgment
Alternative analysis
Published estimating data
Bottom-up estimating
Project management software
Output
Activity resource requirements
Resource breakdown structure
Project documents updates
Estimate activity  duration
Input
Schedule management plan
Activity list
Activity attributes
Activity resource requirements
Resource calendars
Project scope statement
Risk register
Resource breakdown structure
Enterprise environmental factors
Organizational process assets
tools
Expert judgment
Analogous estimating
Parametric estimating
Three-point estimating
Group decision-making echniques
Reserve analysis
Output
Activity duration estimates
Project documents updates
Develop Schedule
Input
Schedule management plan
Activity list
Activity attributes
Project schedule network diagram
Activity resource requirements
Resource calendars
Activity duration estimates
Project scope statement
Risk register
Project staff assignments
Resource breakdown structure
Enterprise environmental factors
Organizational process assets
tools
Schedule network analysis
Critical path method
Critical chain method
Resource optimization techniques (resource leveling, resource smoothing)
Modeling techniques (what if scenario analysis,simulation)
Leads and lags
Schedule compression (Crashing, Fast Tracking)
Scheduling tool
Output
Schedule baseline
Project schedule
Schedule data
Project calendars
Project management plan updates ( Schedule baseline,Schedule management plan,Cost baseline)
Project documents updates (Activity resource requirements,Activity attributes,Calendars,Risk register)
Control Schedule
Input
Project management plan
Project schedule
Work performance data
Project calendars
Schedule data
Organizational process assets
tools
Performance reviews (Trend analysis,Critical path method ,Critical chain method ,Earned value management)
Project management software
Resource optimization techniques
Modeling techniques
Leads and lags
Schedule compression
Scheduling tool
Output
Work performance information
Schedule forecasts
Change requests
Project management plan updates ( Schedule baseline,Schedule management plan,Cost baseline)
Project documents updates (schedule data, project schedule,risk register)
Organizational process assets updates

 

​Bagaimana memilih Project management metodologi yang tepat

Posted on by
Reply

Mengidentifikasi metodologi  , memutuskan mana yang terbaik untuk project tertentu adlh bukan hal yg sederhana. 
Berikut adalah cara untuk membuat pilihan yang tepat.

       
beberapa metodologi yang paling dikenal, serta beberapa faktor ,  dapat mempengaruhi keputusan pemilihan..
metodologi ini adalah proses berulang, efektif dan efisien yang membantu organisasi merampingkan kegiatan proyek. 
Karena proses ini, setelah dikembangkan, dapat didokumentasikan dan diulang, mereka membantu organisasi untuk menghabiskan waktu kurang fokus pada bagaimana melaksanakan proyek itu sendiri, dan lebih banyak waktu pada tujuan dan deliverable proyek.
Proses yang diperlukan untuk  dinilai, dokumen, dan akhirnya memilih metodologi yang tepat untuk setiap proyek jauh lebih rinci, memakan waktu dan kompleks awalnya, 
tapi worth it pada akhirnya (dengan asumsi PMMs paling tepat dipilih).
pertimbangan utama saat menentukan metodologi terbaik
PMMs pasti tidak satu ukuran cocok untuk semua, bahkan dalam perusahaan yang sama, jenis proyek atau industri.
 Dalam satu situasi metodologi tertentu dapat bekerja terbaik.
Metodologi yang sama tidak mungkin untuk bekerja di organisasi yang sama pada semua proyek; praktek terbaik adalah untuk mengembangkan dan menerapkan proses penilaian metodologi ramping  untuk menentukan pendekatan yang terbaik untuk setiap proyek.
 Perlu diingat, proses ini sendiri mungkin memerlukan penilaian ulang dan modifikasi sebagai faktor bisnis berubah.
Apa yang masuk dalam penilaian
Dalam pengembangan organisasi, serta dalam list proyek-proyek,  kriteria penilaian yang relevan berlaku. 
Ketika datang untuk memilih metodologi kriteria yang sama juga harus ada dr faktor dalam. Ini dapat dibagi dalam kriteria internal dan eksternal, serta subkategori masing-masing.

Proses penilaian


Setelah kriteria penilaian telah diperhitungkan dalam keputusan, mengembangkan proses untuk mengidentifikasi pilihan terbaik untuk PMM untuk proyek-proyek tertentu.
 Seperti disebutkan sebelumnya, proses ini perlu ditinjau kembali dan dimodifikasi dari waktu ke waktu untuk bersaing dengan kebutuhan bisnis dan pemangku kepentingan secara keseluruhan.
 Berikut adalah beberapa langkah umum:
Pertama menentukan driver dari proyek, mengidentifikasi dan  tujuan utama dan prioritas proyek.
Setelah menentukan driver bisnis,
 persyaratan / proyek dan tujuan,
 mengidentifikasi semua kriteria yang metodologi akan berdampak dan sebaliknya.
Identifikasi semua kemungkinan metodologi yang tersedia / yang paling relevan untuk proyek tersebut.
Luangkan waktu membandingkan dan membedakan masing-masing PMM dalam kaitannya dengan proyek.

Pertimbangkan  metodologi yg akan menghasilkan hasil terbaik dan menawarkan risiko minimal.
Mendapatkan umpan balik dan buy-in.
Mendokumentasikan metodologi dan pemikiran.
Menerapkan metodologi.
Memonitor dan memodifikasi sesuai kebutuhan.
Meskipun faktor risiko terbesar adalah kemungkinan untuk jatuh dalam kemampuan organisasi dan kesiapan, kriteria lain yang disebutkan sebelumnya dapat menciptakan masalah signifikan jika mereka melanggar persyaratan utama proyek.

Beberapa metodologi juga diarahkan tipe tertentu dari proyek, tetapi mungkin tidak selalu bekerja di setiap contoh. Seperti adalah tempat pilihan hybrid (menggabungkan lebih dari satu metodologi) harus dipertimbangkan pada berbagai tahap proyek.
Contoh PMMs
Agile umumnya digunakan dalam proyek-proyek pengembangan perangkat lunak, itu membuatnya mudah untuk mengidentifikasi masalah dengan cepat dan membuat modifikasi pada awal proses pembangunan dibandingkan menunggu sampai pengujian. Agile menawarkan proses berulang, mengurangi risiko, memungkinkan untuk umpan balik segera, memberikan perputaran cepat dan mengurangi kompleksitas.

Air terjun/ waterfall menawarkan tahap perencanaan yang lebih formal yang dapat meningkatkan peluang menangkap semua persyaratan proyek di depan, mengurangi hilangnya informasi kunci dan persyaratan pada tahap awal.

 metodologi hibrida.

Menyadari apa yang menjadi prioritas, apa metodologi yang, dan kapan, dimana dan bagaimana masing-masing metodologi menciptakan dampak positif terbesar adalah kunci untuk keberhasilan proyek. 
Di sinilah peran manajer proyek yg  dapat membantu organisasi dalam meningkatkan bagaimana mereka melaksanakan proyek dengan cara yang paling efektif dan efisien sekaligus mengurangi risiko.
Sangat penting untuk dicatat tidak ada satu solusi dalam semua kasus, bahkan dalam organisasi yang sama. Pengalaman PM datang ke dalam project , dan ini adalah di mana pengetahuan manajer proyek dari pro dan kontra dari masing-masing metodologi dapat sangat membantu organisasi dalam berhasil menavigasi proyek dengan cara-cara yang memungkinkan mereka untuk memaksimalkan potensi pemangku kepentingan.

WHAT IS Work Breakdown Structure (WBS)

Posted on by
Reply

​

Source workbreakdownstructure.com.


A work breakdown structure is a key project deliverable that organizes the team’s work into manageable sections. The Project Management Body of Knowledge (PMBOK) defines the work breakdown structure as a “deliverable oriented hierarchical decomposition of the work to be executed by the project team.” The work breakdown structure visually defines the scope into manageable chunks that a project team can understand, as each level of the work breakdown structure provides further definition and detail. Figure 1(below) depicts a sample work breakdown structure with three levels defined.

Work Breakdown Structure (WBS)

Work Breakdown Structure for Construction of a House
Figure 1. Work Breakdown Structure
Click Here for full size image

An easy way to think about a work breakdown structure is as an outline or map of the specific project. A work breakdown structure starts with the project as the top level deliverable and is further decomposed into sub-deliverables using the following outline hierarchy (Figure 2):

Work Breakdown Structure Deliverable
Figure 2. Work Breakdown Structure Deliverable

The project team creates the project work breakdown structure by identifying the major functional deliverables and subdividing those deliverables into smaller systems and sub-deliverables. These sub-deliverables are further decomposed until a single person can be assigned. At this level, the specific work packages required to produce the sub- deliverable are identified and grouped together. The work package represents the list of tasks or “to-dos” to produce the specific unit of work. If you’ve seen detailed project schedules, then you’ll recognize the tasks under the work package as the “stuff” people need to complete by a specific time and within a specific level of effort.

From a cost perspective, these work packages are usually grouped and assigned to a specific department to produce the work. These departments, or cost accounts, are defined in an organizational breakdown structure and are allocated a budget to produce the specific deliverables. By integrating the cost accounts from the organizational breakdown structure and the project’s work breakdown structure, the entire organization can track financial progress in addition to project performance.

Why use a Work Breakdown Structure?

The work breakdown structure has a number of benefits in addition to defining and organizing the project work. A project budget can be allocated to the top levels of the work breakdown structure, and department budgets can be quickly calculated based on the each project’s work breakdown structure. By allocating time and cost estimates to specific sections of the work breakdown structure, a project schedule and budget can be quickly developed. As the project executes, specific sections of the work breakdown structure can be tracked to identify project cost performance and identify issues and problem areas in the project organization. For more information about Time allocation, see the100% Rule.

Project work breakdown structures can also be used to identify potential risks in a given project. If a work breakdown structure has a branch that is not well defined then it represents a scope definition risk. These risks should be tracked in a project log and reviewed as the project executes. By integrating the work breakdown structure with an organizational breakdown structure, the project manager can also identify communication points and formulate a communication plan across the project organization.

When a project is falling behind, referring the work breakdown structure will quickly identify the major deliverables impacted by a failing work package or late sub- deliverable. The work breakdown structure can also be color coded to represent sub- deliverable status. Assigning colors of red for late, yellow for at risk, green for on-target, and blue for completed deliverables is an effective way to produce a heat-map of project progress and draw management’s attention to key areas of the work breakdown structure.

Work Breakdown Structure Guidelines

The following guidelines should be considered when creating a work breakdown structure:

  • The top level represents the final deliverable or project
  • Sub-deliverables contain work packages that are assigned to a organization’s department or unit
  • All elements of the work breakdown structure don’t need to be defined to the same level
  • The work package defines the work, duration, and costs for the tasks required to produce the sub-deliverable
  • Work packages should not exceed 10 days of duration
  • Work packages should be independent of other work packages in the work breakdown structure
  • Work packages are unique and should not be duplicated across the work breakdown structure

Tools to Create a Work Breakdown Structure

Creating a Work Breakdown Structure is a team effort and is the culmination of multiple inputs and perspectives for the given project. One effective technique is to organize a brainstorming session with the various departments that will be involved with the project. Project teams can use low-technology tools like a white board, note cards, or sticky note pads to identify major deliverables, sub-deliverables, and specific work packages. These cards can be taped to a wall and reorganized as the team discusses the major deliverables and work packages involved in the project.

The low-technology approach is easy to do; however, it does not work well with distributed teams or translate easily into an electronic format. There are several tools available that support mind mapping, brainstorming, and work breakdown structures. MatchWare MindView is an easy-to-use mind mapping software package that supports work breakdown structures, project outlines, Gantt charts, and exports easily into Microsoft Project for further schedule definition. Figure 3 provides an example of a work breakdown structure using Matchware MindView.

Mind Mapping software for Work Breakdown Structure
Figure 3. MindView Work Breakdown Structure
Click Here for full size image

The key benefit to MatchWare MindView is its ease-of-use translating work breakdown structures into high level project schedules. A natural extension of the work breakdown structure is the project schedule. By brainstorming the project scope in a mind mapping tool, the project manager can easily assign budget and duration estimates. These budget and duration estimates can easily be exported into Microsoft Excel or Microsoft Project for additional planning and analysis. Project managers want tools that help accelerate their work and reduce the administrative burden that accompanies project management processes.

Work Breakdown Structure Video

Learn how to use MindView to easily create your Work Breakdown Structure / WBS. Apply numbering scheme, completion percentage (100% rule), resources, cost calculation, and more. This video also demonstrates different views as Timelines, Gantt chart, and mind map, as well as several export functions including MS Excel, MS Word, MS Project, etc.


“This Work breakdown structure was made using MatchWare MindView 4”. Click here to build your own work breakdown structure.

https://accounts.google.com/o/oauth2/postmessageRelay?parent=http%3A%2F%2Fwww.workbreakdownstructure.com&jsh=m%3B%2F_%2Fscs%2Fapps-static%2F_%2Fjs%2Fk%3Doz.gapi.id.nfhO6YTP1rM.O%2Fm%3D__features__%2Fam%3DAQ%2Frt%3Dj%2Fd%3D1%2Frs%3DAGLTcCNkfqcYNUlzGS5JuXkJW-qBPG4XOQ#rpctoken=344105267&forcesecure=1

COMMUNICATION  , How to Present to Senior Executives  -HBR, Nancy Duarte

Posted on by
Reply

​Senior executives are one of the toughest crowds you’ll face as a presenter. They’re incredibly impatient because their schedules are jam-packed — and they have to make lots of high-stakes decisions, often with little time to weigh options. So they won’t sit still for a long presentation with a big reveal at the end. They’ll just interrupt you before you finish your shtick.

It can be frustrating. You probably have a lot to say to them, and this might be your only shot to say it. But if you want them to hear you at all, get to what they care about right away so they can make their decisions more efficiently. Having presented to top executives in many fields — from jet engines to search engines — I’ve learned the hard way that if you ramble in front of them, you’ll get a look that says, “Are you kidding me? You really think I have the time to care about that?” So quickly and clearly present information that’s important to them, ask for questions, and then be done. If your spiel is short and insightful, you’ll get their ear again.

Here’s how you can earn their attention and support:

Summarize up front: Say you’re given 30 minutes to present. When creating your intro, pretend your whole slot got cut to 5 minutes. This will force you to lead with all the information your audience really cares about — high-level findings, conclusions, recommendations, a call to action. State those points clearly and succinctly right at the start, and then move on to supporting data, subtleties, and material that’s peripherally relevant.

Set expectations: Let the audience know you’ll spend the first few minutes presenting your summary and the rest of the time on discussion. Even the most impatient executives will be more likely to let you get through your main points uninterrupted if they know they’ll soon get to ask questions.

Create summary slides: When making your slide deck, place a short overview of key points at the front; the rest of your slides should serve as an appendix. Follow the 10% rule: If your appendix is 50 slides, create 5 summary slides, and so on. After you present the summary, let the group drive the conversation, and refer to appendix slides as relevant questions and comments come up. Often, executives will want to go deeper into certain points that will aid in their decision making. If they do, quickly pull up the slides that speak to those points.

Give them what they asked for: If you were invited to give an update about the flooding of your company’s manufacturing plant in Indonesia, do so before covering anything else. This time-pressed group of senior managers invited you to speak because they felt you could supply a missing piece of information. So answer that specific request directly and quickly.

Rehearse: Before presenting, run your talk and your slides by a colleague who will serve as an honest coach. Try to find someone who’s had success getting ideas adopted at the executive level. Ask for pointed feedback: Is your message coming through clearly and quickly? Do your summary slides boil everything down into skimmable key insights? Are you missing anything your audience is likely to expect?

Sounds like a lot of work? It is, but presenting to an executive team is a great honor and can open tremendous doors. If you nail this, people with a lot of influence will become strong advocates for your ideas.

This is the first post in Nancy Duarte’s blog series on creating and delivering presentations, based on tips from her new book, the HBR Guide to Persuasive Presentations.

​Risk dalam project management

Posted on by
Reply

Risk kerap dilewatkan atau hanya sebagai formalitas,
Sejatinya bila benar benar dilakukan dan diantisipasi , hasilnya akan sangat berguna terutama saat saat ini dimana target pertumbuhan byk negara  yang direvisi.
Ada beberapa standard utk risk ada IRM 2002 dr UK , ada iso kepala 31000 dll.
Garis merahnya hampir sama,

Yg sy akan bahas dibawah adalah risk management dr pmbok 2012 fith edition, gak beda jauh bila anda compare dgn iso 21500.
Risk persepsi  banyak ditangkap adalah negative,apalagi bila diterjemahkan dgn bahasa indonesia resiko, udah kartu mati.
Risk bisa positive atau negative.
Ada beberapa attitude , company terhadap risk,
1. Appetite , ini adalah willingness gairah keinginan perusahaan dlm menghadapi resiko. Tentu tidak membabi buta.ada  batasannya.
2. Tolerance.

Resiko yg bisa ditoleransi, misal kita beli equipment dgn usd tp jual dgn rupiah. Berapa deviasi tolerance nya , utk dpt margin , ditambah interest, cost equity , tempo waktu kita dibayar setelah done, 90 hari , atau kalau ingat setelah ditagih tagih . wkk  
3.threshold 
Lebih ke nilai quantitative, ini penting , anda harus set nilai nya secara jeli dan disiplin, ingat juga risk management bersifat iterative artinya tdk hanya didepan project, tapi diseluruh project life cycle. Gunakan earned value management utk performance control.

Kemudian apa delivery yg harus dilakukan dlm risk management.
1. Risk management plan

2. Risk list identification

3. Risk list quantitative

4. Risk list qualitative

5. Risk list respond planning

6. Risk list control.
quantitative adalah ukuran dlm matematika misal papan tulis, ukuran panjang x lebar, berat dlm kg berapa.
Sementara qualitative lebih bersifat kualitas, misal perception, satisfaction, scope juga bisa dimasukkan.
Biasanya saya buat risk list sbb:
1. Risk list identification.

Ingat risk ada luas, political, economic, social, technic , dll.
2. Risk list description.

3. Sign atau symtom atau tanda2 nya apa.

4.ada di project management knowledge mana : int scope time dll

5. Ada di project life cycle mana: starting , prep, exe, closing ?

6.impact nya : high medium low, bisa juga kita gambarkan dlm angka.

7.probabilitynya, high medium low, bisa juga dlm percentage

8.occurence, jarang, sering ?

9. Impact bila negative: avoid, transfer, mitigate , accept ?
10. Impact bila positive, exploid, enhance ?
11.respond planning nya apa?
12.ownership nya siapa.

13. Risk id, 

14. Risk date.

15. Remark/ description

16. Risk category : strategic,operational, finance, compliance.
Banyak kan.

Dari list tersebut bisa kita petakan ke dalam grafic,
Ingat bila kita orang technic, focuskan juga ke arah business, persepsi management lbh kearah value dari business itu , objective  dari project tersebut.
Walau seakan menguntungkan tp kemampuan terbatas dan membahayakan operational business lbh baik dicermati secara seksama.
Apalagi bila product portfolio yg kita jual belum mature,

Ingatkan bcg matrix: market vs growth.

Itsm value ?

Product life cycle ?