Project Management

Mengapa proyek Anda GAGAL?

2009-09-02T18:50:00.000-07:00

Gagalnya proyek yang anda pimpin, seringkali disebabkan oleh beberapa faktor yang harus disadari dan perlu dihindari, agar proyek anda dapat memenuhi target. Faktor-faktor itu adalah :

Dukungan Sponsor
Seringkali terjadi dukungan Project Sponsor terhadap proyek Anda tidak begitu bagus. Sehingga pada saat Anda dan Tim proyek anda membutuhkan bantuan untuk menyelesaikan masalah-masalah yang terjadi, sering terabaikan. Untuk itu perlu dilakukan langkah-langkah untuk mengkomunikasikan apa yang anda butuhkan kepada Project Sponsor agar mendapat perhatian dan dukungannya.

Keterlibatan Customer/User
Kurangnya keterlibatan customer/user dalam proyek anda, dapat mengakibatkan proyek yang anda pimpin Gagal memenuhi target. Untuk itu perlu dilakukan strategi agar Customer/User dapat dilibatkan dalam berbagai kegiatan dalam proyek anda, agar dapat dipastikan proyek anda dapat memenuhi kebutuhan dan atau ekspektasi mereka.

Kekurangan Sumber Daya (resource)
Apabila anda (PM) merasa resource yang dimiliki masih belum memenuhi kebutuhan dalam proyek anda, coba lakukan Leveling Resource, dan apabila tidak berhasil, sesegera mungkin informasikan ke Project Sponsor untuk dapat ditinjau kembali.

Target Waktu yang kurang realistik
Apabila target waktu yang dibebankan ke Anda (PM) tidak begitu realistik, komunikasikan kembali dengan Project Sponsor untuk dapat dinegosiasikan kembali agar target proyek menjadi lebih realistik.

Kegagalan berkomunikasi
Seringkali Anda (PM) gagal atau kurang bisa dalam berkomunikasi karena Communication Skill yang masih kurang handal. Sehingga setiap orang masih beranggapan bahwa proyek berjalan dengan baik sampai disadari proyek tidak dapat memenuhi target. Untuk menghindari kasus di atas, perlu adanya komunikasi status proyek maupun proyeksinya sedini mungkin, agar tim proyek anda masih punya waktu untuk memperbaikinya sesuai target.

Motivasi kerja rendah (Low morale)
Proyek anda seringkali mengalami keterlambatan karena diakibatkan motivasi kerja tim yang rendah. Untuk menghindari masalah ini, anda harus dapat memotivasi mereka dengan cara memberi contoh cara bekerja dalam proyek, mengusulkan pemberian Reward dan Recognition kepada yang berprestasi, sehingga diharapkan tim anda dapat memenuhi target yang dibebankan untuk dicapai.

Ketidakjelasan Ruang Lingkup Pekerjaan (Scope)
Scope yang tidak jelas dan tidak lengkap dapat menyebabkan terjadinya banyak perubahan-perubahan yang dapat menyebabkan target proyek anda terutama target waktu dan budget tidak tercapai. Untuk itu perlu dibuatkan strategi bagaimana Scope proyek anda dapat diidentifikasi secara lengkap dan jelas dalam tahapan awal proyek anda. Untuk perubahan-2 yang mungkin muncul dalam proyek, perlu dibuatkan Sistem dan Prosedur yang tersentralisasi (Change Control System) agar semua dampak dari perubahan yang disetujui dapat disesuaikan (update) kembali, sebagai target baru.

10 Tips untuk meningkatkan Performansi Tim

2009-04-10T00:38:00.000-07:00

Banyak cara meningkatkan performa/kinerja tim proyek anda. Anda dapat mencoba 10 tips di bawah ini, dengan harapan dapat membantu anda me manage dan meng organize tim secara lebih baik. Adapun tips-2 tersebut adalah :

Tip 1. Jelaskan VISI proyek anda
Tim proyek dapat mengerjakan dengan baik seluruh pekerjaan yang diberikan, apabila mereka mengerti dan memahami latar belakang MENGAPA proyek dilakasanakan, APA yang akan dibuat dan BAGAIMANA mengerjakannya. Untuk itu sebagai PM anda harus bisa menjelaskan dengan lengkap VISI, SASARAN, TARGET proyek, dan RUANG LINGKUP pekerjaan dari proyek anda kepada tim proyek anda, sehingga anda akan memperoleh dukungan dan komitmen dari tim secara lebih baik.

Tip 2. Pelihara hubungan baik dengan setiap anggota tim
Setelah meeting selesai, coba jelaskan secara personal dengan masing-masing anggota timmengenai peranan penting mereka agar proyek dapat diselesaikan sesuai target yang diberikan. Cek kembali apakah Job Description yang diberikan benar-2 jelas dan lengkap, dan bagaimana cara anda mengukur performa tim dari seluruh pekerjaan yang ditugaskan kepada mereka. Cobalah mendapatkan INPUT dari mereka mengenai pengaturan pekerjaan, motivasi dan cara supporting yang mereka butuhkan dari anda.

Tip 3. Aturlah waktu kerja tim secara proporsional
Pekerjaan proyek sering mengalami kondisi Under Pressure, dan sebagai PM anda harus bisa mengatur waktu kerja dari tim anda. Pekerjaan mana yang harus menggunakan waktu lembur dan mana yang tidak. Ini akan membantu dalam rangka mencegah penurunan performa tim.

Tip 4. Kontrol hasil kerja tim
Hasil kerja tim harus dapat dikontrol secara periodik (harian, mingguan atau bulanan) untuk dievaluasi pencapaian target kerja dari tim, mana yang melebihi target dan mana yang harus diperbaiki. Coba utarakan kepada tim secara terbuka dan konstruktif.

Tip 5. Berpikirlah positif
Dalam menghadapi permasalahan-2 dalam proyek, tetap selalu berpikir positif, jangan hanya menyalahkan tim anda, karena akan merusak hubungan baik anda dengan tim. Cobalah dievaluasi kembali dan berikan dukungan kepada tim untuk perbaikan-2 yang diperlukan.

Tip 6. Berikan penghargaan atas prestasi kerja tim
Penghargaan hasil kerja tim sering kali terlupakan, sehingga membuat motivasi kerja tim bisa menurun. Jadi apabila tim anda dapat memenuhi atau bahkan melebihi target yang ditetapkan dalam proyek, berikan apresiasi atau penghargaan untuk mereka, walaupun mungkin hanya sekedar jabat tangan atau mentraktir mereka.

Tip 7. Kembangkan terus kekompakan tim
Kekompakan tim (teamwork) sangat penting untuk selalu dievaluasi selama proyek berlangsung, sehingga penting sekali bagi anda untuk membuat program-2 kecil bagaimana tim anda selalu kompak dalam melaksanakan seluruh pekerjaan proyek sesuai dengan target.

Tip 8. Berikan waktu istirahat
Jangan ragu memberikan waktu istirahat bagi anggota tim apabila diperlukan. Hal ini akan mengurangi cuti sakit, meningkatkan performa dan efisiensi tim anda.

Tip 9. Berikan apa yang mereka butuhkan
Motivasi setiap anggota tim tentunya berbeda-beda. Sebagai PM anda harus bisa mengetahui dan memahami motivasi dari setiap anggota tim anda. Berikan penghargaan atas prestasi berdasarkan apa yang memotivasi mereka sehingga diharapkan performa mereka akan semakin meningkat.

Tip 10. Rayakan kesuksesan proyek anda
Seringkali terjadi perayaan kesuksesan proyek tidak dilakukan mengingat pekerjaan proyek berikutnya sudah menunggu. Ini akan menyebabkan perasaan stress dari proyek sebelumnya akan terbawa ke proyek selanjutnya. Cobalah untuk membuat kegiatan perayaan setelah proyek selesai agar sega perasaan kurang enak, stress dan lain-lain dapat dikeluarkan dan diselesaikan melalui acara ini, sehingga untuk pekerjaan proyek yang baru, tim dapat lebih fresh dan mempunyai semangat yang tinggi untuk bekerja kembali.

Dengan melaksanakan tip-tip di atas, diharpakan performa tim anda dapat lebih baik lagi, sehingga proyek anda dapat diselesaikan sesuai target. Selamat mencoba dan SUKSES selalu.

Giving the Good Presentation

2009-03-04T05:10:00.000-08:00

Dalam memberikan presentasi, terutama untuk melaporkan perkembangan Proyek yg anda pimpin, ada beberapa hal yg harus dilakukan, agar presentasi anda berhasil dengan baik, yaitu :

Buatlah Ringkasan dari beberapa topik yg akan disampaikan pada Slide awal, agar audiens mengerti tentang apa yg akan disampaikan;

Buatlah strategi agar audiens ikut terlibat pada sesi awal, pertengahan maupun akhir presentasi. Caranya buatlah pertanyaan mendasar yg menarik untuk dijawab oleh audiens pada awal dan atau pertengahan sesi. Pada akhir sesi, buatkan pertanyaan mengenai pemahaman audiens tentang seluruh topik penting yg sudah dipresentasikan;

Jangan hanya membaca slide! Jika anda hanya membaca slide audiens akan bosan karena mereka dapat membacanya sendiri! Coba sampaikan dengan menarik dan berikan contoh2 konkrit untuk penjelasannya;

Berikan kesempatan kepada audiens untuk membahas topik yg anda sudah sampaikan dalam sesi istirahat (break), agar dapat lebih jelas untuk dipahami;

Gunakan tangan, wajah dan intonasi vokal anda agar presentasi Anda menjadi menarik. Audiens akan bosan dan tidak tertarik malah mungkin akan tertidur..., apabila penjelasan yg diberikan hanya datar-datar saja;

Anda harus percaya diri dan jangan merasa gugup. Jika Anda melakukan presentasi dengan keyakinan yg tinggi, audiens Anda akan melihat dan percaya bahwa apa yang Anda sampaikan benar benar terlaksana dengan baik (penyampaian harus jujur dan sesuai kondisi).

Pada sesi penutup, buatlah kesimpulan dari presentasi ini secara singkat dan jelas, dan buatkan komitmen untuk seluruh audiens bahwa proyek anda memerlukan dukungan mereka untuk dapat berhasil dengan baik dan sesuai target.

Selamat mencoba..!

PMBOK Edisi 4 Th 2008

2009-02-18T22:46:00.000-08:00

PMBOK versi 4 Th 2008 akan di "launch" 31 Desember 2008. Menurut beberapa artikel terutama dari PMI menyatakan bahwa perubahan dari versi yang lama tidak begitu drastis alias tidak semua konten mengalami perubahan dalam PMBOK yang terbaru. Beberapa perubahan tersebut adalah :

Process changes

• Ada 2 (dua) proses baru dalam requirements collection dan stakeholder identification
• Yang dihapus adalah develop Preliminary Scope Statement and Plan Scope
• Procurements juga telah dikurangi dari enam proses sampai empat proses, yaitu:
* Plan Procurements
Plan Purchases and Acquisitions
Plan Contracting
* Conduct Procurements
Request Seller Responses
Select Sellers
* Administer Procurements
* Close Procurements

Content Clarification

Salah satu tujuan dari revisi ini adalah untuk membuat format dan terminologi beserta penjelasannya lebih tersruktur, konsisten dan terstandar dengan baik, terutama untuk:
• penjelasan
o Project Scope Statement vs. Project Charter
o Project Management Plan content vs. processes to manage the project
o Change Requests
• Konsistensi
o konsisten dalam istilah untuk masukan/input dan keluaran/output

The Chapters

• Chapter 1: Introduction
o Diskusi pemahaman traditional triple constraint (time / cost / quality) menjadi proses menyeimbangkan pemenuhan project constraints seperti scope, schedule, quality, budget, resources and risk
o Juga diskusi mengenai istilah projects vs programs, portfolios, strategic planning and operations
• Chapter 2: Project Lifecycles and Organization
o Penyesuaian dengan standar lain yg berlaku
o Diskusi mengenai stakeholder roles dalam proyek
o Update dan tambahan Gambar/grafik
• Chapter 3: Project Management Processes for a Project
o Gambaran terbaru mengenai project management process interactions, with emphasis dalam integrating processes
o Modifikasi deskripsi Process group terutama untuk Initiating / Executing / Closing
• Chapter 4: Project Integration Management
o Konsep developing a Preliminary Scope Statement dihilangkan
o Ada penambahan pemahaman untuk konsep Develop Project Management Plan dan Close Project or Phase
• Chapter 5: Project Scope Management
o Plan Scope process diganti dengan Collect Requirements
o Outputs dari proses ini terdiri dari:
 Requirements management plan
 Requirements documentation
 Requirements traceability matrix
• Chapter 6: Project Time Management
o Revisi fous utama dalam reorganizing and streamlining the chapter agar dapat lebih dipahami
o Diskusi AOA dihilangkan
• Chapter 7: Project Cost Management
o To-Complete Performance Index (TCPI) ditambahkan sebagai tool dalam control cost
o Greater alignment between 5.5 (Control Scope), 6.6 (Control Schedule) and 7.3 (Control Costs)
• Chapter 8: Project Quality Management
o Deskripsi proses-proses lebih akurat
o Diskusi mengenai cost of quality ditambah penjelasannya
o Quality Baseline hdihilangkan
• Chapter 9: Project Human Resource Management
o Manage Project Team dipindahkan dariMonitoring & Controlling ke Executing
o Dalam appendix, topics and references ditambah
• Chapter 10: Project Communication Management
o Proses Identify Stakeholders ditambahkan dalam Initiating Group
 Outputs terdiri dari: Stakeholder Register; and Stakeholder Management Strategy
o Manage Stakeholder dirubah menjadi Manage Stakeholder Expectation
• Chapter 11: Project Risk Management
o Chapter ini ada penambahan beberapa pemahaman penting sesuai dengan best practices, antara lain:
“For every complex problem, there is an answer which is clear, simple and wrong”
“Don’t expect BIG change; expect clarifying minor change; and expect some folks to find the clarifications less than clarifying”
• Chapter 12: Project Procurement Management
o Berubah dari 6 proses menjadi 4 proses
o Konsep teaming agreements ditambahkan
o Cost Plus Percentage of Costs sebagai contract type dihilangkan; it’s illegal in most locations
• Appendix:
o appendix dari interpersonal skills ada penambahan, yaitu:
 Leadership
 Team Building
 Motivation
 Communication
 Influencing

Demikian sekilas gambaran dari PMBOK 4th 2008. Semoga bahasan ini semakin memperkaya pemahaman anda dalam konsep Project Management dengan lebih baik lagi.

What is the Project ???

2009-01-02T09:52:00.000-08:00

Before you can be a good 'project manager' and apply good 'project management' techniques, you must first be sure that the work you are undertaking is, in fact, a project. Some people say that all work is a project, but that is not totally accurate. There are really multiple kinds of work – support, operations, management, projects etc.

Support, work includes maintaining current solutions that are already in place. For IT development people, support work consists of answering questions, going to regularly scheduled meetings, fixing problems in the production systems, etc. For sales people, this could be making daily sales calls, moving contracts through an approval process, updating call logs, etc. Operations work consists of the routine work required to run the business processes. For an accounts receivable clerk this could be checking reports, balancing accounts, posting journal entries, closing out the system, etc. Management work is required to manage and lead people and business processes.

The key aspect is this type of work is that it is an ongoing and routine part of your job. This is the work you do today, tomorrow and a month from now.

According to PMBOK 2004 from PMI,

A project is a temporary endeavor undertaken to create a unique product, service or result

Project management is “the application of knowledge, skills, tools, and techniques to project activities in order to meet project requirements”

On the other hand, projects are not routine. The biggest difference in these categories of work is that projects, by their definition, have a defined start and end-date. There is a point in time when the work did not exist (before the project), when it does exist (the project), and when it does not exist again (after the project). This is the key determinant of whether a piece of work is a project. However, other characteristics of a project include a defined scope, finite budget, specific end results (or deliverables) and assigned resources. Another characteristic of a project is that the work is unique. Even if a project is similar to another one, it is not exactly the same because circumstances change and because things are always different when you are dealing with people.

That being said, now you must get practical. In theory, projects can be one hour, 100 hours or 100,000 hours. So, you must recognize that, although the creation of a small deliverable is a project, it does not need the structure and discipline of a much larger project. For a one-hour project, you 'just do it'. Any planning, analysis and design is all done in your head. For a twenty hour project, you mostly 'just do it'. However, now you may need to plan a little bit, maybe communicate a little bit, maybe deal with problems a little bit. A one hundred hour project probably has too much work to plan and manage all in your head. For instance, you need to start defining the work and building a simple workplan. A 5,000 hour project needs full project management discipline. On the other extreme, a 100,000 hour project probably has too much work to get your head around it all. This requires you to break the larger project up into smaller, but related, projects to get the entire piece of work done.

20 Key Project Manager Actions and Deliverables *

2009-01-02T09:39:00.000-08:00

Action

Deliverables

Initiating

1. Demonstrate project need and feasibility.

A document confirming that there is a need for the project deliverables and describing, in broad terms: the deliverables, means of creating the deliverables, costs of creating and implementing the deliverables, benefits to be obtained by implementing the deliverables.

2. Obtain project authorization.

A "go/no go" decision is made by the sponsor.

A project manager is assigned.

A "project charter" is created which:

	Formally recognizes the project
	Is issued by a manager external to the project and at a high enough organizational level so that he or she can meet project needs
	Authorizes the project manager to apply resources to project activities

3. Obtain authorization for the phase.

A "go/no go" decision is made by the sponsor which authorizes the project manager to apply organizational resources to the activities of a particular phase

Written approval of the phase is created which

	Formally recognizes the existence of the phase
	Is issued by a manager external to the project and at a high enough organizational level so that he or she can meet project needs

Planning

4. Describe project scope.

	Statement of project scope
	Scope management plan
	Work breakdown structure

5. Define and sequence project activities.

	An activity list (list of all activities that will be performed on the project)
	Updates to the work breakdown structure (WBS)
	A project network diagram

6. Estimate durations for activities and resources required.

	Estimate of durations (time required) for each activity and assumptions related to each estimate
	Statement of resource requirements
	Updates to activity list

7. Develop a project schedule.

	Project schedule in the form of Gantt charts, network diagrams, milestone charts, or text tables
	Supporting details, such as resource usage over time, cash flow projections, order/delivery schedules, etc.

8. Estimate costs.

	Cost estimates for completing each activity
	Supporting detail, including assumptions and constraints
	Cost management plan describing how cost variances will be handled

9. Build a budget and spending plan.

	A cost baseline or time-phased budget for measuring/monitoring costs
	A spending plan, telling how much will be spent on what resources at what time

10. Create a formal quality plan. (optional)

	Quality management plan, including operational definitions
	Quality verification checklists

11. Create a formal project communications plan. (optional)

A communication management plan, including:

	Collection structure
	Distribution structure
	Description of information to be disseminated
	Schedules listing when information will be produced
	A method for updating the communications plan

12. Organize and acquire staff.

	Role and responsibility assignments
	Staffing plan
	Organizational chart with detail as appropriate
	Project staff
	Project team directory

13. Identify risks and plan to respond. (optional)

A document describing potential risks, including their sources, symptoms, and ways to address them

14. Plan for and acquire outside resources. (optional)

	Procurement management plan describing how contractors will be obtained
	Statement of work (SOW) or statement of requirements (SOR) describing the item (product or service) to be procured
	Bid documents, such as RFP (request for proposal), IFB (invitation for bid),etc.
	Evaluation criteria -- means of scoring contractor's proposals
	Contract with one or more suppliers of goods or services

15. Organize the project plan.

A comprehensive project plan that pulls together all the outputs of the preceding project planning activities

16. Close out the project planning phase.

A project plan that has been approved, in writing, by the sponsor A "green light" or okay to begin work on the project

17. Revisit the project plan and replan if needed.

Confidence that the detailed plans to execute a particular phase are still accurate and will effectively achieve results as planned.

Executing

18. Execute project activities.

	Work results (deliverables) are created.
	Change requests (i.e., based on expanded or contracted project) are identified.
	Periodic progress reports are created.
	Team performance is assessed, guided, and improved if needed.
	Bids/proposals for deliverables are solicited, contractors (suppliers) are chosen, and contracts are established.
	Contracts are administered to achieve desired work results.

Controlling

19. Control project activities.

	Decision to accept inspected deliverables
	Corrective actions such as rework of deliverables, adjustments to work process, etc.
	Updates to project plan and scope
	List of lessons learned
	Improved quality
	Completed evaluation checklists (if applicable)

Closing

20. Close out project activities.

	Formal acceptance, documented in writing, that the sponsor has accepted the product of this phase or activity.
	Formal acceptance of contractor work products and updates to the contractor's files.
	Updated project records prepared for archiving.
	A plan for follow-up and/or hand-off of work products

Project Problem : Poor Scope Management*

2009-01-02T06:15:00.000-08:00

Defining scope is perhaps the most important part of the upfront process of defining a project. In fact, if you don't know for sure what you are delivering and what the boundaries of the project are, you have no chance of success. Managing scope is one of the most critical aspects of managing a project. However, if you have not done a good job of defining scope, managing scope will be almost impossible.

The purpose of defining scope is to clearly describe and gain agreement on the logical boundaries of your project. Scope statements are used to define what is within the boundaries of the project and what is outside those boundaries. The more aspects of scope you can identify, the better off your project will be. The following types of information can be helpful:

· The types of deliverables that are in scope and out of scope. (Business Requirements, Current State Assessment)

· The major life-cycle processes that are in scope and out of scope. (analysis, design, testing)

· The types of data that are in scope and out of scope. (financial, sales, employee)

· The data sources (or databases) that are in scope and out of scope. (Billing, General Ledger, Payroll)

· The organizations that are in scope and out of scope. (Human Resources, Manufacturing, vendors)

· The major functionality that is in scope and out of scope. (decision support, data entry, management reporting)

Have a Viable Scope Change Process in Place

The project manager and project team must realize that there is nothing wrong with scope change. That is, changing scope while a project is underway is not an evil proposition. In fact, in many cases it is a good thing. First, the client typically cannot identify every requirement and feature that will be required for the final solution. Second, even if they did, the business changes over time, and therefore the requirements of the project may change as well.

If you cannot accommodate change, the final solution may be less valuable than it should be, or it may, in fact, be unusable. Therefore, you want the client to have the ability to make changes during the project when needed. The problem comes when the project manager does not proactively manage change on the project. Every project should have a process in place to manage change effectively. The process should include identifying the change, determining the business value of the change, determining the impact on the project and then taking the resulting information to the project sponsor for his/her evaluation. The sponsor can determine if the change should be included. If it is included, then the sponsor should also understand the impact on the project and allocate the additional budget and time needed to include the change.

Common Problems with Scope Change Management

There are a number of common problems that project teams encounter with scope change management.

· Scope creep. Many project managers recognize large scope changes, but are not as diligent about smaller changes. There is a tendency to just go ahead and add the additional work without too much thought. Scope creep refers to what happens when a project accepts a large number of small changes. When all of these small changes are combined, the team realizes that they have taken on too much extra work and can no longer meet their budget and deadline commitments.

· No sponsor approval. Many times a project manager will receive requests for changes from end users, stakeholders or client managers. Since these are all people in the client organization, there is a tendency to think that they should be accepted. Again, this is a mistake. The end users usually surface scope change requests, but they cannot approve them. Even a client manager cannot approve scope change requests. The only person that can is the sponsor (unless the sponsor has delegated this authority to others). Many projects get in trouble because the team thinks they are getting approval to proceed with scope changes, but discover later that the person who really counts, the sponsor, has not agreed.

· Project team accountability. Since the project team members can have a lot of interaction with the client, they are the ones that field scope change requests the most often. Therefore, the entire project team must understand the importance of scope change management. All of them must detect scope changes when they occur and funnel them back to the project manager. If they take on the extra work themselves, there is a good likelihood their activities will be completed late and jeopardize the entire project.

It’s Never Too Late to Start

If you find that your project is starting to trend over its budget and schedule, try to find the cause. In many cases, you will find that you are simply taking on more work than you originally agreed to. The best time to define a scope change management process is before the project begins (as a part of the Project Management Procedures). However, if you do not have a good process in place, it is never too late to start. The project manager must call a quick time-out and work with the client on a process for detecting and approving scope change requests. Then, everyone must be educated in the new process. If there is a good side of this effort, it is that the team and the client can see first hand the impact of not controlling scope because the project is already in trouble. They should be better able to understand the purpose of scope change management and be more willing to follow the more rigorous process in the future.
* TenStep Project Management

Project Problem : Inadequate Project Definition and Planning *

2009-01-02T06:08:00.000-08:00

Have you ever attended an end-of-project meeting on a project that had major problems? If you have, chances are that one of the major themes you will hear is that “we should have spent more time planning.” Many project managers think that they need to jump right into the project by gathering business requirements. They think that if they do a good job gathering the business requirements, they are ready to run on the project. That is not true. In fact there is a definition and planning process that needs to happen before you ever start gathering the business requirements.

Before the project work begins, the project manager must make sure that the work is properly understood and agreed to by the project sponsor and key stakeholders. The project manager works with the sponsor and stakeholders to ensure that there is a common perception of what the project will deliver, when it will be completed, what it will cost, who will do the work, how the work will be done, and what the benefits will be. The larger the project, the more important it is that this information be mapped out formally and explicitly. All projects should start with this type of upfront planning to prevent future problems caused by differing viewpoints on the basic terms of the project.

Common Planning Problems

Poor up-front definition and planning cause problems in many areas later in the project. These problems include:

· Lack of business support. If you do not define the major characteristics of a project up-front, it is very common to have differences in expectations among the major stakeholders. This is true even if you take all of your initial direction from the sponsor. As a project gets larger, even the sponsor may not have a totally complete picture of what needs to happen for the project to be successful. Other times, the sponsor has a vision, but there are other visions that may be better or more viable. These competing ideas end up surfacing later in the project and causing confusion and rework.

· Poor estimates. Usually a project needs to have a budget and deadline before the business requirements are completed. In many cases, if the definition and planning is not done ahead of time, the project team starts off with inadequate resources and time, and you don’t realize it until the project is already in progress. Many projects that could be successful are viewed as failures because they overshot their budget and deadline. This situation is often caused by the project manager committing to numbers that are too low, the result of a lack of up-front planning.

· Poor scope control. One of the major aspects of defining a project is defining the high-level scope. If you do not define and gain agreement on scope, you will find it very difficult to manage scope effectively throughout the project.

How to Avoid the Mistake

Spending time on a good definition and planning ends up taking much less time and effort than having to correct problems while the project is underway. It should not be surprising, then, that the best way to avoid this problem is to do a good job of defining and planning the project up-front. This includes:

· Defining. Before the actual work of the project begins, make sure you have spent the time to define the project objectives, scope, assumptions, risks, budget, timeline, organization and overall approach. The project manager may think that they know all of this already. However, the purpose of this work is to ensure that there is a consensus between the project manager, project sponsor and all other stakeholders. Even if the project manager and the sponsor are in agreement, there may be other major stakeholders that have other ideas. Differences of opinion need between the major stakeholders needs to be resolved before the project starts – not while you are in the middle.

· Planning. The project manager should create an overall project workplan before the project starts. This will help you estimate the total project effort and duration. The project manager also needs to ensure that he or she has the detailed work mapped out over the next few months to ensure that the project resources are assigned the right work once the project actually begins.

In addition, it is very helpful to have an agreed upon set of project management procedures that are used to manage the project. These will include how the project manager will manage scope, issues, risks, communication, the workplan, etc. Again, the key is to define these all up-front to better manage expectations. For instance, if you define and get agreement on the procedure for approving scope change requests, you should have a much easier time managing change once the project begins.

What if You Are Already Into the Project?

Of course, the best way to solve a problem is to prevent it to begin with. However, what if you do not have that option? Let’s say you are into a project, and you start to see some of the problem areas described above. For instance, you start to see stakeholders coming forward with different ideas for what the project should accomplish, but you are already well down the path to the prior vision.

If you are having trouble with one or two aspects of the definition process, you may be able to resolve it with a mini-definition process. For instance, if you find that you cannot control scope because you did not define it to begin with, you can take the time to formally define and gain agreement on the scope. This involves going back to the sponsor and major stakeholders to gain the consensus and approval that you did not get earlier.

If you start to see differing visions as to what the project should achieve, you may need to actually complete the entire definition process while the project is in progress. This is very difficult and painful, but it can be done. You need to take a step back and define objectives, scope, roles, risks, etc. You might need to actually stop work on the project until this definition process is completed, although in many cases this is not practical.

As painful as it is to define the project while it is in progress, it is still preferable to ignoring the problem. The first option may end up causing rework, resulting in additional cost and a later delivery date. However, ignoring the problem may end up making the entire solution irrelevant or obsolete as soon as it is delivered.

* From TenStep Project Management