Manajer Proyek - Kunci Produktif Dalam Pengawasan Proyek

manajer proyek

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

Apakah Manajer Proyek Perlu serttifikat?

Bulan lalu, PMI mengumumkan peluncuran sertifikasi baru untuk manajer proyek berpendidikan. Mereka yang ingin mendapatkan sertifikat PMI gesit harus lulus ujian menantang untuk membuktikan bahwa mereka mampu menerapkan metodologi tangkas di tingkat profesional. PMI akan mulai menerima aplikasi pada Mei 2011. Laporan Institute bahwa sertifikasi baru dikembangkan oleh para praktisi yang ahli untuk didirikan dan didasarkan pada cara-cara yang dapat diandalkan untuk menilai kompetensi. Anda dapat mempelajari lebih lanjut tentang sertifikasi baru dan persyaratan kelayakan di www.pmi.org.

Organisasi-organisasi lain, seperti Aliansi Agile, telah menawarkan sertifikasi sendiri tangkas sebelumnya. Namun Project Management Institute, dengan lebih dari setengah juta anggota dan pemegang mandat di 185 negara, pasti organisasi yang paling berpengaruh dalam ruang manajemen proyek, jadi menyenangkan untuk melihat PMI sekarang resmi mengakui tangkas sebagai tren signifikan dan tak terbantahkan dalam proyek manajemen.

Memang, ketrampilan manajemen proyek  telah datang jauh dari pendekatan baru untuk suatu metodologi manajemen proyek utama. Ini melampaui bidang ibunya, pengembangan perangkat lunak, dan digunakan dalam sebuah set semakin luas industri saat ini. Hal ini tentu meningkatkan kebutuhan bagi para profesional gesit, dan pengusaha ingin memastikan bahwa mereka mempekerjakan orang yang tepat untuk pekerjaan itu. Di sinilah sertifikasi berguna.

Yang mengatakan, masih ada banyak lawan seluruh ide sertifikasi tangkas. Sebagai contoh, salah satu argumen utama untuk Michael Dubakov, seorang penulis di Edge of Chaos blog, adalah bahwa ada begitu banyak faktor yang mempengaruhi proses manajemen bahwa mereka membuat sertifikasi apapun mustahil. "Perusahaan Anda adalah khusus. Anda memiliki orang-orang khusus pada tim pengembangan. Anda memiliki kondisi khusus, peraturan dan faktor eksternal lainnya, "tulis Michael.

Apa pendapat Anda tentang sertifikasi PMI baru? Apakah Anda menganggap itu untuk diri sendiri atau karyawan Anda? Silahkan memposting pemikiran Anda di komentar di bawah ini.

3 Ways to Build Excellent Teamwork

manajemen konstruksi
Hampir semua kisah legendaris tentang kejayaan perusahaan atau organisasi selalu dibentangkan oleh sebuah tim kerja yang ekselen. Penemuan lampu bohlam pertama ternyata tak hanya diracik oleh sang genius Thomas Alva Edison, namun lantaran ditopang oleh puluhan anggota tim-nya yang bekerja tak kenal lelah, melakukan eksperimen hingga ribuan kali. Medium internet yang sekarang tengah Anda nikmati juga diracik oleh kolaborasi puluhan programmer yang bekerja di lembaga Darpa Defense Project. Dan kisah Facebook yang fenomenal itu diusung tak hanya oleh Mark Zuckerberg namun hasil kolaborasi sang pioner dengan tiga rekannya yang sama-sama punya peran fundamental.
We don’t create superman/woman, we develop super team. Demikian kredo yang kini kudu diusung dengan penuh bara antusiasme. Sebab tanpa kualitas tim yang top markotop, sebuah organisasi bisa limbung ditelan arus perubahan yang terus menggilas tanpa kenal letih. Kalau demikian, dimensi apa saja yang amat penting untuk membentangkan sebuah tim legendaris?
Beragam studi tentang team effectiveness, menyuguhkan tiga keping elemen yang layak diperhatikan kala kita hendak membangun tim yang tangguh.
Elemen pertama, tak pelak lagi adalah : team leader yang kredibel. Anda boleh punya tujuan tim yang heroik, atau punya para anggota team dengan talenta yang mengagumkan. Namun tanpa team leader yang inspiring, sebuah tim bisa terseok-seok di tengah jalan dan lalu terpelanting.
Anda sendiri mungkin pernah punya pengalaman menjadi anggota tim dimana ketua (atau team leadernya) tak punya talenta, atau yang kecakapannya abal-abal. Pelan-pelan para anggota tim bisa digayuti rasa frustasi, kehilangan arah dan goyah; lantaran sang ketuanya gagal memberikan panduan yang jelas dan inpsiring. Semangat dan spirit kerjasama tim juga perlahan redup lantaran kegagalan sang leader untuk membangun komunikasi yang tegas dan monitoring yang konsisten.
Dalam kondisi seperti diatas, tak banyak asa yang bisa dibentangkan kepada tim. Kondisi seperti itu telah membikin potensi tim retak, sebelum ia menemukan momentum untuk menjadi super team. Itulah kenapa, memilih team leader yang kredibel adalah sebuah kata kunci.
Elemen yang kedua adalah ini : sebuah tim hanya akan mekar kinerjanya jika ia memiliki tujuan/sasaran yang jelas, dan tak kalah penting, segenap anggota tim saling koordinasi untuk memetakan dimana peran dan tanggungjawabnya dalam mengejar tujuan itu.
Di tempat kerja acap kita temui antar anggota tim/bagian dalam organisasi saling bekerja sendiri-sendiri, tanpa koordinasi yang jelas; seolah-olah masing-masing pihak punya arah yang bersimpangan. Sialnya masing-masing juga acap tidak mampu membangun komunikasi yang yang lancar.
Komunikasi dan koordinasi sungguh dua kata yang sederhana. Namun sering kita menyaksikan dua kata ajaib itu lenyap. Yang kemudian menyeruak adalah kinerja tim yang lamban, saling menyalahkan, dan terseok-seok menjawab tuntutan zaman.
Itulah kenapa elemen kedua ini amat penting : setiap tim harus punya mekanisme sistematis untuk membuat masing-masing anggotanya saling memahami apa kontribusinya bagi pencapaian tujuan tim.
Elemen yang terakhir bagi munculnya great team adalah ini : terbangunnya sense of togetherness yang solid. Atau spirit kebersamaan demi tergapainya tujuan tim. Disini yang tak boleh muncul adalah perasaan egoisme yang kental (gue yang paling berperan dalam tim ini) atau juga ego sektoral (bagian atau departemen kami yang paling penting; atau kami ndak mau tahu kerjaan bagian lain).
Bagaimana semangat kebersamaan tumbuh mekar dalam lingkungan semacam itu? Itulah kenapa yang harus dimunculkan adalah sikap kebersamaan : sikap untuk saling peduli antar sesama anggota tim. Dan juga sikap untuk dengan penuh antusias saling membantu dan berkoordinasi (sekali lagi, koordinasi!!) demi tercapainya tujuan bersama.
Itulah tiga elemen kunci untuk menghadirkan great team. Kita juga pasti akan merasa enjoy jika terlibat dalam great team. Spirit kebersamaan yang kental dan kinerja tim yang handal memang akan membuat kita kian happy dalam bekerja.
manajemen proyek 

Defining Project Goals and Objectives

The very first step in all projects: business, home, or education, is to define goals and objectives. This step defines the projects outcome and the steps required to achieve that outcome. People, including project managers, do not spend sufficient time on this step or complete it incorrectly thereby ensuring an unsuccessful project completion.
Poorly defined goals and objectives, or goals without objectives, pushes a project into overruns, territory battles, personality clashes, missed milestones, and unhappy clients.
Goals and objectives must be clear statements of purpose. Each with its own purpose that drives the end result of the project. Goals and objectives MUST be measurable.

Goals are the "WHAT"

Goals are broad statements applied to a project. Goals are the "what" of the process. In other words, "what" will the project accomplish? Projects may have more than one goal, but many objectives per goal. Do not confuse goals with objectives.

Examples:

1. Website development goal: Visitors will be convinced that global warming exists.
2. Insurance company: The Medical Insurance department will increase provider options by 10%.
3. Physicians office: Patients will not wait longer than 1 hour to see a physician.

Objectives are the "HOW"

Objectives are specific statements that support the goal. Every goal will have one or more objectives tied to it. In essence, the objective is the "how" of the process.
Always start an objective with an action verb. This ensures that the objective is measurable and that the projects end-result is addressed through the action of the objective. Each objective becomes a measurable milestone as well.

Examples:

1. Goal: Visitors will be convinced that global warming exists.

• Create a table comparing the costs of addressing global warming today verses 100 years from now.
• Illustrate the effects of global warming in a photo gallery.
• Identify and address the "myths" of global warming.

2. Goal: The Medical Insurance department will increase provider options by 10%.

• Identify provider options and costs.
• Survey the customer to find out each options value.
• Compare options to competitors.

3. Goal: Patients will wait less than 1 hour to see a physician.

• Evaluate personnel requirements.
• Purchase new appointment scheduling software.
• Setup appointment confirmation schedule.

Keeping goals and objectives in the forefront of every project ensures that the project and the team are on the same page throughout the projects life cycle.
Whether in education, business or are running a household, clearly defined goals and objectives will support the projects successful result.
Project Management manajemen konstruksi

Managers, Programmers, and Designers

Depending on the structure of your organisation, the project manager is most likely the person who interacts with the broadest range of stakeholders. Sure the managing director will intermingle with project managers, business development, maybe even the client at early stages. But a project manager will interact with all these people and more; most notably, technical staff such as programmers and graphic designers. And let's not forget the client; a project manager will probably spend the largest amount of time with them compared to anyone else.
Every now-and-then someone comes along with a ground breaking theory or universal law that's so simple its mind-blowing; Maslow's Hierarchy of Needs, Covey's 7 Habits of Highly Effective People, and of course the three business personalities described in Michael Gerber's classic book The E-Myth (i.e. entrepreneur, manager, and technician).
For those not familiar with the book, what follows is a brief summary of the personality types:

• The entrepreneur's work is strategic in nature, involves focusing on the future and developing a vision of where they want to take the business.
• The manager's work is both strategic and tactical. The manager's focus is on the present and achieving results through others. They are concept to reality facilitators.
• The technician follows the guidance of the manager to get the work done. They focus on the present and are hands-on.

The E-Myth is about much more then just these personality types. It's about the pitfalls of starting your own business, and how to build a business which allows you to live the kind of lifestyle you want.
We are all combinations of these characters to different degrees. Some of us are half manager half technician, others are very entrepreneurial, and so on. Understanding these archetypes can be very helpful when working in a team environment.
I am about to make some generalisations, and as with most generalisations they should be taken with a grain of salt since there are always exceptions. Programmers and designers commonly fit squarely into the role of technician, perhaps with a splash of manager (by designer, I mean graphic designer).
There are a number of contrasts between programmers and designers, even though both are fundamentally creative disciplines. Perhaps this is because the work of a designer is visual and more apparent to users, whilst a programmer's output is functional and more 'under the hood'.
I interviewed a professional graphic designer to find out her thoughts on the interaction between managers and technical staff, here is what I found:
Q. "How do designers differ from programmers?"
A. "Programming is objective, design is subjective. Designers work with imagination [whilst programmers are more academic]."
Q. "How should a manager go about asking a designer to make changes to their work?"
A. "[Managers should refrain from] involving themselves in the design process. Changes need to make sense and be based on solid reasoning. [Berating comments should be avoided]."
Q. "How can a manager's input be counter-productive to the design process?"
A. "There is nothing more frustrating then a manager trying to be a designer. [There needs to be] concrete reasoning behind the suggested correction."
Q. "What are the most common issues between designers and managers?"
A. "When a manager shuts down creative flow by being too overbearing. [Micro-managing or meddling] is a common problem."
Q. "Should a manager's opinion on visual design hold less weight than a designer's?"
A. "Unless working in a small business, [managers don't] need to involve themselves in design. Opinions and feedback are always welcome, [but emotive recommendations should be kept to a minimum]."
Q. "Would it bother you if someone changed your work without asking you first?"
A. "[I would] not be happy. [Managers wouldn't like their processes being bypassed without being consulted first]."
- Vera Babenko, Lead Web Designer, ANZ Bank.
I have shortened or paraphrased the interviewee's answers. The changes have been checked by the interviewee to ensure the original message has not been lost.
A pattern I have noticed with graphic designers, which does not seem as prevalent in programmers is that it can be quite an upheaval to suggest a change, or even worse, to go ahead and make a change without their prior knowledge, a move rarely conducive to harmony within a team. Perhaps the reason this phenomenon is more prominent in designers is because artistic endeavour is so subjective; what looks good to one person may look uninspiring to another. When a programmer is asked to make a change in functionality, it generally has a tangible and visible affect, something people can agree on.
When working directly with designers, I will often make suggestions based on my strong usability background. Even though I have seen graphic designers violate well established best-practice usability guidelines (e.g. using '|' as a breadcrumb hierarchy separator instead of '->'), I never insist on a change. What I generally say is something along these lines: "have you thought about changing this to this because...?" If they don't want to change it, I don't push the issue.
To me it's beside the point whether I think I know better, the designer's work is their dominion and their responsibility. The only time I would revisit the topic is if the client wasn't happy with it, then I would come back to the designer and say "well, regardless of whether the change is right or wrong, the client wants it the way they want it".
consultant management Construction Management

Virtual Teaming Soft Skills Relevant to all Projects

One of the most critical aspects of project management leadership is the effective use of communication to facilitate the team process. Effective communication is one of the key enablers of building cohesive teams and is critical to the successful management of key stakeholders. The probability of communication breakdown is intensified in the virtual environment. Consider for a moment that the majority of virtual project teams will never meet face-to-face. Because over fifty percent of communication is nonverbal, we lose a significant amount of message content if we cannot view the other party we're attempting to communicate with. Significant feedback can be gathered by paying attention to body language and facial expressions while we're communicating.
Due in large part to corporate downsizing, strategic outsourcing, and reallocation of organisational human resources due to mergers and acquisitions, virtual project teams are becoming more the rule than the exception. When we think of a virtual teaming environment our thoughts often gravitate toward globally-dispersed projects. In global project environments virtual teaming and leadership skills are an absolute necessity for the project manager and the team.
Cultural diversity was once one of the largest differences between a traditional project team and the virtual project team. Today, cultural diversity is the normal team composition which has introduced a greater degree of tolerance amongst people who realise that the person they are dealing with may or may not know their cultural norms. Consequently, the problems that do arise are much more severe as they are now beyond the tolerance limit already expended. Even if a team is not geographically dispersed, it's likely to be comprised of team members representing a multitude of cultures and backgrounds. Differing backgrounds and experiences is a great advantage, which diverse teams have over others as diversity leads to diverse thoughts and creative action. It also presents a challenge for the project leader. The challenge is ensuring that every team member is listened to, respected, and has his or her suggestions seriously considered.
Increasingly, virtual teaming skills are becoming critical to the management of projects even if the project team resides within the same geographical region or, even if the team is collocated. I've personally been involved in several projects in large organisations with the majority of the project team residing in one building and the remainder only a building or two away. This lack of immediate collocation can result in team members feeling disconnected and misunderstood which is a significant problem for the project leader. When a team member perceives they're not being taken into consideration their communication has a tendency to stop and information is often guarded.
Recognising individual identity and taking the time to entertain all viewpoints is the keystone of building positive working relationships and trust. The trust which team members have in their leadership, and in each other, is paramount to project teams performing effectively. This trust is one of the elements which energises and empowers every team member. The longer this cycle recurs, the greater the team synergy.
When it comes to building trust, treating your collocated team as if it were a virtual team can be a very effective way to help you expedite the process. Remote team members typically lack the face-to-face time which is so instrumental to building rapport, understanding individuality and enhancing relationships. To overcome this barrier, remote teams must extend respect and train themselves to refrain from making assumptions or jumping to premature conclusions. Teams are especially susceptible to premature assumptions being made in multicultural team settings. Virtual teams are able to more readily overcome this barrier because they are inherently more aware of this dynamic when engaging in team discussions. How many project teams have you led, or been a member of, that could have used this technique more effectively?
All of the preceding discussion items have been challenges which the virtual project team must work to overcome that collocated teams take for granted although they face many of the same challenges. However, some very specific advantages related to these challenges exist, which the virtual team has over the collocated team.
First, consider that, in addition to communicating message content, an individual's body language and facial expressions also serve to communicate social status, personality, and position within the organisational hierarchy. These cues are less likely to affect virtual teams. What this relates to is that virtual teams can be less apprehensive when it comes to speaking what's on their mind or challenging an idea, which has been put forth by an individual higher up in the organisation. The bottom line is that typical hierarchies, both formal and informal, are less evident in the virtual environment. If handled properly by the Project Manager, this "less evident" hierarchy can potentially turn every interaction in to a synergized brain-storming. This can be a great asset to every team.
Another advantage enjoyed by virtual teams is that team members will be less likely to be judged on the basis of sex, race, religion, national origin, class, or age. Regardless of what we'd like to believe is the case, humans still judge based on appearance first and content second. This is largely due to past experience, our childhood, and other internal belief factors. Having the ability to remove this personal filter is a very powerful advantage and, quite frankly, one that we can all benefit from if we take the time to actively remove it, i.e. - understand that it's at work and reduce its impact.
Since virtual teams are fast becoming the rule rather than the exception, we will all be required to use these skills at some point in our project leadership careers. As project managers, we may as well all learn and utilise them sooner rather than later as our project teams, our organisations, and our projects themselves all stand to gain from their implementation.
Project Management manajemen konstruksi

Top Seven Questions for Starting Projects More Effectively

We are all project managers. Some of us manage projects like vacations or reunions, while others run implementations of new software systems, consolidation divisions of companies, launch new products, or build buildings. While the scale changes for different kinds of projects, and complexity changes as more people are affected and involved; at the core there are questions you can answer to help get any project off to a better start.
Here are seven of those questions you should ask (and answer!) when initiating a project:

1. What can I do at this early stage to increase the likelihood of project success? This question gets you thinking about the key things to do now. Often at the beginning, especially of big projects, people focus all their effort on planning. While planning is certainly important, sometimes there are actions other than "to plan" that need to be done early.
2. What skills will I need to complete this project, and who are the right people for the team? Seldom can we do it alone - and on big projects this question will get asked several times during the course of the project. Getting the right people with the right skills on your team is critical and needs to be done as soon as you can.
3. How do I influence and persuade these people to be committed to this project? It is one thing to identify the people you want on your team. It is another to help them understand why you want them, the roles they can play, and influence them to choose to be involved when they have other competing interests and opportunities. Even in a corporate setting where people can be placed on or assigned to a team, we need to think about how we will gain their commitment, involvement and passion in the project outcomes.
4. What are the major deliverables for this project? A key part of any project plan is to outline what the outcomes will be. Answering this question is a critical part of your project planning, and sometimes overlooked as people focus only on the final end results, not considering the major deliverables along the way.
5. What are the major steps in my project plan? Actually that is the question you want to answer, but isn't where you want to start. Start by brainstorming on - "what are all the things that will need to be done in this project?" Don't worry that you won't think of all of them - you'll think of more later! Get down on paper everything that you can think of first, and then ask the second question - "what are the major steps?" From your big list you will be able to identify the key steps and then group the other steps "inside" the major steps.
6. How detailed does my plan need to be at this stage? Think about the complexity of the project, the number of people involved and the skill and experience of those people. All of these factors (and potentially many more) can play into the decision of how detailed to make your plan. Make your plan detailed enough that people are clear on the deliverables and know what is expected of them by when. Perhaps the plan will need greater detail later and you will leave that to team members responsible for those components or maybe you need to develop that detail up front. This is one of the things you should be considering and balancing at the start of the project.
7. What can I do at this early stage to ensure fewer risks and obstacles during the course of the project? Think about the end of the project for a few minutes. Imagine today what obstacles, stumbling points and hurdles have had to be beaten to get to this successful completion. Then step back and ask yourself how you can eliminate the obstacles, bridge the roadblocks, and clear the hurdles now. This is one of the best uses of your time at the start - to take steps to reduce or eliminate these things, before they can occur to stall or delay your project.

manajemen proyek management consulting

Capturing Those Lessons Learned

Do you capture your lessons learned? If you do, how effectively do you capture them?
There are many reasons why lessons learned are not captured, or, if they are captured, not used, including:

• Lack of time
• Lack of management support
• Lack of resources
• Lack of clear guidelines around collecting the information
• Lack of processes to capture information
• Lack of knowledge base to store and search information captured for future us

We all have good intentions to do so, but often don't get around to effectively capturing lessons learned from projects. Often, if we do try to capture lessons learned, we do so at the very end of the project - getting the team together to try to remember what worked and what didn't. With short projects - maybe just a few weeks in duration - this might work well some of the time. The team hasn't forgotten anything. Just catch them before they are off to the next project!
For longer projects though, it is difficult to wait until the end to attempt to capture what is learned. Too often team members are ready to move on, or they have forgotten much of what should likely be captured. Better to track lessons learned throughout the project, as much as possible. For example, track the following as it occurs on the project, including the team's response to the situation, the resolution/outcome, and comments:

• Risks or issues
• Quality defects
• Vendor issues
• Change requests

By tracking these situations throughout the project, everything is fresh in your head as it has just occurred. You can then compile the information at the end and develop a more comprehensive lessons learned.
Other areas worth capturing on projects, detailing what worked well and where improvement is needed include:

• Requirements management
• Scope management
• Schedule development and management
• Cost estimating and budget control
• Quality planning and management
• Resource allocation
• Teamwork/team performance
• Problem solving/issue resolution processes
• Communication management
• Stakeholder identification and management
• Status reporting
• Risk identification and management
• Procurement planning and management/vendor management
• Process improvement initiatives
• Change management process

Detail also areas where the team performed exceptionally on the project and areas where improvement is needed. Delineate options for improvement - be specific.
For each area (process) reviewed, capture:

• What is the situation/issue that occurred during the project
• What actions were taken or alternative considered to fix the issue
• What worked well
• What can be improved upon
• Other information that may help other project team members
• Shared learning, what is your advice to future project teams

Finished Capturing? Your Job's Not Done!

Once you have captured lessons learned - make sure they are easily referenced by other project teams. Keep them in a location where they can be easily found and searched - maybe a project portal or intranet site. Start every project by accessing past project lessons learned. Track improved effectiveness and efficiencies on projects based on applying the lessons learned from past projects. In this way, the lessons learned from past projects help to increase the success of future projects. Make a component of every project a requirement to review the lessons learned from past projects.

Summary

Capturing lessons learned is of vital importance. Unfortunately, it is often forgotten at the end of the project - people just want to move on to the next assignment. By assigning an individual on the project (ideally an individual trained in capturing what is learned) to lead the capture of what is learned from the beginning of the project, and tracking throughout all the stages of the project, you won't feel so pressured at the end to fit it in.
The more mature the project management function within the organisation, the more likely that lessons learned are captured, internalised and applied to all future projects. Effective transfer of knowledge from what is learned is not solely to other project teams, but also to the organisation as a whole. These organisations which are more mature will capture lessons learned not just from the project team, but also from customers, contractors, and other internal staff. These organisations likely also have a formal process for capturing what is learned to ensure there are consistencies among all project teams.
management consultant management project

Ten New Rules for Project Managers

These ten ideas will help improve your projects. Are these ten rules the top ten? You decide. But don't take too long. Share these rules with your team. Your team members are sure to help you carry them out.

1. Adopt practices for exploring a variety of perspectives.
   We think we see what we see, but we don't. We really see what we think. Remember the blind men and the elephant. Make it your habit to inquire what others see. You'll see more together.
2. Stay close to your customer.
   Clients' concerns evolve over the life of a project. Take advantage of that to over-deliver. Stay in a conversation with your client to adjust what you are doing.
3. Take care of your project team.
   We've come to accept that the customer comes first the customer is always right. We can't take care of the customer if we first aren't taking care of our project team. It's a challenge. While there are some things we can do for the whole team, it comes down to taking care of each team member as the individual that he or she is. And to make it more difficult, then we must bring their various interests into coherence.
4. Keep your eye on the overall project promises.
   Project work can be difficult. It is easy to loose sight of what we are doing and why we are doing it. Remind your team and yourself of the overall promises and how you are doing fulfilling those promises.
5. Build relationships intentionally.
   Project teams come together as strangers. To do great work, innovation, learning, and collaboration all take people who like and care for each other. Don't leave that to chance. Start your projects by building relationships among team members.
6. Tightly couple learning with action.
   Projects are wonderful opportunities to learn. Don't put that off for the after project lessons learned. Make it your habit to incorporate learning loops in all your project activities. Your team will appreciate it. Your customer will benefit from it. And best of all, it will make your job easier.
7. Coordinate meticulously.
   A project is an ever-evolving network of commitment. Keep that network activated by tending to the critical conversations. See that people are making clear requests, promises that have completion dates, and share opinions that advance the purposes of the project. Without attention to those critical conversations the project will drift.
8. Collaborate. Really collaborate.
   Make it your rule to plan with those people who will be the performers of the plan. Don't wait until the project has gone south to get their help. Start out that way. Continue collaborating as the usual way you work through the project.
9. Listen generously.
   People are able to say what they can in the moment. For the most part, people are well-intended. Give them the benefit of the doubt. Take the time to listen. Ask questions. Seek others' opinions. And while you're at it, don't be so harsh on yourself.
10. Embrace uncertainty.
    Expect the unexpected. There is far more that we don't know and can't know than what we can anticipate. Be resilient to what life throws at you. Anticipate that your team will learn something along the way that can and should change what you have promised and how you can deliver on your promises. And when you take a set-back - we all do sometime or another - review the other nine rules for how you can work your way out of it.

manajemen proyek management consulting

Helpful Suggestions For Managing Difficult Clients

Every consultant has had to deal with a difficult client. The nice thing about being a consultant - you just need to get through the project and you will be able to move on - you don't necessarily have to work with that client ever again. But really, that's not what you want, is it? Ideally you develop a strong working relationship with a client so that when another project comes up, the client thinks of you first. You become a partner with the client, not just a one-time deal.
There are many examples of what might be considered a difficult client - refusal to pay for services rendered (certainly sometimes with good reason), frequently changing the objectives of the project, not signing off on documents to move a project forward, avoiding responsibility for their component of the project (e.g., not making needed decisions), pressing for solutions before analysis is completed, etc. These are just a few examples - no doubt you have many more!
Let's look at how to best handle difficult clients. One thing I have found to be most beneficial is to develop strong client working relationships right from the very start - this builds trust and credibility and makes the difficult conversations with the client a bit smoother and easier. I often find that difficulties with clients arise when things are not agreed upon in the first place or are not well documented.
Difficult clients sometimes look for an "out" of their agreement with you. To avoid this, I recommend documenting all conversations with a client right from the beginning of the first contact with them. I do this and it seems to be quite effective. I share the information with them as follow up to a phone call or a face-to-face meeting we have had. This helps to ensure I understand the client's needs and have not forgotten anything. It also provides the client with the opportunity to add to the status report - correcting what I may have misunderstood or to add in some new piece of information he/she may have forgotten during our conversation. It always includes a "next steps" section with due dates and roles and responsibilities. This document also serves me well if there is a misunderstanding or expectation from the client once a project is underway. I can always refer back to this documentation, and refer the client back to it, to clarify something or correct any misperception. When working with a client on developing the scope of the project, be sure you are working with the right person at the client site. You want to be working with someone with the authority to make decisions and sign off on documents (such as the project charter and project scope statement.) Don't just assume the individual working with you is authorised. I have seen this get many consultants in trouble with the client and gives the client an out in paying the invoice.
When working on a client project, I update the client, at least weekly (sometimes daily depending on the project) on the status with a formal report. My status report will include at least this information:

• What should have been accomplished in the week.
• What was actually accomplished in the week.
• Any variances and why (root cause of variances).
• Activities to be accomplished in the following week.
• Any issues identified and corrective actions planned or preventive actions taken.
• Any questions or issues I need the client to address.

I follow up the status report with a phone call or a face-to-face meeting. This keeps the client in the loop regarding the project's progress and lets them know of any issues right up front and how they are being addressed or if I need the client's support in addressing the issues. No surprises this way and the client can't state later that no information has been shared with them or that they didn't know about an issue. A client who is kept in the loop feels better about the project - even if there are issues arising - because you are not hiding what is going on and you are being responsive by addressing issues immediately as they occur. During the phone call or face-to-face meeting, I ask the client about how things are going from their perspective. If they come up with issues, I document that and send that information to the client to be sure I have captured the information correctly. I also include a plan for addressing the issues that the client has brought up. Being responsive helps to further strengthen and develop the relationship with your client.
As the main client contact (and head of the project) I always take responsibility for what goes wrong. Don't pass the buck or blame your team, a subcontractor, or someone else for the problems. You are the key person - it is your responsibility. And I never go to the client with a problem unless I have some potential options for resolution. I also tell my team that I don't just want a problem brought to my attention - come with some options for fixing the issue.
In speaking with Sarat Varanasi (a fellow blogger), he offered the following information concerning clients who don't want to pay the invoice. From his perspective, and many other consultants I know feel the same way, this is likely a sign of poor project and relationship management. Bottom line - you did something wrong! A good project manager or relationship manager stays in constant communication with his/her client. He/she shows tangible progress to the client, knows the clients concerns and addresses client issues proactively on a regular basis rather than waiting until the client is angry or until the end of the month when the invoice has arrived and the client refuses to pay. A good project or relationship manager is well aware of how the client will react to issues that occur. If a mistake is made, he/she will admit to the mistake and have a plan in place to remedy the issue. By owning up to the mistake, good will and trust is retained with the client. This will help you turn around a tough client and certainly make for a better working relationship. According to Sarat, ignoring the mistake in the hopes that the client will not notice and/or will forget is never a good choice! Once the project is done and the client refuses to pay the invoice, or even a part of the invoice, because he/she is unhappy with the work, your options are limited. You can try pushing back on the client and providing a discount for the work, but likely you have limited your ability to do future work with this client. An unhappy client will remain an unhappy client.
I'm OK with clients who want to change something on the project (let's not assume this is necessarily a difficult client.) But I make sure there is a formal change process in place - and the client knows what that change process is and how it works. This protects everyone and avoids a client turning to a difficult client. Changes are natural - things occur that makes a client rethink what they need. I don't outright tell a client changes are not possible. By letting them know the impact on the project cost and the timeline for the project, they can better make a decision as to whether that change is really necessary. If there is a possibility of making the change with a "second release" of the project, and that may be more cost effective for the client, I let them know about that option. Work with a client who wants changes to the project - putting your foot down and saying "no," or worse yet agreeing to everything doesn't benefit anyone.
I always make sure the client is actively involved in projects. This also helps avoid difficult clients who like to have "plausible deniability" about what is going on. I ask a client to assign a project manager from the client-side to work with the team. This means the client also takes ownership of the project. It also enables me to transition ongoing project maintenance to the client. My goal is to provide the client what they need to make sure this project was a success and not feel like they have to call on me each time they want to do something. Let me provide you an example, if a client wants me to develop a new process for something, I make sure to provide them all the information they need to update or "tweak" that process at a later date and not feel like they need to call on me to do so. Clients feel better about working with you when nothing is a mystery to them. They are involved in the project also and learn from you. Transitioning your knowledge to the client should be part of your responsibility. Believe me - you aren't losing a client. Another project comes up and they are calling on you!
So - I think you must have enough examples by now of the benefits of working closely with the client and being transparent. This helps to tone down your difficult clients. Here are a few brief bullets to help you avoid having to deal with a difficult client.

• Make sure you have a clear project charter and scope statement for all projects that have been developed with and signed off on by the appropriate level contact at the client.
• Have the client sign a project manager from their side to be involved in the project.
• Be sure to develop a written status report on a regular basis and share that information with the client.
• Have regular client meetings - whether by phone or via conference call - to update the client and get answers to questions, resolve issues, etc.
• Don't hide anything from the client - bring up issues immediately along with a proposal for solving the issue.
• Develop and stick to a change management plan. If changes come up - even if minor - stick to the processes for managing change requests. No exceptions here! Make sure everyone on the team knows the process and follows it.
• Develop a detailed contract or agreement for the project that specifically includes what the consultant (that's you!) and the client expect from each other and how you are going to work together.

These steps will help you to keep a project moving in the right direction and avoid a client turning into a difficult one.
And once you have a difficult client, take these steps:

• Set up a face-to-face meeting with the client to address their issues and concerns.
• Develop a plan, with the client, on how to get back on track.
• When necessary, refer back to the documentation (such as status reports, write-ups of meetings and/or conference calls, etc) and your contact with the client (see bullets above on how to avoid having a client become a difficult one.)
• Most important - keep your cool with the client. Come to a consensus on what will work for both you and the client. Don't look to just "win." There is no real winning here if you can't remedy the situation and come to agreement.

management consultant management project