What does Project Manager Do ?

What does Project Manager Do ?

Whatever environment might be , the position could caused you on fire. Or shooted, so just well prepared & ready in action


The project manager :

  • is the person responsible for accomplishing the project objectives.
  • is the person assigned by the performing organization to lead the team that is responsible for achieving the project objectives.
  • Is a Person who leads of Projects
  • Make things happen but not Doing everythings
  • Applied of resources to achieve project objectives
  • Becomes the link between the strategy and the team
  • Big responsibilities, but limited authority


The project manager should be fulfilled some competencies:

Best Computers  ever seen

  • Technical Knowledge & Experienced : referring relevant Projects , examples for construction :  rail road, harbour,airport, building etc
  • Project management Knowledge , Performance & Project’s governance
  • Interpersonal Skill : Leadership , Communication, Influencing , Problem solving etc.
  • Organizational & Business processes

International best seller books

What Does DO ?

Lead of projects from Preparing, Starting, Executing, Controlling & Closing

Preparing :

  • Understand , Clarify to Sales /user of the project’s objectives and the Project’s deliverables
  • Requesting & Preparing Project team, Assigning people to all project roles
  • Defining Strategy , how the team will perform its essential functions
  • Preparing well defined Project management Plan, Project management documents, Business document

Starting :

  • Kick Off meeting : Finalize & stated Project’s deliverables
  • MOM Signature
  • Informing Project management procesess & Reporting method,KPI, Dashboards

Performing :

  • Doing the tasks: Perform the work that’s in your plan
  • Managing & developing team
  • Key user training
  • User Acceptance

Controlling :

  • Comparing performance with plans
  • Fixing problems that arise
  • Keeping everyone informed


Closing :

  • Handover to Operation
  • Biling statement
  • Closing Project

You Don’t Need a Title to Be a Great Leader

If you can influence and have an impact on others, you’re a leader

By lolly daskal


Many people believe leadership is something that’s conferred along with a title or attained when you direct a a team of people, but true leadership is never about authority or power. It’s about helping others grow, and that’s something anyone can do.

If it’s your desire to influence and have an impact on others, you have leadership qualities. And if you can inspire people to do something they thought they couldn’t do, demonstrate how the impossible is possible, believe in someone when they didn’t believe in themselves, you’re already a leader.

People don’t set out to be great leaders, they set out to make a difference. It’s never about the role or the title, but about influencing others, helping and supporting them.

Here are seven questions to help you gauge your own leadership:

1. Do you act with integrity? Leaders allow their good character to speak for them. If you are the type of person who is consistent in your actions, values, methods, and principles–regardless of who’s watching–and if people know what say you do you will do, and do it to the highest standard, you’re a leader.

2. Are you a great communicator? Great leaders are great communicators. Are you the type of person who likes to share information? To keep people informed and make sure they have all the guidance they need? Do you communicate with openness, candor, and honesty, and without drama or wordiness? You’re a leader.

3. Do you have confidence? Confidence doesn’t always come easy. It’s what you do with your confidence that makes you a leader. If you have the ability to inspire, engage, and empower others, helping them realize they can do things they thought were impossible, you’re a leader.

4. Are you decisive? One of the most basic duties of any leader is to make decisions. True leaders aren’t afraid to make tough calls when circumstances require it. If you are the kind of person who can gather information, make informed decisions quickly without hesitation or second-guessing, and make it work, you’re a leader.

5. Do you have a courageous attitude? A true leader is not afraid to take risks. The bigger the risk, the bigger the payoff. If you’re bold about taking chances, if you can see opportunities, and if you’re willing to start difficult conversations, you’re a leader.

6. Are you a problem solver? Let’s be honest: much of life is problem solving. There’s always something to figure out, some difficulty to resolve, some circumstance to correct. Most people spend their time complaining about problems, but leaders view a problem not as a distraction but as a source of improvement and new opportunities. If you find yourself problem solving, you’re a leader.

7. Are relationships important to you? The foundation of true leadership is the quality of your relationships. Relationships are built on a deep understanding and appreciation of others. They require the capacity to connect on a deep and personal level with others and penetrate beyond the surface with people. When you make relationships important, you’re a leader.

No matter what title you have, no matter where you work, or who you work with–if you’re influencing others and making change happen, you’re a leader.

Communication skill Value: Inspire others

To inspire positive action you must ask first, What message do I want to send and second, How do I want people to feel?
When you inspire others, they experience new ways of thinking, feeling, and acting. With your words alone you can help people feel connected to a larger group and mission. You will also help people develop a personal connection with you as their leader.

This is a value that leaders often underestimate.

Your Communication Is Accountable When:
• People are inspired. They go into action to make things happen.
• People re-create your message for others. They use their own words to restate what you want and when you want it.
• People know what is important. They are clear about your priorities and what needs to happen first.
• People are emotionally and intellectually engaged. Your message has tapped both their hearts and minds.



“That’s the problem in a nutshell.” add ,Now it’s up to us to turn this around.”
“This is an issue we must address quickly.” Add: “I’m confident we can do this.”
“We will meet on Friday at 8 a.m. in the conference room.” Add: “Let’s use this time to generate new ideas together.”
• “I haven’t had a chance to read your report.” Add: “I always appreciate how you look at things.”
• “We are facing a number of challenges this next year.” Add: “I’m happy to be on a great team. We’ll need everyone’s thinking and energy.”
• “Good morning. ” Add: “It’s always good to see you.”
• “Here’s the document. Read it and let’s talk.” Add: “I’m interested in hearing your thoughts.”



  • A few years back, 1,500 employees in a variety of work settings were surveyed to find out what they considered to be the most powerful workplace motivator. Their response?

The most powerful workplace motivator?

Recognition ,


and more recognition!



Research tells us that there are three types of conflict:

Task, relationship, and process.

  • Task conflict relates to the content and goals of the work.
  • Relationship conflict focuses on interpersonal relationships.
  • dsc02489_r.jpg
  • And process conflict relates to how work gets done.

Conflict is constructive when it improves the quality of decisions, stimulates creativity and innovation, encourages interest and curiosity among group members, provides the medium through which problems can be aired and tensions released, and fosters an environment of self-evaluation and change

ENTREPRENEUR Apa Kualitas utama, yg Orang paling inginkan Dari seorang Leader ?

Hal ini cukup sederhana namun sering diabaikan.


Suatu Jaringan Pengusaha dr  komunitas online di mana orang-orang yang paling berpengaruh dalam perkembangan startup Amerika.

Byk mendptkan pertanyaan:

“Apa gaya kepemimpinan yg harus dipunyai oleh seorang pengusaha ?”

Memahami gaya bekerja kepemimpinan yg sesuai dan konsisten adalah hal yang setiap pengusaha perlu dilakukan untuk mendorong sebuah organisasi ke depan.

kuncinya adalah bukan apa yang Anda pilih untuk melakukannya – tp adalah apa yang Anda bisa untuk melakukan secara konsisten.

Satu-satunya cara untuk memahami apa gaya kepemimpinan  utk bekerja dengan tim Anda , adalah dgn meminta umpan balik real-time.

Meminta tim Anda , satu-satu bagaimana mereka mengalaminya – apakah mereka mendapatkan nilai dari percakapan?

Apakah mereka merasa Anda mendengar tantangan dan keprihatinan mereka?

Mencari umpan balik dan  tindakan lanjut /follow up.

Pemimpin adalah manusia.
Mereka kadang sering mengacaukan. Semakin manusia mereka, semakin mereka mengacaukan.

Beberapa berpendapat bahwa jika Anda tidak mengacaukan, Anda tidak mendorong cukup keras.

INti untuk membuat kemajuan adalah membangun metrik yang jelas yang berfungsi tidak hanya sebagai garis finish, tetapi juga pengingat dari apa yang perlu Anda lakukan.

Jadi, jika Anda berencana untuk mengembangkan hubungan yang berkualitas, performa tinggi ,

Anda hrs menetapkan tujuan yang -konsisten yang menghasilkan percakapan konstruktif dan kejelasan tentang kemajuan tujuan dan hasil kunci utama yg ingin dicapai.

Untuk melakukan ini, Anda bisa menuliskan dlm spreadsheet sederhana untuk mengingatkan Anda tentang  to do list , doing-progress utama, satu-satu dan di mana Anda bisa  lbh , melakukan yg terbaik.

Instrumenting perilaku kepemimpinan perubahan kualitas perilaku itu.

Sebagai seorang pemimpin, itu penting Anda mengidentifikasi perilaku yang Anda paling ingin melihat dalam seorng  pemimpin – Anda akan menjadi cerminan dari mereka, dan mereka bagian dari Anda.

Bagi saya, kualitas yang rendah hati, yang membantu Anda memahami bahwa, tidak ada satu orang yang pernah akan memiliki semua jawaban yang benar diberikan tempat dunia yang kompleks kita hidup ini.

Anda tidak dpt belajar dari orang lain, atau kesalahan Anda, kecuali jika Anda cukup rendah hati untuk memahami ini.

Pemimpin yang rendah hati meminta umpan balik atau kritik konstruktif dan mereka mau mendengarkan .

Mereka mau mengakui kesalahan  dan bertujuan untuk memberdayakan tim.

Mereka menunjukkan keberanian dengan menjadi nyaman dengan segala risiko dan kegagalan dihitung.

Sebuah penelitian Catalyst terbaru menunjukkan perusahaan dengan para pemimpin yang rendah hati lebih mungkin untuk menjadi inovatif dan memiliki tim yang lebih didedikasikan untuk perusahaan.

Ada beberapa cara pengusaha dapat membangun budaya lebih rendah hati dalam organisasi mereka:

Menunjukkan bahwa pemimpin juga seorang manusia

orang yang tidak sempurna sepanjang waktu.

Menunjukkan tim Anda bahwa Anda adalah manusia membantu mereka memahami bahwa Anda lebih dari sekedar bos.

Dengan menjadi transparan tentang kesalahan Anda dan pelajaran yang telah Anda pelajari selama karir Anda,

Anda dapat memupuk tim kuat dan budaya rasa memiliki , di mana memberi yang terbaik bagi perusahaan, pelanggan dan tim.

Mendorong keterbukaan, diskusi dan dialog. 

Banyak yang bisa disalahartikan melalui email. Mendorong tim Anda untuk benar-benar berdiri dan berbicara satu sama lain dapat meningkatkan kesadaran, dinamika tim dan budaya perusahaan.

berbagai perspektif dapat membantu anggota tim merasa lebih , dan dalam jangka panjang, dapat meningkatkan inovasi. Dengan menggabungkan lebih sudut pandang, Anda lebih mungkin untuk datang dengan solusi yang lebih kreatif.

Merangkul ketidakpastian dan tidak mengetahui semua jawaban yg benar-benar dapat mendorong tim penasaran untuk mengisi kekosongan.

Dengan tidak dengan asumsi Anda tahu segalanya, Anda menciptakan ruang untuk tim Anda untuk mencari hal yg lbh tinggi  untuk solusi, lbh bisa menguji ide-ide dan menantang diri mereka sendiri.

Pertumbuhan startup bukanlah perjalanan linear.

Anda akan membuat banyak kesalahan dan kemampuan untuk mengakui ketika Anda salah adalah kualitas penting yang dapat digunakan untuk membawa tim Anda lebih dekat bersama-sama.

Untuk membantu karyawan Anda memahami bagaimana untuk mengambil risiko yang diperhitungkan, gagal cepat, iterate dan terus mendorong maju.

Dengan memimpin sebuah organisasi untuk menjadi manusia dan rendah hati,

Anda akan melihat orang-orang hebat melakukan hal-hal menakjubkan.

Hanya karena Anda membangun sebuah lingkungan di mana itu its okay n fine untuk mencoba dan gagal – selamat  mencoba.

Good article: The important things Lesson learned Documentation & Scope Creep.


Scope Creep and Action Reports (SCARs) in Software Projects

Sarma Danturthi, PhD, PMP– May 18, 2016

There is a strange quote that says, “Two things in life are very easy to do. One, walking on water and two, developing software, if the water and functional/user requirements of the software are frozen.” Funny? Right, but those in the software development field know this statement is an absolute truth. What causes the scope creep?

In information technology software development projects (after submitting the initial requirements), a customer is very likely to change and keep changing the requirements—much to the annoyance of the development team. A team writing software is also often negligent in creating the proper documentation or following a coding standard. This article discusses the scope creep that may sneak into software projects and why the creation of project documentation should be made mandatory, whether the project methodology is agile, waterfall, or any other.

Jim Davis, a project manager, just started working on a new software development project that’s very similar to the project his team completed last year. A month after submitting the requirements, the customer is now busy adding more changes to the original requirements and expanding the scope of project. To recall how his team dealt with this kind of scope creep, Jim wants to look into the lessons learned document from last year’s project, but he cannot remember where it is. The team’s technical lead left the company and none of the other team members have any idea about what Jim is asking about. Though Jim remembers some of the pitfalls his team had in the last project, he shudders to think that the team has to go through the same route again. A lessons learned document would have helped Jim save hundreds of work hours, but the document is not available. Worse yet, it was probably never created. Jim is now at a crossroads as to what to do with the scope creep he is experiencing and how his team will sail through all the troubles again.

Does the story of Jim sound familiar? This is the story we may discover again and again in the software development life cycle, even though every project manager has heard the rule a dozen times—in every phase of a project, create the action reports and lessons learned documentation, whether all the project management principles are followed to the core or in part.

Let us face it. First, while developing software, every project manager has more or less experienced the dreaded scope creep at one stage or the other, where the requirements keep changing with regular customer feedback even if the project methodology follows an agile, waterfall, or any other model. Second, it is probably an open secret that a majority of the project managers and developers in the field of information technology often avoid creating action reports or lessons-learned documentation, or for that matter, any other technical documentation, unless absolutely necessary. There are several reasons—either valid or invalid—for the lack of (or willingness to create) these documents. This paper discusses these two factors—combined as an acronym SCARs—and tries to reason as to why scope creep may sneak into software projects and why action reports should be made mandatory, however tough a project manager’s stance is. In this discussion, by using the term “action reports,” we should keep in mind that they are to be created and updated throughout the project and do not replace any other existing or required project documentation. Instead, they are helpful in augmenting a project’s success and will prove to be valuable assets en route to continuous process improvement.

Scope Creep
There is a strange quote that says, “Two things in life are very easy to do. One, walking on water and two, developing software, if the water and functional/user requirements of the software are frozen.” Funny? Right, but those in the software development field know this statement is an absolute truth. What causes the scope creep? To find the answer to this question, let us dig a bit deeper into a software company’s infrastructure. A software development firm usually has three different environments—development, test, and production. If we leave out the mom and pop and bed and breakfast software shops (which actually develop software of high quality), a project manager is familiar with these environments. At best, all three environments are on different servers—both front and back ends. But there are also some companies that have only the back end on different environments, keeping the front end intact on only one machine.

The first option is ideal and obvious—to keep everything detached in every environment. Each environment has its own front and back ends, operating system, software, libraries, objects, and so on and so forth.  A great deal of systems administration, maintenance, and coordination among the teams is necessary to keep these three environments functioning. With three environments and a change control board (CCB) in place, the design and development is done first on the development machine and, when complete, the customer is informed about the approaching test on the testing machine. But during and at every stage of the software development project life cycle, the customer is in direct contact with both the project manager and developers and can give feedback with one or more change requests that may pass through CCB.

In the second option of one front end and three different back ends without any CCB in place, the developer just changes his connections to a different machine while developing, testing, or deploying on a public-facing production server. The bed and breakfast software companies do not have the resources or manpower for three separate environments and take their risks with only one. Their deployment may usually be on a paid hosting website or server. This method is a trial and error and is prone to risk, but these shops feel comfortable with the risk they are taking to deploy or rollback their changes as they deem fit.

Except for a large software development firm, it is very common not to have any CCB to approve or reject changes requested by the customer. The reason for not having a CCB is simple—lack of money for the resources, either human or otherwise. In the absence of CCB, the customer and the project manager are in direct agreement on what changes to make. It is also quite common that these requests from the customer to the project manager sometimes are verbal and/or happen on a mere phone call. Once the project manager starts implementing those verbal changes, the customer gets a feeling of being able to wave the magic wand whenever he wants because the project manager has allowed the customer to play the cards.

As surprising as it may sound, the changes are often for inserting a check box, adding or removing a text box, changing text in a message box, modifying what is displayed, how it is displayed, adding a new column to the database table, adding new functionality to the application, conforming a web page to a standard such as ADA/EOE or W3 Standards, and so on and so forth. The project manager, after allowing the customer to have his way, will soon notice that the project is expanding beyond the original requirements and scope creep is becoming a regular pain. This is because before a software package is created, the customer has only a jagged idea of how the software should look, but really cannot tell what exactly it should look like. This is contrary to a civil engineering project—such as construction of a bridge—where everything is finalized at the design stage. More often, even the most experienced software developer and project manager cannot tell ahead of time how beautiful the final software product will be when complete, because one control (e.g., check box) can be programmed to run like another (e.g., radio button) or a developer can design his own user control with a different look, feel, and functionality.

Let us consider an example. A few days before final deployment while testing the code in action, the customer thinks he now needs an additional text box on a web page, in which he can type a note and record it. It is a very simple request that will not take more than fifteen minutes of code changes. At least, that’s what the customer assumes. After receiving this request from the customer, the project manager calls an open dialog in the war room and discusses this change with his programmers. A text box can be created easily, but now the team raises some valid questions. What does the customer plan to type in the box? A free entry text box on a web page can be a land mine for SQL injection attacks. So, the text box requires a validator for data. If we somehow avoided that land mine with a validator, the next question is, where do we store the data typed in that text box? Do we already have sufficient table space on the back-end database for it? If not, how much time and space is required on the back end? Also, if the customer is typing some free text into the text box, when he retrieves the data, should the entered data show up on a different page? Questions galore—and what is seemingly a very simple text box for the customer, quickly becomes a complex scope creep problem for the project team to implement.

The project manager and the development team may start feeling bitter and hostile toward the customer for these ever-changing, unpredictable requirements. On the other end of spectrum, the customer may also have negative feelings toward the project team for not getting the changes he/she wants. Suddenly, every stakeholder recognizes that this scope creep now will have an effect on budget, timelines, etc. The problem in such a situation is lack of communication, since the customer thinks the changes are very simple; whereas the project manager and his team know that these requirements were not mentioned at the start of the project. However, an experienced project manager should be able to handle these things with discretion, dexterity, and diplomacy.

Even in large software development corporations with a fully functioning CCB, this kind of scope creep can happen. When the project manager informs the customer about the possible scope creep and additional costs, if the customer insists on a change at any stage of development with proper change requests through CCB, the project manager will have to budge for various reasons. First and foremost being the fear of losing the business and the goodwill of the customer. Second, the reputation of the company could be at stake. Even if both of these reasons are invalid, we know that a customer can force the project manager to make changes when the customer thinks he “should have his say” in the project. The project manager can find ways to avoid or limit the scope creep by having a boundary for the original requirements and by stating new completion dates, additional costs, pushing the project to another phase, etc. Also, the scope changes can be controllable if done the right way with a certain knack and diplomacy from the project manager. But, as it so happens in software projects, if the customer agrees to the new dates and costs, the project manager has to budge again.

In addition to projecting a smiling face, there are two rules that are repeatedly drilled into the minds of all those working in software development. One, never say no to the customer and two, do not display technical arrogance. Saying no to the customer will lose your business and may cost you your job. Secondly, as a developer or project manager, you may be the smartest person who knows everything from Alpha, Lambda, and Sigma to the most sophisticated rocket science used to send an unmanned spacecraft to Mars, but the customer does not have to know those things. All you need to do is “listen to the customer and comply with what he wants.” There is no need show the customer your abilities to design a space shuttle. In other words, “do what is needed and do not volunteer to do what is not required,” is the official song. These are some of the reasons IT staff always complies and why scope creep may happen—sometimes, at an alarming regularity when dealing with a specific customer.

So, there we have the undocumented first rule—in every software project, be prepared in advance for scope creep to happen. Once recognized and ready—if scope creep happens a few times even after completing several projects successfully—the project manager and his team are at ease to work with a customer and on future projects.

Action Reports/Lessons Learned Documentation
Our next discussion is the creation of action reports or lessons learned documents and adhering to coding standards. As project management practitioners, we all know the real importance of lessons learned documentation and their role in continuous process improvement. We are all brainwashed thoroughly to create lessons learned documents and/or action reports at every stage of the project—not just at the end of the project. But, if we randomly pick a software guy and ask how much time he/she really spends creating any documentation, we know the answer. Software development teams, in general, are very negligent in creating those documents. Large organizations have built-in software, such as Visual Studio’s Team Foundation Server (TFS), to process documentation, but what about the mom and pop, and bed and breakfast joints that cannot afford to buy software for bug tracking, documentation, etc.? Except for the user and operating manuals, there is really no other documentation that is created by those shops. Even after a successful test run, did we actually record the number of bugs found and how they were corrected? Did we document how a difficult bug was eliminated after several days of research and mental toil? If not, once we fixed the bug and have lost track of the process, only the person who did the original work may remember those bugs and their resolutions—and maybe only for a short period of time. If the original coder has moved on to another project or company, the entire knowledge base goes with him or her, just out of the door and into the oblivion. Think of the number of hours one can save and the amount of mental stress one can avoid if only such an experience were properly documented.

Why doesn’t the software team or project manager care much for creating the action reports? There are dozens of reasons. Among them are laziness, lack of time, ever-changing technologies and their versions, the absence of any project management methodology in the project, staff changes, programming language changes, migration to a different environment/framework, or various other financial and social obligations. Yes, the “my-job-is-holier-than-document-creation” factor comes in too.

The other side of the documentation coin is purely technical, much more distressing, and actually happens inside a perfectly functioning piece of code. If we randomly pick a software development business and look carefully within its infrastructure, we find that there is no proper standard that is usually followed for coding—either by the team lead or by those who work with the team lead. Even large organizations give very little importance to coding standards because their focus is mainly on a version of working code rather than properly written working code. There is quite a bit of difference between “working code” and “properly written working code.” A properly written working code is readable, has plenty of comments, follows a pre-defined format, encourages other coders to follow the format, gives insight to the application, class, or objects being created, and makes the life of a coder/reader easy. It also compiles without bugs and runs successfully. On the other hand, a “working code” may function and can, apparently solve the problem, but once a bug is found, anyone other than the original coder will find it increasingly irritating to understand the functioning of the code in order to trace or debug. Even the original coder—after not seeing the code for six months or more—will find his own code very annoying when he comes back to debug. A properly formatted and well-documented or commented code saves time, energy, and avoids frustrations. But when it comes to coding, do we follow a format or a standard? If we do, how good is the format and how often do we document the code? Those are the most important questions for everyone in the software development field. Lame excuses like lack of time or interest for not writing proper comments or for not following a coding format should not be entertained by the project manager. If writing dry code takes a few hours, with a little practice, writing properly written working code can be efficiently done in the same number of hours.

Documenting is a lucid write-up of what we know, what we did, and how well we understand the process. By documentation, it is neither a dry Microsoft Word document nor a lengthy novel, but one that saves our lives. In one sentence, documentation is the life blood of the software development process and is an essential component of successful project management. But, there is a general disregard and alarming indifference to creating documentation for software projects. In his book, Memoir of the Craft – On Writing, fiction writer Stephen King asks all the people who do or want to write, “If God gives you something you can do, why in the name of God wouldn’t you do it?”

Why, indeed! The question applies equally to all of us working in the software field who refuse to create the needed documentation and do not follow any formatting or coding standards. Above all, we need to remember that the greatest advantage of action reports or lessons learned documentation is that they help us in continuous process improvement and in shaping the success of current and future projects.

Those of us working in the software field need to accept the fact that scope creep can happen sooner or later. Even if we have worked in the field for a year, ten years, or thirty years, a customer request will probably push us beyond the original scope of the project. And the best action we can take for creeping scope is to expect it and be prepared for it. Secondly, any action reports created at any stage of software development life cycle—design, development, code, test, or deployment—are going to be life savers, both to the original coder and the successors. The more documentation we have about a project, the better our lives become because these documents provide a mental map of the project and can save us embarrassment and hundreds of hours of time. Documentation also includes having a coding standard and religiously sticking to it while coding. If we conscientiously avoid the documentation for whatever reasons, we know we have an accident waiting to happen—an imminent wound, and an ugly scar when the wound heals. The best way ahead to avoid all these is to remember the acronym—SCARs. We need to be prepared in advance for possible scope creep and action reports. In addition to promoting success in current and future projects, they can expertly guide us in continuous process improvement.

About the Author
R. Sarma Danturthi has a PhD in engineering from the University Of Memphis, Memphis, TN, USA and has taught graduate-level courses in computer science. He has been working in the IT field for several years. His experience includes design, coding, leading project teams, and successful project management. He has also published papers in peer-reviewed journals and has written book chapters on software interfaces, modeling, and simulation. His interests include cloud computing, intelligent interfaces, and mobile application development, among others. He can be contacted at d_danturthi@hotmail.com

Kegagalan PMO ( Program / Project management office),


Kegagalan PMO ( Program /project management office),

Ada tapi tiada, ada tapi belum maksimal, berfungsi tapi belum optimal,
Begitu banyak resource, biaya yg telah keluar, tapi kegagalan dgn membuktikan hasil kerja nyata maksimal, jadi sandungan utk, dan bisa menjadi beban dlm organisasi.

Byk… perusahaan yg rela mengeluarkan uang tdk sedikit utk mendatangkan pihak luar utk melakukan audit & improvement, tp sayangnya -hasilnya yg masih belum maksimal,
Worst casenya Hasilnya dijadikan menambahnya beban pengeluaran , hari gini ?
Dr sejarah , wkk. Utk perusahaan worldwide di Jakarta, tariff nya bisa hampir 1 M. hy utk konsultasi.

Rahasia umum masalah besar yg dihadapi, tp selalu ditutupi, atau seakan2 utk tdk enak, menjaga tetap as is, tdk berubah, dgn sejuta ber milyard alasan,
,mari kita ulas, pastinya anda juga sudah paham2 juga 🙂 ,
1. Culture
• Lack ownership, lack of Sense of urgency, alon alon tp tdk kelakon, penting untuk menunda pekerjaan, bagaimana menyusun dalih2, tdk mau dicontrol, ingin pekerja seperlunya. Bikin parpol2 gurem diktr, duduk2 enak, cape browsing, Tapi gaji ingin naik wkk, dipikir perusahaannya bisa cetak uang sendiri wkk,
Kalau diulas sangat panjang lebar, saya serahkan ke ahlinya saja.

2. Project governance
• Bukan hy flow process, sekian byk SOP, SUP dan WI, sudah adakah & dilaksanakankah dan pre post audit utk setiap project ??
• Template harus lengkap, dari Business case, Project category, Charter, Project mgnt pln, minute of meeting, dll,
Bila perlu sampai template meeting invitation,
Saya sedih betapa ada, dlm meeting project, meeting invitation, seadanya, tanpa tema meeting jelas, dan kata2 yg memotivasi, sangat datar, kl pun ada mom, hy seperlunya, habis meeting, ngalor ngidul, done, bablas angine.
3. Project management knowledge & Performance
• Seperti telur atau ayam, knowledge performance yg kuat timbul governance –frame work structure yg oke,
• Mau apapun diatas kertas, tp bila pelakunya tdk ada semngat, passion di project management,rohnya akan beda, auranya akan beda,
• Knowledge yg cukup, ditunjang performance akan menjadi duet maut, duet maut penghasil revenue hebat utk perusahaan.
• Ikhlas,focus, kerja222
• Dll deh

4. Project management structure, organization.
• Ingat kepentingan perusahaan nomer satu, customer adalah utama, jangan menunggu
• Mau supportive, controlling, directive, pmo itu sendiri yg menentukan, jgn duduk menunggu rejeki jatuh, pro active, kontribusi, dan tdk berkelit dr pekerjaan.
• Orang merasa membutuhkan bila bermaafaat, bermaanfaat bila terus berusaha, ingin terdepan, project adlh terdepan, ujung tombak perusaahaan, mau salesnya jumpalitan, kl project nya gagal, kita bisa gak dibayar tahu.. wkk udah ah.

Cara Membuat Project Charter


Bagaimana Membuat Project Charter,

ada juga bisa membaca artikel saya : apa project charter ?

Apa itu Project charter?


Dibawah hanya contoh sederhana, anda bisa mengembangkan ketingkat level yg lbh tinggi,

Project Charter,


Revision history





1.1          Project Title and Description

What is the project?  Utk lebih detail anda bisa tambahkan juga:  start dan finish date.

Project Name


Project Manager

Project Category: XXXX

1.2          Project Background

Jelaskan alasan project ini, why ? kenapa ada, apa yg men trigger.


1.3          Project Objectives

Pernah dengar SMART,

  • ü    Specific: Jelaskan gamblang tentang project ini
  • ü    Measurable: Pengukuran, utk menunjukan progress project, cara menentukan deliverable result
  • ü    Achievable/agreed to:  hal2 yg telah disetujui utk dicapai ( scope,deliverable , out scope)
  • ü    Realistic: Project ini dapat dicapai dengan apa? Jelaskan juga constrain nya.
  • ü    Time able: Start finish, target go live dan sebagainya.

1.4          Project Scope

In Scope:

                  Term in- scope disini ada dua: Product Scope Dan Project Scope.

  •                   Product Scope: feature function that characteristic: Product/service/result
  •                   Project Scope: the work performed to deliver above feature & function


Out of scope: , yang bukan tanggung jawab di project ini,  ingat scope creep. Penyebab masalah dlm banyak project.

1.5          Scope of deliverables

Jelaskan sangat detail scope deliverable di project ini,Sertakan deliverable types : product and or service and or result.

Jelaskan secara jelas, jangan dgn Bahasa ambiguity : makna jelas deliverable yg ingin diraih


1.6          Project Schedule

Gunakanlah Software Project management tool, Project schedule sangat penting , develop schedule untuk project ini, berikan baseline, milestone, assigned resources dan estimate cost


1.7          Project Cost

Cost dlm project ini SEMUA harus tercapture, gunakan project management tool, masukan biaya material, plan travel –hotel, fuel, resources, overhead cost

Dlm budget masing2 perusahaan punya policy masing2, anda harus tahu, jgn krn masalah administrasi ,form,approval ,mengganggu timeline project.

1.8          Project Quality

Quality sering diucapkan tapi banyak dilupakan,  sertakan quality standard utk project ini, ingat quality ,Bukan hy saat UAT/ATP, tp jauh sebelum itu,

UAT scenario, assigned QA person, QA testing strategy sangat penting

1.9          Project Organization

Masukkan project organization, sertakan juga peer to peer project organization dgn project organization customer,

Berikan role, responsibility beserta nama yg diassign


1.10       Project Stakeholder

List identification stakeholder,

Project sponsor, performing organization, User/customer ( initiator,user,buyer, influence)  ,supplier vendor, government bila ada


1.11        Project Communication

  •                   Template project status update,
  •                    Project status report
  •                   List distribution information
  •                   Time –venue for Project’s regular meeting
  •                   Meeting participants
  •                   Template MOM
  •                   Escalation level to communicate


1.12        Project risk management

Risk identification list,

Example:  kurs rupiah, dependency with other parties, turn over resource, economic perspective, procurement lead time, budgeting

1.13       Project Constrain

Yg tdk bisa kita control, target go live, readiness infrastructure, government regulation etc

1.14       Critical satisfaction Factor

Yg paling penting dan crtical dkm project ini, misal full filly resource, skill expertise  consulatant yg penting , budget, time line for clear requirement, properly quality testing scenario, team collaboration, resource focus_ prioritized

1.15        Project Approval

Approval dari project sponsor,project manager, customer dll

Apa itu Project charter?

Apa itu Project charter?

Project charter adalah document yg secara formal menandai, memulai , melaksanakan suatu project,  Project charter berguna utk project manager , utk berhak dan punya wewenang utk menggunakan resources dlm menjalankan akitifitas2 di dlm project tersebut.

Apa saja dan bagaimana membuat project charter, silahkan  refer tulisan saya berikut:


Project charter biasanya di presentasikan dan bila semua oke ditandai dgn approval pihak terkait langsung ditempat,

Apa kegiatan itu? Yaitu Kick off meeting,


Sblm KOM, baiknya kita circular dulu draft project charter utk dipelajari ke participants, sehingga ketika KOM, tujuan/ objectives nya akan tercapai maksimal.

Concern needs expectation bisa masuk segera ke bahan pokok document utk di follow up.


Project charter bisa juga dilihat sebagai tanda keseriusan suatu organisasi utk melakukan kick off project,

Apakah seadanya, seperlunya atau berusaha terbaik. apakah project ini, dipersiapkan secara matang,detail dan proper ?

Skill dan competency seorang project manager juga bisa terlihat jelas, kemauan, kapasitas, maturity, expertise, pengalaman, sangat mempengaruhi keberhasilan project.


Runtun ke belakang, Urutan dlm memulai project ada beberapa stages:

Project mandates, starting project, preparation, executing – monitoring dan closing.

Project mandate adlh , assigned project manager yg akan handle project tersebut.

Biasanya ada meeting dgn management, team sales solution product, diulas proposal, target, serta scope deliverable.

Ingat sangat penting memulai project dgn project governance,


Dlm lapangan, banyak organisai memulai project dgn langsung bergerak duluan, tanpa matang dipikirkan efeknya,

Kedubrag dubrag , pikir kemudian,

Kita telaah sebentar :

Project charter tdk bisa asal dibuat tanpa input dasar,

  • Customer background: ada banyak kejadian perusahaan gagal bayar, be aware
  • Contract/perjanjian kerja : ada hak kewajiban yg diatur,secara legal, ini sangat penting, di perusahaan besar, sebelum membuat PO, sblm create vendor id, name, info record, salah satu yg disyaratkan adlh approved contract, bidding result.
  • Agreement: yg paling penting PO, purchasing organization, SPK ada yg bisa, tp saran sy di kondisi ekonomi sekarang ini, mintalah PO,
  • User requirements
  • SOW, statement of works.
  • Organizational process asset: Proses, policy, procedure, lesson learned

Setiap organisasi unik, jadi pastikan anda paham dan mengerti organisasi customer anda.


  • Enterprises environmental factors. Government regulation, culture, standar, structure dll, sangat penting CULTURE.



Definition Project Charter at PMBOK fifth edition:


The project charter is the document issued that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.

It documents the business needs, assumptions, constraints, the understanding of the customer’s needs and high-level requirements, and the new product, service, or result that it is intended to satisfy.

Beda pmbok dgn prince

Dlm semua ilmu ada guidancenya, demikian juga utk project management,

Ada berbagai guidance best practise,

Yg ingin diulas disini adalah:
Pmbok project management body of knowledege  5th edition 2012


Princev2 2009

Bila anda ingin mendalami project,  dua diatas sangat dianjurkan utk dipelajari dan jgn lupa dipraktekkan ..

Cukup , tdk!

Project management adlh ilmu yg berkembang pesat terutama methodology dlm developmentnya,

Kl dulu water fall
Kemudian ada agile

Dan Trend sekarang adlh hybrid methodology,

Utk project life cycle:
Starting prepating executing n closing

Most of time
Most of project
Generaly recognized

Pmbok dan prince msh sangat relevant

As good practice
To enhance probability succesffuly of project.

Lalu apa beda pmbok dgn prince ?

Prince konsep dasar penting utk project governance

Bila anda ingin membuat sop business processes alur flow dr prince akan sangat membantu.

Prince berkisah tentang what is , why project management

Bagus dlm bahasa indah dlm konsep tapi utk best practice anda butuh bantuan supporting doc utk merealisasikan konsep prince

Konsep prince ada environment process themes masing2 ada componentnya


Lbh membumi mudah utk dicerna dan dipraktekkan

Bertutur ttg how project managemnt

Menjelaskan berbgi teknik semisal evm pert cpm slack dll

Dilengkapi ttg prjt mgnt interpersonal skill

Mau apapun project nya, is about subjectives to human factors, personal skill adlh mutlak

Dlm Konsep pmbok ada project management process group: initiating planning executing closing

Sbg header di horizontal

Utk header di vertical ada 10 project knowledge area : integrated scope schedule cost quality human rsc communit risk procure stakeholder

Anak dr knowledge area dgn prosess group ada 47, dinamai project mgnt process group description: project charter project mgnt plan dllllll.

Project Management adalah

Project management adalah ,

Adalah penerapan dari knowledge,skill, teknik & tools , agar sesuai dan bisa mencapai requirement  dari project.

Ingat perang bintang star wars perlombaan senjata diantariksa, rudal balistik benua, perang dunia satu dan dua,

Semua membutuhkan perencanaan koordinasi massive dgn biaya hampir tdk terbatas dijamannya dgn deadline waktu yg sangat sangat mepet.

Project management berawal dari hal2 yg luar biasa, dan telah dibuktikan bisa lbh baik.

Apakah project haruslah yg besar??

Ketika anda mudik anda targetkan budget anda py objective anda py schedule activities
Anda pun py project
Ya itu adlh  project.

Project adlh dgn waktu tertentu utk menghasilkan sesuatu bisa product ,service atau result

Bersifat unik
Punya start dan finish, timeline.

Balik keawal,

Jd project management, adalah berguna utk meningkatkan kemungkinan sukses , to enhance probability successfuly suatu   project

Berapa byk tak terhitung project gagal karena tdk berfungsinya project management.

Dari yg over budget,bleeding, molor waktu hingga gagal total..

Kunci kata project adlh customer dan requirement

Customer adlh perlu solution
Customer: they want to feel in something different

Project yg berhasil adlh delightfully customer dan meet with requirement

Comply fulfill requirement

Apa to ya requirement, diulang ulang terus

adalah sesuai business processes
Adalah sesuai dgn functional, contoh hasil dlm software aplikasi development: fungsi searchny jalan, print previewny bisa
Semua yg discope bisa berjln baik.

Adalah sesuai dgn nonfunctional
Ini adalah performance, availability, security dll
Byk kejadian ada sofware yg functionalny oke namun performance lelet banget dan tiba2 crash.

Dlm project management anda butuh knowledge , project management

Byk project manager yg sudah lama memakai title tsb tp tdk py waktu atau enggan belajar lagi

Knowledge projet mgmt anda bisa belajar dr best practise utk prj mgmt
Misal pmbok
Terakhir release efisi ke 5 thn 2012

Anda pun bisa belajar dr prince v2

Ada byk stdr yg lain tp saran sy focus dulu yg plng byk digunakan

Di prj mgmt ada juga teknik2 sendiri yg digunakan

Misal cpm,pert, earned value mgmt dll
Gak usah bingung, anda pelajari dulu yg paling anda sukai dulu

Kemudian skill,
Diprojct mgmt dibutuhkan byk skill,

Project manager kebyk bukan title jabatan tp functional

Anda harus bisa merangkul
Leadby example

Lesan tertulis anda hrs berlatih setiap hr

Negotiation skill win win solution

Problem solving

Persevering,patient, passion, praying
jgn mudah menyerah
jgn mudah emosi hrs tenang berpikir matang

Diproject tensi nya sangat tinggi
Anda hrs sabar tp tegas
Jelas jgn mengambang
Disatu pihak ingat constructive kritik
Jgn bikin down orng, merendahkan.
Ingat ada anak istri mereka dirumah
Jaga baik2 jgn sampai periuk nasi pecah

Disatu sisi diingat juga perusahaan menghidupi byk kepala keluarga, kl gagal bayar, efekny lbh besar

Ketegasan penting dilandasi kebijakan.

Anda matang diproject management bila sudah ada inner voice, framework-tata kelola-self governance, properly deliverable dan good perception, perception baik anda dpt dr jerih pyh kerja keras bukan office politics

Customers satisfied
Team happy
Company untung

Maaf kl salah2 typo, nulisnya sambil nyambi rebus ayam wkkk.


What Is Project Management ?

• According to DIN 69901, project management is defined as “all leadership tasks, organization, techniques and methods for carrying out a project”(ibid., p. 9). While this definition is obviously based on a very narrow concept of management – read “leadership”– the concept of project management is often much broader, particularly in English-speaking countries.
• In Pmbok: Project management is application of knowledge, tool & techniques to project activities to meet the project requirements
• In Prince2: The Planning, delegating, monitoring, control all aspects of the project and the motivation of those involved, to achieve the project objectives within the expected performance targets for time, cost, quality,scope, benefits & risk

Why Project management?
• Project must always be managed in order to be successful.
• Management is about human beings. Its task is to make people capable of joint
performance, to make their strengths effective and their weaknesses irrelevant.
This is what organization is all about, and it is the reason that management is the
critical, determining factor.
• Management must also enable the enterprise and each of its members to grow and develop as needs and opportunities change.
• Management is Practise not science.

cara simple membuat to do list action, perencanaan diri, mengatur waktu

To do list,

Ceritanya  Sebagai seorng project manager, pertama yg perlu dilakukan adlh bgmn bisa menata diri sendiri,

Self organized,

Mulai dr yg kecil menuju ke lebih kompleks,

A simple kanban board ,basic from to do list.



Setiap hari biasakan,

Dgn notepad, excel,onenote atau apapun

Mulailah hari dgn create to do list,


Simple tapi perlu pembiasaan,


Konsepnya adalah:


Tgn kita terbatas

Pekerjaan yg dilakukan buanyak

Waktu kita dibatasi timeline , work in process

Setiap hr ada target

Setiap hr dituntut harus efektif efisien



Buatlah perencanaan task/activity yg harus kita lakukan, focus dgn deliverable

Dan urutkan dgn urgency lalu importance



Buat weekly report project status

Call vendor

Invite weekly meeting

Meeting with procurement, beauty contest

Create email reminder fsd review

Create project closure

Learn princev2


List semua kegiatan yg anda rencanakan hr ini,

Ingat urgency dan importancy

Urgency yg harus dilakukan segera.

Importancy , penting utk dilakukan tp bisa menunggu.


Order by :

1.yg urgent dan penting

2.yg urgent

3. Aktifity yg penting

4.aktifity learning atau self improvement

Setelahny segera lakukan  task list yg sdh anda buat, : Plan,Doing,DONe

bila sdh bergeser ke doing atau done, berilah tanda, jgn ragu utk memberi catatan

Bila blm selesai hr itu, segera selesaikan hr berikutnya

Jgn pernah menunda pekerjaan.






Cara taktis Pemecahan masalah secara sistematis, Problem solving management,


Pemecahan masalah secara sistematis, / Problem solving management,
Masalah selalu ada dimana dan kapan saja,
Setiap hariny kita di challenge untuk melakukan problem solving secara cepat dan benar lagi,

Step2 scr sederhana digambarkan sebagai berikut:

1. Problem definition:
a. Problem definisi, apa sih problem nya? Apa effect/ impact nya, apa saja penyebabnya?
b. Didlm problem ada masalah technical atau socially , secara socially mereka tahu dan bisa tapi tdk mau , 
c. Anda harus definisikan secara jelas masalahnya.
2. Collecting data,
a. Kumpulkan data yang cukup, ingat pareto, 20 % adalah memberikan impact 80% pengaruh.
b. Kumpulkan data, dari yg terpercaya, dari tier satu, dari langsung sumbernya, jangan katanya katanya dan pikirkan scr objectives. Jangan berprasangka
3. Create option, solusi,
a. Ambil langkah2 solusi nya, list kan apa saja yg mungkin utk solusinya
b. Don’t wait the best idea, soon implement the better idea
c. Masing2 option, buatlah advantage dan disadvantage (plus minu, pro contra dll) , beri bobot utk yg mana paling menguntungkan utk diambil. Urutkan lah berdasar nilai tsb.
4. Select option, pilih option yg paling baik
a. Ambil keputusan secara bersama2 dgn pihak terkait,pilih yg terbaik
b. Ketika sudah dipilih, segera diimplementasikan

5. Monitor, review, bila tdk tepat jangan ragu utk memodifikasi
a. Ambil rentang waktu tertentu, utk mengamati hasil dari option tersebut,
b. Reviewlah, bila berlangsung baik, formalkanlah, socialization dan buatkan secara tertulis utk penerapannya.

Menata awal lebih baik dgn , Project management.


Menata awal lebih baik dgn , Project management.
Project management adalah culture,/budaya, culture adalah ditentukan pengalaman umum yg dilalui team member, organization,
Bila pengalamannya baik, akan lebih mudah penerapan project management, namun bila tdk ada atau kurang pengalaman, project management hanyalah sebagai penambah kerjaan, tdk mau dimonitor, ingin bekerja sesuai moodnya, dan bila ada kesalahan, rajin melempar alasan,
Bagaimana membuat pengalaman dan kesan yg baik dlm memanage project dgn project management,
Penerapan Antara satu perusahaan dgn perusahaan lain akan berbeda,


What works well in one company
may not work equally well in another.
Personality conflicts can occur at any time, with anyone, and over anything

Jangan pesimis, dlm lini hidup semua ada tantangan,
Yang pertama, adalah doing something, contribution, active, tutup telinga, bersihkan dari prasangka dan ikhlas,
Kemudian jauhilah jargon2 technically, berikan presentasi2 yg menarik,
• make sure the recipients know what the  mean and how they are used.

Presenting them in non-project management terms to project sponsors and other key stakeholders. This is much easier than training stakeholders on “project management speak” (whether they want it or not).
Contohnya anda manfaatkanlah feature timeline di ms project,

Sangat sederhana, tapi pesan yg anda sampaikan akan lebih masuk,
Berikan visual yg lebih menarik, tekankan dgn gambar.warna berbeda utk lebih menarik perhatian.



Utk membuat sangat mudah,
Buat project schedule anda,
Lalu view gant chart, right click , pilih add to time line
Di view time line,
Anda bisa customize sesuai kebutuhan,
Misal, ingin dlm bentuk default atau anda bisa Tarik dlm bentuk call out, anda tinggal, click hold ,lalu Tarik keluar.

cara sederhana mengukur KPI Cost & Schedule dalam Project

COST – Schedule Performance, mengukur KPI Cost & Schedule dalam Project

Project performance adalah cara utk kita mengukur, measurement utk project , tidak bisa semua ujug2
dlm artian hanya mengandalkan proses, tanpa controlling.

konsep sederhananya, bahasa awamnya seperti ini:

Where are we now?
saat ini kita ada dimana,
Where do we want tobe?
Target yg telah dicanangkan, compare current vs target

How to we get there?
dgn cara apa menuju ke sana, bila, current vs target – blm tercapai

How to check we got there?
measurement utk memastikan, kita menuju sasaran tepat, sesuai yg telah disepakati.

keberhasilan project dpt kita lihat dari kombinasi byk faktor, istilah PMBOK nya balancing the competing of project constrain:

project on time/ on schedule,
approved budget,
On scope
On resources
on quality, comply dgn requirement, fullfill dgn requiremne
customer satisfaction
project team happy
on risk.

earned value management adalah salah satu cara utk mengukur kesuksesan project UTK Project COST & Schedule,

Earned Value can change quickly and actual costs and project progress rarely occur as budgeted. However, Earned Value does serve as an excellent early-warning system, and looking at Earned Value trends can provide very useful data. It is most common to report Earned Value weekly, but this could be more frequent for a shorter project.
Customer Satisfaction and Quality are not captured within Earned Value calculations. While Earned Value is helpful for measuring project performance relative to schedule and budget

tidak perlu khawatir , bila anda belum paham, langkah pertama adalah membaca dulu 🙂 :
earned value,
value yang diperoleh : dr kegiatan yg telah dilakukan, dengan BUDGET YG telah disetujui.
, bukan activity yg masih belum dilakukan, bukan actual cost tp didasarkan dgn budget plan diawal.

karenanya earned value sering disebut BudgetED Cost WORK performED
pronuncation ed, menunjukkan past, yg telah dilakukan.
dlm bahasa yg mudah dicerna,

earned value adalah utk mengukur performance project dari sisi COST & Schedule,

EVM atau earned value, tdk bekerja sendirian, indikator yg utama yg dihasilkan dari EVM adalah SPI dan CPI,

SPI adalah schedule Performance: > 1, ahead schedule, < 1 adlh below schedule, =1 adlh on schedule , ( bila on schedule sja bagus, apalagi ahead schedule, slesai sebelum target waktu)
CPI adalah Cost Performance: > 1, under budget, < 1 adlh over budget, =1 adlh meet budget.

ketika kita misalnya renovasi rumah, target biaya kita 1000 usd,
bila actual 900 uSD : tentu bagus utk biaya, krn dibawah target. bayangkan kalau lebih,
dimana kita harus mencari sumber pembiayaaan lain. ini utk hal yg sederhana, dan kita ketahui di akhir project,
tujuan KPI Prject ini, adalah utk segera mungkin mengukur performance project ketika sedang berlangsung,
jadi bila ada trend over budget, kita segera melakukan langkah2 antisipasi.


bila scr plan harusnya kita mengeluarkan biaya 1000 di akhir project, tetapi EVM melebihi dari plan , misalnya 1200USD,
apakah ini bagus ataukah jelek?

EVM atau BCWP, perlu teman2 lainnya utk diukur.

siapakah teman2nya itu:


lalu anak2nya: SPI dan CPI

kita ulas sederhana:

BCWS: Budgeted cost work Schedule
ACWP: actual cost work performed

SPI: schedule performance index,
dari hasil hubungan : BCWP(EVM) / BCWS

CPI: cost performance index :
dr hasil hubungan, : BCWP (EVM) / ACWP

apa bedanya BCWS sgn baseline cost,
baseline cost, adalah total budget, tdk tergantung, waktu kita melihat, pokoknya total budget.
sementara BCWS adalah total budget, tergantung DGN dimana waktu kita melihat.

satu project ditargetkan selesai dlm satu bulan dgn budget cost : 1000 USD, ( 1000 usd adlh baseline cost)
ketika dlm waktu 15 hari, berjalan, BCWS nya adalah 1/2 X budget cost dlm satu bulan. 500 USD


dlm project plan : 5 hari workdays (satu minggu), target perhari menanam 10 pohon, dgn budget 100 USD per pohon,

setelah 3hari berjalan,:

kita ingin melihat performance project nya,


data yg diperlukan, hari dimana kita ingin melihat performance, setelah berjalan 3 hari,
target pohon 3 days X 10 pohon: 30 pohon,

BCWS= budget perpohon, 100 USD, utk 30 pohon jadi, 30X 100= 3000 USD,

data actual, dalam 3 hari, pohon yg telah ditanam, 40 pohon
BCWP= 40 pohon X budgeted perpohon= 40X 100 USD = 4000 USD
biaya actual yg telah dikeluarkan utk 40 pohon tsb : 3500 USD (ACWP)

SPI=BCWP/BCWS = 4000/3000 ( >1, yg berarti bagus)
CPI=BCWP/ACWP = 4000/3500 ( >1, yg berarti bagus)
yg dimaksud bagus, dlm 3 hari, bukan berarti bagus sampai akhir project, karenanya pengukuran performance ini harus kontinue,
memastikan sampai akhir project, nilai selalu bagus. Dan segera dilakukan perbaikan bila dibawah nilai standar.

Secara prakteknya, anda bisa terapkan ke dalam project schedule yg anda buat di microsoft project.

Buat project schedule,
lau create baseline, di menu project, set baseline

lalu masuk ke view resource sheet:
lengkapi resource anda, bisa material, work atau cost ( typenya)
utk basic, lengkapi dulu
Resource name, contoh developer, type pilih work, max 100%, yg paling penting disini STD RATe, isi rate nya bisa dlm jam atau hari. ( angkanya harus mendelati real, utk menjadikan cost accurate, amount bisa kita dapatkan dr HRD, per function ( average per funtion), jgn person, utk mencegah kecemburuan gaji,

kemudian assign resource, misal yg diatas developer ke activity di project schedule anda, dikolom resource name.lakukan asignmnet utk semua task.

lalu di view gant chart,

insert column sebagai berikut:
baseline cost, ACWP,BCWS,CPI,SPI

hubungan baseline cost dgn EVM adalah menu file, option, advanced, lihat agak kebawah -lihat earned value option for this project,
pilihlah baseline for earned value calculation.

cukup semua, belumm.

ingat EVM bisa diukur ketika project sudah berjalan,
artinya, project schedule anda, harus di confirmasi,

misal double click, task/ activity anda, hingga muncul summary task information, di percent complete, set hingga 100%.

ketika semua kita isikan dgn benar sesuai diatas, value SPI,CPI akan muncul.

Project management utk revenue yg lebih baik



Ketika kita dihadapkan banyaknya project, perlu ada nya prioritas, salah satunya adalah menampilkan, kondisi saat ini, as is, terutama kepada management, agar semua effort atau sumber daya yg kita kerahkan segera bisa menjadi revenue,
Cash flow,…
Ingat cash flow sangat penting, mulai dari bisnis yg sederhana, menuju bisnis yg lbh complex,

Prioritas, untuk mengerti titik crusial, yg menjadi foundation bagi arus revenue kita,
Bila dlm marketing ada segementasi, mengerti behavior, utk mengerti kebutuhan pelanggan kita, klasifikasi berdasar pattern, buying criteria, attitude n how they use our product. How we can improve within their opinion, how we can more competitive.
Didlm tulisan ini, ,saya akan menggambarkan , bagaimana memanage project –project , melakukan penerapan strategy, sehingga cash flow bisa berjalan , sehingga bisa memenuhi target dr management.
Dibawah hanya contoh sederhana , anda bisa mengembangkan ke tingkat lanjut, modifikasi tergantung tingkat kebutuhan.
Perlu pemahaman, program management, how to manage projects and operation to achieves program objectives,
Program management, adalah

  • how to manage project inter dependencies,
  • How to optimization manage among projects.
  • How to resolve common problems: Resources,budget,infrastructure,
  • How to align company strategy.

Terlalu teori ya .. wkkk.

Ingat dimanapun kita berada, semua problem hampir semua adalah sama, dari mulai yg kecil bisa kita hadapi, akan menjadi bekal menapak masa depan yg lbh baik.

Didalam project management , knowledge adalah sangat penting, implementasi dari knowledge akan mejadi performance, ditambah component dasar seorang management adalah, interpersonal skill, ( mendengar,mengerti , memahami people, led by example, leadership, communicative, negotiation, persuading, problem solving, persevering, persistence, patient, passion, anda harus mencintai pekerjaan anda, banyak orang yg bergantung, berharap, tanpa anda mencintai, hasil tak akan maksimal, yg anda lakukan tak bisa memberi kesan, yg terakhir adalah , praying, yes, praying, dalan project management, anda harus lbh byk mendekatkan diri, setiap detiknya, anda merasa harus bergantung dgn diatas, bergantung dgn melakukan yg terbaik yg bisa kita lakukan.


portfolio projects


Contoh diatas, adalah sampel sederhana, bagaimana mapping project sederhana, ingat hanya sample, anda bisa atur, modifikasi, sesuai term anda.
Tabel nya hanya sederhana, tapi maknany cukup dalam, cielahh…
List semua project yg ada, misal project A, Project B dsb
Lalu pilih parameter yg paling penting , disini saya contohkan, business value,gak perlu mumet2 , contoh bisa kita asumsikan, sales amount, atau profit/margin, uang yg akan kita dapat. Bayangin tentang uang wah kita lebih melek, semakin tinggi score misal 5, berarti margin percentage lebih besar.
Lalu Complexity, bisa bearti technology, atau bisa kita anggap time frame, waktu yg kita butuhkan utk implementasi, ingat ini hy contoh.

Anda harus memberi kriteria yg jelas dan disepakati dulu, score utk menggambarkan nilai real dilapangan,

Kalau kita baca grafik dibawah, ada project yg waktunya cepat tapi margin nya tinggi, ini lah yg jadi pundi2 kita, contoh dibawah project A.

Yg juga penting, anda lihat hasil revenue, account receivable kita, itu berasal dari mana saja,
Umumnya, project2 yg berdurasi pendek, dgn tingkat komplesitas medium, biasanya yg menjadi revenue kita,
Nah inilah yg harus dijaga, agar target penerimaan tepat,
Utk project2 durasi panjang, mungkin bisa dinegosiasikan dgn term pembayaran, schema yg win win solution, jadi bisa ada milstone terpisah yg jadi POC, percentage of completed, sebagai reference utk pembayaran.
Selain itu tertib administrasi sangat penting, komunikasi sangat penting, bisa project selesai, segeralah BAST kan, invoicekan, tagihkan, reminder kan, lagi, tutup project dgn sempurna dan tepat. Bila perlu project kan, byk kejadian account payable tinggi, tapi receivable nya rendah, How Come? Case yg byk terjadi adalah ketidak sinambungan internal /coordinasi lintas department, banyak kita berhasil utk project customer tp gagal utk membangun komunikasi dgn internal department.
Tdk kalah penting scope creep , batasilah scope anda, jangan tdk berujung, Causes of Scope Creep,:
• Poor understanding of requirements: This occurs when we accept or rush into a project without fully understanding what must be done.
• ◾ Poorly defined requirements: Sometimes the requirements are so poorly defined that we must make numerous assumptions, and as we get into the later stages of the project, we discover that some of the assumptions are no longer valid.
• ◾ Complexity: The more complex the project, the greater the impact of scope creep. Being too ambitious and believing that we can deliver more than we can offer on a complex project can be disastrous.
• ◾ Failing to “drill down”: When a project is initiated using only high-level requirements, scope creep can be expected when we get involved in the detailed activities in the work breakdown structure.
• ◾ Poor communications: Poor communication between the project manager and the stakeholders can lead to ill-defined requirements and misinterpretation of the scope.
• ◾ Misunderstanding expectations: Regardless of how the scope is defined, stakeholders and customers have expectations of the outcome of the project. Failure to understand these expectations up front can lead to costly downstream changes.
• ◾ Featuritis: This is also called gold-plating a project and occurs when the project team adds in their own often unnecessary features and functionality in the form of “bells and whistles.”
• ◾ Perfectionism: This occurs when the project team initiates scope changes in order to exceed the specifications and requirements rather than just meeting them. Project teams may see this as a chance for glory.

Anda bisa modif menjadi seperti ini:


Pertanyaannya bagaimana membuat grafik diatas, ternyata tdk sesederhana kelihatan nya , wkk.


yg pertama,

siapkan table dulu, yg sederhana saja, kalau sudah bisa, bisa ditambah lbh kompleks.


block table, insert chart, bisa dari rekomendasi atau pilih charts : pilih scatter

insert recommended chart




Design, dibawah kiri, pilih add chart element, pilih data label.

Muncul dibawah,
Cara lain,
Click kanan pilih add data label,
setelah itu click kanan lagi, pilih format data label,
Terutama dilabel option, utk excel versi terakhir, ada muncul value from cells, ( utk versi lama, tdk muncul)
Ini yg jadi utama utk memunculkan label/ nama projects.

Click dulu value from cells, lalu pilih data label range
Pilih data label range, sesuai table anda

Muncul lah berikut:
Utk menghilangkan nama complexity, untick lah series name, dilabel options:

Kemudian manual, buatlah seperti dibawah:
Data table , sederhana, tapi membuat grafiknya cukup melalui banyak tahapan.

, maaf capture gambarnya tdk urut, tp setidaknya anda bisa mencoba dgn tahapan by text diatas.

select point graph

add chart element


axis option



Apa sih earned value

Earned value management atau EVM
Apasih tu, aduh.. 
Pembahasan ini lebih menekankan awam seperti saya,

Dalam project management, KPI, parameter sangat penting,
parameter atau indikator sangat penting utk memberitahukan titik dimana posisi project kita berada,
earned value, adalah satu dari value yg bisa memberikan inputan parameter utk project.

saya tdk akan menerangkan semua,
yg saya ingin ulas adalah :SVI dan CVI, apalagi itu duhh..

balik dulu ke earned value, atau bisa disebut BCWP, budget cost work performed, atau simplenya budget (dr plan) utk kegiatan yang sudah done.
hubungan SVI dgn earned value adalah:
SVI= EV/ Plan Cost

SVI adalah schedule variance index,
Plan Cost adalah cost yg direncanakan diawal. atau juga bisa disebut BCWS, budget cost work schedule, secara simplenya adalah
biaya yg direncanakan utk kegiatan yg dijadwalkan ( ingat dijadwalkan, bukan yg sudah atau telah dilakukan).

Tentu anda sering mendengar waktu adalah uang, sama yg dimaksud disini , adalah inputan dari cost bisa dijadikan parameter utk
melihat apakah schedule kita, terlambat/sesuai jadwal/lbh maju dr jadwal.

Jangan khawatir bila masih blm paham, sama 🙂
tenang … nanti akan diberikan contoh sederhana.

CVI , adalah cost variance index
CVI= EV/Actual cost,
actual cost adalah biaya yg sudah terjadi.

nah lalu bila sudah ketemu ; CVI dan SVI utk apa?

CVI adalah parameter utk cost, bila hasilnya 1= adalah sesuai dgn yg direncanakan, bila kurang dari 1,adalah overbudget, dan ygpaling bagu
bagus adalah bila lebih dari satu= biayanya berhasil dihemat dari awal yg direncanakan.

sama utk SVI,

SVI adalah parameter utk schedule, bila hasilnya 1= adalah sesuai dgn jadwal yg direncanakan, bila kurang dari 1,adalah jadwalnya molor/terlambat, dan ygpaling bagu
bagus adalah bila lebih dari satu= pekerjaan berhasil diselesaikan dr jadwal yg direncanakan.

masuk ke case sederhana, yuk:


Kegiatan Minggu pertama
target menanam pohon dlm minggu pertama  ( satuan perpohon) 20
rencana  anggaran menanam perpohon (dlm USD) 100
total plan cost minggu pertama (USD) ( 20 x100) 2000
pohon yg telah ditanam dlm mingggu pertama 15
actual cost  at week 1 (USD) 1400


CVI:        EV/AC   EV=        1500       activity done X plan cost per activity        AC=     1400


SVI:        EV/PV   EV=        1500       activity done X plan cost per activity        PV=        2000



CVI:        1.071428571

SVI:        0.75

KPI dan Strategi implementasi Project Management Office


Discussion, saya ambil dr internet, dr para suhu2 project Indonesia 🙂


KPI PMO minimal perlu dilihat dari beberapa sudut yakni:

(1) apakah program/proyek-proyek yang masuk dalam lingkup kerja PMO tsb dapat diselesaikan dengan baik dan dapat memenuhi target waktu/ anggaran dan mutu serta kepuasan stakeholders dari proyek/ program terkait

(2) apabila peran PMO sudah mengarah pada governing commitee dan strategic portfolio management maka tentu saja kinerja PMO sudah harus dinilai dari kemampuannya untuk menciptakan overall long-term benefit utk sTakeholders dan juga sHareholders

(3) selain itu PMO dapat menjadi center of excellence dalam rangka pembinaan dan pengembangan para project leaders dan sebagai fasilitator dalam pengembangan dan penerapan practical methodology, tools dan procedures

KPI PMO berdasarkan 2 key stakeholders PMO, yaitu sponsor dan users.

  • Untuk sponsor, KPI nya sangat straight forward…project harus on time, on budget, within standard quality yg ditetapkan dalam PC.
  • Untuk users bisa dibagi menjadi 2, yaitu dr sisi project management dan change management.

– Proj.management lbh ke penilaian kesuksesan pelaksanaan milestone2 dalam project plan.

–Sedangkan change management lbh ke penilaian communication, training dan organisation assessment.

Pada setiap milestone, biasanya saya melakukan evaluasi dengan meminta penilaian users terhadap kinerja PMO. Cukup dibuat simple (small kuesioner atau interview) tapi diusahakan untuk dilakukan secara berkala


Pengukuran KPI di perusahaan (vendor side) antara lain:

  • Project delivery (on time, on scope, on budget)
  • Risk allocation usage => pemakaian aktual terhadap risk budget yg disepakati boleh digunakan
  • Customer Survey index => respon dari hasil survey kepuasan pelanggan
  • Implementation saving => Dibandingkan terhadap baseline target
  • Compliance procedure => biasanya ISO 9001:2008 atau yg lebih spesifik ISO 10006
  • Interdepartmental relationship => berdasarkan data survey internal



  • PMO bisa diartikan sbg Project, Program atau Portfolio mgt office. Masing-2 punya KPI yg sasarannya dari level taktis sd strategis, tergantung kebutuhan organisasi.
    KPI ini bisa dilihat detailnya di standard for project (pmbok), program and portfolio di 3 buku terpisah, keluaran PMI

PMO juga memiliki peran sebagai Competency Development Center untuk Project Management Reseources dan juga sebagai think tank dari PM Processes dan Assurance.
Jadi intinya tidak semata2 business oriented organization but system oriented organization


KPI untuk PMO acuannya banyak faktor yang mempengaruhi

  1. Posisi PMO itu sendiri apakah PMO berada didalam Portfolio, Program or Project ?
  2. Apakah organisasi PMO itu ada di sudut pandang Owner or Vendor
  3. Prespektif internal organisasi itu sendiri yaitu sudtu pandang sponsor dan sudut pandang user.
  4. Fungsi organisasiPMO itu sendiri, apakah organisasi PMO berfungsi sebagai consulting organization atau centralized organization
  5. Level maturity dari PMO yaitu berada di stage Project Office, Basic PMO, Standard PMO, Advance PMO, atau Center of Excellence


Implementasi PMO

1.Akan lebih mudah jika sifatnya top down…jd ide membuat PMO datang dr BOD atau level pengambil keputusan.

  1. Implementasi PMO disuatu perusahaan harus dibangun dengan memahami setiap sisi atas delivery atau implementasi project dr perusahaan tsb termasuk didalamnya strategi2, batasan2 atau kategori penilaian sukses suatu proyek…untk tahap ini BOD yang punya peran

3.Penerapan PMO sampai jalan membutuhkan waktu..pengalaman saya di beberapa perusahaan minimal 3 tahun yaitu:

tahun 1 kita petakan business prosesnya..mulai membuat sopnya..dan membuat strategi dan batasan yang diinginkan BOD perusahaan..intinya menyamakan presepsi..ini dilakukan paralel dengan sosialisasi

tahun ke 2 kita sosialisasikan dengan semua tim proyek atau BOD semua ….prosesnya paralel dengan proses evaluasi..

tahun ke 3 biasanya sdh bisa dilihat hasilnya..PMO nya sdh jalan

3 hal diatas sy lakukan dilevel perusahaan yg menangani banyak proyek… Kuncinya komunikasi dan menyamakan presepsi, alat ukur kesuksesan (on budget + on schedule) dari setiap tahapan project sehingga data lapangan bisa langsung dipakai sebagai bahan analisa di level PMO di head office..

Tapi kalau levelnya project mungkin lebih simple karena hanya melibatkan tim proyek dan owner saja jd waktunya lebih cepat..


Issue-Top management


  • Dukungan manajemen atas is a must..kalau ini tdk ada tdk akan jalan..jadi musti didekati 1 1 biar memahami manfaat nya. Kalau atas sdh mendukung kebawah lebih mudah.
  • Tp kalau sudah top manajemen (portfolio) biasanya KPI perusahaan tahunan..dr direktur utama diturunkan kebawah sampai ke operasional project (program)…sementara dilevel project turun ke tim project itu pakai project charter

–Untuk kpi biasanya..
1. Untuk aquisis sebuah project maksimum nilai investasi yg diijinkan berapa? Dan brapa proyek yg akan diambil dibidang apa saja dengan level resiko berapa

2. Revenue target tahunan berapa? Capex opex…dalam running project …%

3. Strategi marketing diijinkan sampai tahap mana?

4. Direktur operasional diberi kewenangan seperti apa….

–Sedang untuk proyek (project charter):
1. Kalau di tim project kewenangan PM sampai mana bs mewakili manajemen mengambil keputusan..

2. Berapa biaya operasional proyek (=nilai kontrak – biaya marketing + revenue perusahaan). Dr nilai itu budget proyek bs dibuat


Issue-Top management

  • Top manajemen memang waktunya terbatas dan kadang sulit membuat mereka involved. Itulah sebabnya sense of urgency, priority & perceived value of the project yang akan mengarahkan mereka untuk “do the right thing”…

dan disinilah peran PMO menjadi penting sebagai jembatan dan juga peran PM sendiri sebagai komandan di lapangan…


  • “Dukungan dan komitmen top mgmt itu seperti apa real-nya ?” saya percaya bahwa, belajar dari penanganan proyek MIS yang penuh intrik dan office politics selama bertahun-tahun, yang dimaksud dengan “komitmen” adalah “keterlibatan dan dukungan penuh” artinya “commitment is involvement not only promises or false hopes”…

–contoh kasus ketika saya terlibat dalam suatu proyek yang melibatkan beberapa senior people dalam sebuah “pm team/ steering commitee” yakni terdiri dari pejabat eselon satu sebuah institusi pemerintah dan project director (expat) dari sebuah perusahan MNC global…disana saya merasakan betul Keterlibatan, Keperdulian dan Kepemimpinan mereka on daily basis dan BUKAN hanya secara “SIMBOLIS” saja (semisal hanya hadir ketika ada formal meeting memberi sambutan, datang belakangan dan pulang duluan atau ketika bos yang lebih besar lagi akan hadir maka ybs kalang kabut supaya bisa “jaim”…)

–itulah versi saya mengenai “top mgmt commitment“…

–Pada dasarnya kapan seorang pimpinan puncak harus commited dan involved ? menurut saya terutama dalam keadaan kritis dan juga apabila nilai proyek yang ditangani sangat besar stake-nya dan juga apabila persepsi tingkat ketidakpastian dan risiko dalam proyek tersebut dianggap cukup tinggi..bahkan seorang Mahatir Mohamad (eks PM Malaysia) turut berpikir mengenai basic layout dari twin tower ketika mereka sdg mencari-cari karakter yang pas utk rancangan menara kembar tsb….


Sharing Strategi implementasi pmo,

  • Problem:

–implementasi sangat resistance sekali dengan adanya organisasi pmo dimana mau tidak mau departemen2 lain yang menjalankan proyek terkontrol dan termonitor.

–dipengalaman malah ada beberapa project yang project managernya membuat “pmo bayangan” dimana mereka merekrut orang untuk menjalankan fungsi pmo tetapi dibawah supervisi project lead, bukan organisasi pmo. Hal ini terjadi karena walaupun mereka kurang nyaman “diatur” dan dikontrol, tetapi mereka juga tahu betul kalau membutuhkan pmo

  • Usulan

–Ada Strategi yg selalu diterapkan yg cukup single:

Contribute and Do things right since the first time.

Singkatnya, sejak pertama kali pmo dibentuk…manajemen beserta proj.manager harus dengan clear mengkomunikasikan keseluruh team apa fungsi pmo dan bagaimana pmo dapat membantu kesuksesan project. Kemudian, saya selalu tekankan kepada anggota tim untuk selalu aktif dan berkontribusi…mensupport project team dengan sepenuh hati 🙂

Seringkali project yg kita tangani memiliki schedule yg ketat, sehingga “no room for error”, menuntut semua task harus dikerjakan dengan benar sejak pertama kali. Disinilah pmo bisa banyak berkontribusi dan pasti akan dirasakan manfaatnya oleh team yg lain.


  • Respond (dari penanya)

–Saya pikir implementasi pmo merupakan fase yang tersulit diantara fase lainnya.

  • Usulan:

–Harusnya tdk sesulit itu kecuali pmo masuk di tengah-tengah kultur proyek yg sdh memiliki sub kultur dan kepala suku masing2 dgn pola kerja dan pola pikir masing2..
Mungkin perlu ada sosialisasi bahwa kehadiran pmo akan membawa benefit dan bukan sbg beban.
Tentunya penerapan dan perencanaan pmo sebaiknya secara bottom-up dan tdk di-impose mendadak sebagai “pengawas” proyek2..


  • Respond (dari penanya)

–kalau kondisi ideal, business cepat sekali berubah, manajemen dengan cepat akan mengambil suatu langkah dan keputusan untuk mengendalikan business itu.menurut saya yang terpenting adalah apakah cultur perusahaan siap menerima perubahan tersebut? Itu yang menyebabkan resistance