Dalam dunia yang penuh kesibukan, musuh seorang manajer adalah pemborosan waktunya sendiri. Sering seorang manajer kehilangan kendali pada waktunya. Waktu dan hari terasa berlalu demikian cepat. Banyak pekerjaan yang tidak kunjung selesai. Inilah beberapa poin penting bagi seorang manajer untuk mengefektifkan penggunaan waktunya:
* Buat daftar pekerjaan hari ini, Hasilnya apa, bukan kegiatannya. Misalnya \"Menyelesaikan draf kontrak dengan PT.A.\" bukan \"Membuat draft kontrak \" yang belum tahu selesainya dan hasilnya kapan. Kalau bisa daftar pekerjaan besok disusun hari ni sebelum pulang.
* Sentuh suatu pekerjaan sekali saja seminimal mungkin. Menulis sesuatu usahakan selesai. Terima email baca sekali langsung disimpan, direspon, dimasukkan daftar penting, atau dihapus. Yang tidak perlu dihapus.
* Sisihkan waktu cukup beberapa jam untuk pekerjaan-pekerjaan serius. Ada pekerjaan yang lebih baik demikian daripada sambil kerja lain dan tidak kunjung selesai.
* Rapat - Susun agenda, pilih yang datang selektif supaya diskusi tidak kemana-mana, pilih tempat dan waktu yang baik, misalnya rapat jam 11 sebelum makan ataui sebelum jam pulang biasanya lebih cepat selesai daripada yang dijadwalkan jam 8 pagi. Hasilnya juga sering sama.
* Bagi yang beruntung punya, asisten atau sekretaris bisa diminta membantu penyusunan jadwal harian sekaligus mengingatkan. Diingatkan sering lebih baik daripada dibiarkan dengan kegiatan sendiri.
Rabu, 26 Januari 2011
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
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
Selasa, 25 Januari 2011
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.
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.
Whether in education, business or are running a household, clearly defined goals and objectives will support the projects successful result.
Project Management manajemen konstruksi
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:
- Website development goal: Visitors will be convinced that global warming exists.
- Insurance company: The Medical Insurance department will increase provider options by 10%.
- 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.
- Identify provider options and costs.
- Survey the customer to find out each options value.
- Compare options to competitors.
- Evaluate personnel requirements.
- Purchase new appointment scheduling software.
- Setup appointment confirmation schedule.
Whether in education, business or are running a household, clearly defined goals and objectives will support the projects successful result.
Project Management manajemen konstruksi
IT Project Governance and PRINCE2 Project Management
In today's fast-changing information economy, IT project governance has emerged as one of the most vital corporate responsibilities. The relentless pressure to innovate whilst simultaneously driving down costs means that organisations are increasingly "betting the farm" on the successful development and deployment of new IT systems. However, the business environment now evolves so quickly that the original assumptions on which projects were based can often become fatally undermined prior to the projects completion. With technology at the heart of most businesses, the ability to maintain tight executive and board control over such projects throughout their lifecycle has become a deciding factor in determining which businesses thrive and which founder. In response to this challenge, PRINCE2 project management has emerged as the world's leading methodology for ensuring that IT projects stay on track and deliver real value.
No large scale or business critical project should ever be managed on a standalone basis. The need to involve and secure buy-in from functions right across the organisation means that a project governance approach is essential. While project management is the key discipline within this, project governance is broader in scope and has six interlinked objectives:
The board's project governance responsibilities can be summarised as follows:
PRINCE2 project management uses a structured methodology, which means managing a project in a logical and organised way, following clearly defined steps and well-understood roles and responsibilities. It perfectly matches the requirements of a project governance regime by delivering the following attributes to any project:
Planned: PRINCE2 has a series of processes that cover all of the activities needed on a project from starting up to closing down. This process-based approach provides an easily tailored and scalable method for the management of all types of project. Each process is defined with its key inputs and outputs together with the specific objectives to be achieved and activities to be carried out.
Controlled: PRINCE2 project management divides a project into manageable stages, enabling efficient control of resources and regular progress monitoring throughout. The various roles and responsibilities for managing a project are fully described and are adaptable to suit the size and complexity of the project and the skills of the organisation.
Results-driven: Project planning using PRINCE2 is product-based, which means the project plans are actually focused on delivering results and are not simply about planning when the various activities on the project will be done.
Measured: Any project using PRINCE2 is driven by the business case, which describes the organisation's justification, commitment and rationale for the deliverables or outcome. The business case is regularly reviewed during the project to ensure the business objectives, which often change during the lifecycle of the project, are still being met.
There are clear reasons why PRINCE2 project management has become the world's leading methodology. In addition to its best practice approach for the management of all project types, around 800 people per week take PRINCE2 project management examinations, with all training carried out by accredited organisations. It is widely used and popular in both public and private sectors and can easily be tailored to all varieties of projects in many different markets and businesses. For any organisation that is serious about managing its IT investment, PRINCE2 project management is the natural choice.
management consulting management consultant
No large scale or business critical project should ever be managed on a standalone basis. The need to involve and secure buy-in from functions right across the organisation means that a project governance approach is essential. While project management is the key discipline within this, project governance is broader in scope and has six interlinked objectives:
- Ensuring real business value through project and business alignment.
- Controlling costs through centralisation.
- Maximising resource allocation, particularly of high value resources.
- Risk management through portfolio balancing.
- Uniform application of best practice.
- Organisational coherence.
The board's project governance responsibilities can be summarised as follows:
- To approve product initiation, manage the project portfolio and pull the plug on any underperforming projects.
- To make one or more non-executive board members specifically responsible for overseeing project governance. They must have independent and informed oversight of progress on all business IT projects - including attending program (or large project) board meetings.
- To ensure clear accountability at all levels, with detailed, rigorously tested project plans based on a critical path analysis with clearly identified critical success factors, regular milestones and "go/no go" checkpoints.
- To ensure that every project proposal contains a full business case with a fully costed estimate that can stand up to independent audit, with clearly stated assumptions that can withstand rigorous analysis.
- To manage all IT related projects as part of a portfolio.
- To adopt and deploy a recognised project management methodology.
- To adopt a clearly defined risk management plan at programme and project level that reflects corporate level risk treatment requirements.
- To institute a monitoring framework to inform the board of progress and provide an early alert of divergence or slippage in any of the critical success factors.
- To commit funding only on a phased basis.
- To ensure that internal audit is capable and accountable directly to the board for providing regular, timely and unambiguous reports on project progress, slippage, budget, requirements specification and quality requirements. Where there is project divergence the board should not release further funds until the cause of the divergence has been fully dealt with.
PRINCE2 project management uses a structured methodology, which means managing a project in a logical and organised way, following clearly defined steps and well-understood roles and responsibilities. It perfectly matches the requirements of a project governance regime by delivering the following attributes to any project:
- A controlled and organised start, middle and end
- Regular reviews of progress against plan and against the business case
- Flexible decision points
- Automatic management control of any deviations from the plan
- The involvement of management and stakeholders at the right time and in the right place during the project
- Good communications channels between the project, project management and the rest of the organisation.
Planned: PRINCE2 has a series of processes that cover all of the activities needed on a project from starting up to closing down. This process-based approach provides an easily tailored and scalable method for the management of all types of project. Each process is defined with its key inputs and outputs together with the specific objectives to be achieved and activities to be carried out.
Controlled: PRINCE2 project management divides a project into manageable stages, enabling efficient control of resources and regular progress monitoring throughout. The various roles and responsibilities for managing a project are fully described and are adaptable to suit the size and complexity of the project and the skills of the organisation.
Results-driven: Project planning using PRINCE2 is product-based, which means the project plans are actually focused on delivering results and are not simply about planning when the various activities on the project will be done.
Measured: Any project using PRINCE2 is driven by the business case, which describes the organisation's justification, commitment and rationale for the deliverables or outcome. The business case is regularly reviewed during the project to ensure the business objectives, which often change during the lifecycle of the project, are still being met.
There are clear reasons why PRINCE2 project management has become the world's leading methodology. In addition to its best practice approach for the management of all project types, around 800 people per week take PRINCE2 project management examinations, with all training carried out by accredited organisations. It is widely used and popular in both public and private sectors and can easily be tailored to all varieties of projects in many different markets and businesses. For any organisation that is serious about managing its IT investment, PRINCE2 project management is the natural choice.
management consulting management consultant
Most Important Rules of Money Management
The lack of money is often not our problem, it is the way we spend it. Wealthy people tend to spend money on things that increase in value or provide them with a return on their investment.
People who are not wealthy spend the bulk of their money on items that perish, depreciate or have no return on their investment. Even the family home, which is often the most expensive item that most people purchase, usually provides no return on their large capital outlay.
There is one main reason why people get themselves into financial difficulties. They simply spend more than they earn. The two ways of increasing wealth is to either increase our income, or decrease our expenditure.
Unfortunately, through increased exposure to advertising and access to products, we are constantly enticed into having more and more material possessions. The easiest way to resist this temptation is to establish a plan where we always save a little of our income and learn to control our debt. If we do this consistently and regularly, we will eventually form a habit - a good, lasting habit that will overcome our financial difficulties and lead us to financial freedom.
Money is there to provide security, satisfaction and joy in our lives, and we can have some of life's little luxuries along the way. However, while we are learning to manage our finances, we need to control our spending and allocate our money according to our needs.
Initially, this means we may have to eliminate wastage and extravagance, and identify the things we really need to lead happy, fulfilling lives. We need to remain conscious around our spending. We need to remind ourselves that every cent we spend - does count! Initially, this may mean we have to cut back a little, but it is only directed at wastage and extravagance.
I believe that extravagance and over-spending is just the other side of the 'scarcity' coin. It is often the belief that there is not enough that leads us into buying too much. It requires a mature, practical approach, which is within all of us, to become great financial managers. A little planning, a little discipline and often a bit of self-talk are all that is required. It just takes a moment to stop and remind ourselves to think long-term, not short-term.
The trick to economising is actually quite simple. Before you part with your money, always ask, "Do I really need this? Will I end up wasting this? Is this an extravagance I can live without?" If you develop a little voice in your head every time you go shopping that asks you these three simple questions, and you listen to and obey the answers, you will automatically start to economise.
Economising is not about living frugally. It is not about being miserly and not sharing your money. It is not about penny pinching and living without the things you really need. Economising is simply about not wasting your money, not being extravagant and not buying things you cannot afford. Here are a few ideas to help resist the urge to spurge:
1. Keep focusing on your long-term financial goals.
2. Prepare a monthly actual-to-budget variance analysis of where you spent your money. This may seem tedious but it always works wonders. Initially we may have good intentions but as time progresses, temptation can take over. If we see how we fared with our spending each month, it pulls us back a little. If we don't see it, we tend to forget and the overspending can easily get away from us.
3. Carry a small card in your wallet detailing your budget for luxury items. When that is spent - stop, and wait until next month.
4. Only buy what you need. Remember, wastage and extravagances are just the other side of the scarcity coin.
5. Learn to nurture yourself in less expensive ways. A $30 massage may be better than that $200 new dress.
6. Set up a separate savings account to reward yourself with the occasional luxury fantasy, maybe a weekend at some fabulous retreat. By putting away small amounts of your budget, you can save up for those sensational rewards rather than fritter it away on useless $5 or $10 items each week.
There is always the tendency to spend when we should be saving. The surplus money comes in and our automatic response is to go out and spurge. This is the very behaviour we need to address before we can become financial stable. consultant management Construction Management
People who are not wealthy spend the bulk of their money on items that perish, depreciate or have no return on their investment. Even the family home, which is often the most expensive item that most people purchase, usually provides no return on their large capital outlay.
There is one main reason why people get themselves into financial difficulties. They simply spend more than they earn. The two ways of increasing wealth is to either increase our income, or decrease our expenditure.
Unfortunately, through increased exposure to advertising and access to products, we are constantly enticed into having more and more material possessions. The easiest way to resist this temptation is to establish a plan where we always save a little of our income and learn to control our debt. If we do this consistently and regularly, we will eventually form a habit - a good, lasting habit that will overcome our financial difficulties and lead us to financial freedom.
Money is there to provide security, satisfaction and joy in our lives, and we can have some of life's little luxuries along the way. However, while we are learning to manage our finances, we need to control our spending and allocate our money according to our needs.
Initially, this means we may have to eliminate wastage and extravagance, and identify the things we really need to lead happy, fulfilling lives. We need to remain conscious around our spending. We need to remind ourselves that every cent we spend - does count! Initially, this may mean we have to cut back a little, but it is only directed at wastage and extravagance.
I believe that extravagance and over-spending is just the other side of the 'scarcity' coin. It is often the belief that there is not enough that leads us into buying too much. It requires a mature, practical approach, which is within all of us, to become great financial managers. A little planning, a little discipline and often a bit of self-talk are all that is required. It just takes a moment to stop and remind ourselves to think long-term, not short-term.
The trick to economising is actually quite simple. Before you part with your money, always ask, "Do I really need this? Will I end up wasting this? Is this an extravagance I can live without?" If you develop a little voice in your head every time you go shopping that asks you these three simple questions, and you listen to and obey the answers, you will automatically start to economise.
Economising is not about living frugally. It is not about being miserly and not sharing your money. It is not about penny pinching and living without the things you really need. Economising is simply about not wasting your money, not being extravagant and not buying things you cannot afford. Here are a few ideas to help resist the urge to spurge:
1. Keep focusing on your long-term financial goals.
2. Prepare a monthly actual-to-budget variance analysis of where you spent your money. This may seem tedious but it always works wonders. Initially we may have good intentions but as time progresses, temptation can take over. If we see how we fared with our spending each month, it pulls us back a little. If we don't see it, we tend to forget and the overspending can easily get away from us.
3. Carry a small card in your wallet detailing your budget for luxury items. When that is spent - stop, and wait until next month.
4. Only buy what you need. Remember, wastage and extravagances are just the other side of the scarcity coin.
5. Learn to nurture yourself in less expensive ways. A $30 massage may be better than that $200 new dress.
6. Set up a separate savings account to reward yourself with the occasional luxury fantasy, maybe a weekend at some fabulous retreat. By putting away small amounts of your budget, you can save up for those sensational rewards rather than fritter it away on useless $5 or $10 items each week.
There is always the tendency to spend when we should be saving. The surplus money comes in and our automatic response is to go out and spurge. This is the very behaviour we need to address before we can become financial stable. consultant management Construction Management
Getting Work Done: The Human Side of Project Management
Project management is defined as the art and science of getting work done with the active co-operation of individuals and organisations who are directly or indirectly involved with the project. This includes Senior Management, Project Sponsors(s), Customers, End-users, Stakeholders, Team Members, Sub-contractors, Vendors and Consultants.
Given the reality of minimal authority and total responsibility for the outcome of the project, the Project Manager's biggest challenge consists of "Getting Work Done."
Professional project management today is subject to increased industry pressures from accelerated implementations, restructuring and downsizing, mergers and acquisitions, faster technology obsolescence, and the use of new and unproven technologies. Furthermore, the project environment itself is rapidly changing with the use of distributed and virtual teams as organisations implement new "Projectized" cultures.
The challenge for the Project Manager consists of attracting the right resources, forming a cohesive team, keeping the team motivated, meeting individual aspirations and getting the work done - all within scope, cost, time, and customer satisfaction! How should we meet the challenge of dealing with the human side of project management? Here is a checklist with the "Ten Golden Rules" to help you assess the maturity level of project management and team effectiveness in your projects. Place a check mark against each question, only if you can answer it with a confident "Yes."
Teams must embrace a common purpose, and develop and follow a set of common processes based on a set of values and culture adopted by the team. The Project Manager's role in team building is to guide, coach, mentor, facilitate and direct as required to achieve the intended project outcome. The success and survival of project teams depends on understanding the human side of project management.
management consultant management project
Given the reality of minimal authority and total responsibility for the outcome of the project, the Project Manager's biggest challenge consists of "Getting Work Done."
Professional project management today is subject to increased industry pressures from accelerated implementations, restructuring and downsizing, mergers and acquisitions, faster technology obsolescence, and the use of new and unproven technologies. Furthermore, the project environment itself is rapidly changing with the use of distributed and virtual teams as organisations implement new "Projectized" cultures.
The challenge for the Project Manager consists of attracting the right resources, forming a cohesive team, keeping the team motivated, meeting individual aspirations and getting the work done - all within scope, cost, time, and customer satisfaction! How should we meet the challenge of dealing with the human side of project management? Here is a checklist with the "Ten Golden Rules" to help you assess the maturity level of project management and team effectiveness in your projects. Place a check mark against each question, only if you can answer it with a confident "Yes."
Golden Rule #1: Develop a Project Organisation
- Are there specific individuals who are identified as the Sponsor and the Customer or Client for the project?
- Does everyone know who has the single source of responsibility for the project?
- Is there a Project Organisation Chart with individuals identified for each role including team members and internal/external stakeholders?
- Are the roles, responsibilities and expectations clearly defined for each individual?
- Have the responsibilities and commitments been formally accepted by the individuals?
Golden Rule #2: Formulate a Team Purpose
- Is there a common understanding of project objectives and deliverables among all players?
- Are the "Vision, Purpose, Goals" of the project documented and supported by a scope definition with SMART objectives (i.e. Specific, Measurable, Achievable, Realistic and Target-driven)?
- Is there an agreed baseline schedule with resource commitments and intermediate milestones and deliverables for the project?
- Are the functional organisations that are impacted by the project on board with the project objectives and project plans?
- Did team members have input into the norms, rules and processes to be followed for smooth functioning of the team?
Golden Rule #3: Scope and Sell the Project
- Do you know who your clients are and do you have their enthusiastic support?
- Do you have a presentation that explains the business benefits of the project, its major components, how the project will be implemented and why it takes as long as it does?
- Do you have a Risk Management plan that you can execute if and when a major risk event occurs?
- Do you keep your client(s) positively engaged in the project and hold regular update/review meetings with your client(s) and project team?
- Does the Project Sponsor understand the complexity of the project and support the Project Manager in resolving problems that are outside his/her control?
Golden Rule #4: Insulate Team from Management Issues
- Is there a process for escalating problems to management and resolving issues?
- Does the Project Manager resolve internal team conflicts expeditiously, and stand up for the team when dealing with external influences, management and stakeholders?
- Is the Project Manager experience/trained to effectively delegate work, coach and support the team?
- Is the Project Manager experienced in exercising various communication tools and soft skills?
- Is there a well defined process for decision-making within the project team and is the process working?
Golden Rule #5: Teams Optimise, Individuals Maximise
- Does every team member clearly understand his/her deliverables, acceptance criteria, and the individuals who will be approving or accepting the deliverable?
- Is there an agreed facilitation process for team discussion and issue resolution?
- Are decisions arising from team meetings based on a decision making process primarily driven by consensus?
- Are the team members excited about the project experience? Do they see it as a learning opportunity for improving their competency, knowledge and skills?
- Is there a regularly published newsletter to communicate project and team achievements to all clients, stakeholders and the project team?
Golden Rule #6: Encourage & Facilitate Open Communication
- Is there a formal and structured communication process in place consisting of reviews, status reports, minutes of meetings and management updates etc.?
- Does the Communication Plan include weekly "One on One" reviews with team members?
- Does the review process allow for discussion of potential problems and possible solutions?
- Does the team environment genuinely believe in and encourage sharing and trust-building?
- Do team members believe that the team is empowered to make decisions relevant to how the work is to be done (as opposed to being micro-managed)?
Golden Rule #7: Institutionalise Positive Mindset
- Do your team members believe that their meetings are generally productive?
- Do you invite team members to provide feedback on the content and process of the meeting so that you can continually improve the management and performance of meetings?
- Are meeting participants willing to interact and listen effectively during your project meetings?
- Do your meetings focus on problem resolution as opposed to assignment of blame?
- Do you proactively ascertain the confidence and commitment of team members regularly?
Golden Rule #8: Remember the Five "R"s
- Does the project team practice and follow through the 5Rs - Respect, Recognition, Rewards, Rest and Recreation?
- Is the project baseline schedule realistic and based on reasonable assumptions?
- Do the team members believe that the project goal is both challenging and achievable?
- Do you celebrate significant achievements and milestones throughout the project life cycle?
- Do you formally thank, congratulate and recognise team members for their specific contribution on the project?
Golden Rule #9: Implement Consistent & Predictable Processes
- Are team members trained in the fundamentals of project management and are they familiar with the organisation's business terminology and project management methodology?
- Do team members clearly understand the differences and context of the various methodologies used for project management, system design, systems development, proprietary solutions and IT operations, etc.?
- Is there a clear understanding of work packages, milestones, critical path and related project dependencies among the team members?
- Are team members trained to provide meaningful, clear and concise weekly status report?
- Do team members have the opportunity to develop their communication and soft skills as part of the project experience?
Golden Rule #10: Transition the Team Graciously
- Do you get a formal sign-off from the client whenever a project deliverable is approved and accepted?
- Do you take the time to provide feedback to team members on their project performance?
- Do team members know their responsibilities with respect to Change Requests, Enhancements, Support, Warranty and Maintenance regarding the project deliverables.
- Do you hold formal debrief sessions including a post-implementation "Lessons Learned" review with the team following project completion?
- Will your team members enthusiastically volunteer to be a part of your next project?
Teams must embrace a common purpose, and develop and follow a set of common processes based on a set of values and culture adopted by the team. The Project Manager's role in team building is to guide, coach, mentor, facilitate and direct as required to achieve the intended project outcome. The success and survival of project teams depends on understanding the human side of project management.
management consultant management project
Project Management - Risk Management
In many projects, risks are identified and analysed in a random, brainstorming, fashion. This is often fatal to the success of the project, as unexpected risks arise, which have not been assessed or planned for and have to be dealt with on an emergency basis, rather than be prepared for and defended against in a planned, measured, manner. Very early in the preparation and planning stage, it is essential that potential risks are identified, categorized and evaluated. Rather than look at each risk independently and randomly, it is much more effective to identify risks and then group them into categories, or, to draw up a list of categories and then to identify potential risks within each category. This way, common influences, factors, causes, potential impacts and potential preventative and or corrective actions, can be discussed and agreed on.
Categorising risks is a way to systematically identify the risks and provide a foundation for awareness, understanding and action. Each project will have its own structure and differences, but here are some categories that are common to most projects (to which you can add your own local, sector, or project specific, categories). I have not given deep detail here, but your project team and sponsors should be able to relate to these categories and use them in the risk assessment process. For example, with "operational resources" your team can discuss issues such as, availability, delivery timing, cost, capability, necessary conditions for operation (eg. ground, weather, light); with "stakeholder resources" your team can identify all stakeholders and list potential risks that these stakeholders may generate, such as bad publicity from the media, delays caused by community or environmental groups, delays caused by utility companies, problems with trade unions. Related risks and potential actions, must then be documented in the risk management plan and discussed at all the key stages as the project progresses. All the details and the actual action taken and the outcomes, must then be recorded and reviewed during the closure and review stage, for lessons to be learned and applied to future projects.
Here the question that most project managers ask: "how do we know if we can manage the risk, if it arises?" Often, sadly, no evaluation is carried out to determine the expertise, experience, capabilities of the team, individuals, organisations that would be required to deal with, manage that risk, if it occurred. As a result, if it did, the team may not be able to deal with it effectively, even though the initial forecast was that the risk could be managed. This happens frequently when the planning team is not the project team that manages the project and/or when key individuals in the original project team leave the team during the project and are replaced by individuals with different skills, experience and capabilities. The clear message here is that setting a risk tolerance level is a dangerous business. Each potential risk needs to be carefully, rigorously, analysed and the project team, the supporting teams and individuals, the organisation(s) involved in managing the project, all need to be evaluated to determine whether there is the capability to manage that risk successfully, should it arise. Where gaps in capability are identified, then appropriate corrective action must be taken. During the project itself, this capability must be constantly monitored and, where necessary, action taken to return the level of capability to the required level.
Conflict over resources often arise during the middle to later stages of a project, because, often unexpected other, newer demands arise which are seen as being of higher priority. This can lead to resources that were originally allocated to the project being taken away, or reduced in quantity or quality, almost certainly to the detriment of the project. The answer to this dilemma is not easy, but in essence, the project management team must include "conflict over resources during the life of the project" as a major potential risk and plan for it accordingly by securing agreements and then monitoring the situation continuously. If a dispute does arise, there is a role here for the project champion and or the client to ensure that the allocated resources are not taken away.
Fundamental to many of the issues that we discuss here is the question of who should be responsible for risk assessment and management. Too often the responsibility for risk identification, assessment and management, are left to the project team, especially once the project has started. But there are other individuals and groups, including some external stakeholders, who should be continuously monitoring particular activity and feeding back regularly to the project team leader. Some are easy to identify. They include of course, the client, the sponsor, key specialists in the project team's organisation, or organisations, the major external participants, such as emergency services, local authorities and contractors.
The easy way to identify other individuals and groups is to look at your list of stakeholders. Each one has a responsibility, to a greater or lesser degree, to help identify potential risk and give information on this to the project team. Again, the answer to managing the question of risk responsibility is to build discussion, planning and action, on this into the project planning and operational activity.
management consultant management project
Categorising risks is a way to systematically identify the risks and provide a foundation for awareness, understanding and action. Each project will have its own structure and differences, but here are some categories that are common to most projects (to which you can add your own local, sector, or project specific, categories). I have not given deep detail here, but your project team and sponsors should be able to relate to these categories and use them in the risk assessment process. For example, with "operational resources" your team can discuss issues such as, availability, delivery timing, cost, capability, necessary conditions for operation (eg. ground, weather, light); with "stakeholder resources" your team can identify all stakeholders and list potential risks that these stakeholders may generate, such as bad publicity from the media, delays caused by community or environmental groups, delays caused by utility companies, problems with trade unions. Related risks and potential actions, must then be documented in the risk management plan and discussed at all the key stages as the project progresses. All the details and the actual action taken and the outcomes, must then be recorded and reviewed during the closure and review stage, for lessons to be learned and applied to future projects.
Here the question that most project managers ask: "how do we know if we can manage the risk, if it arises?" Often, sadly, no evaluation is carried out to determine the expertise, experience, capabilities of the team, individuals, organisations that would be required to deal with, manage that risk, if it occurred. As a result, if it did, the team may not be able to deal with it effectively, even though the initial forecast was that the risk could be managed. This happens frequently when the planning team is not the project team that manages the project and/or when key individuals in the original project team leave the team during the project and are replaced by individuals with different skills, experience and capabilities. The clear message here is that setting a risk tolerance level is a dangerous business. Each potential risk needs to be carefully, rigorously, analysed and the project team, the supporting teams and individuals, the organisation(s) involved in managing the project, all need to be evaluated to determine whether there is the capability to manage that risk successfully, should it arise. Where gaps in capability are identified, then appropriate corrective action must be taken. During the project itself, this capability must be constantly monitored and, where necessary, action taken to return the level of capability to the required level.
Conflict over resources often arise during the middle to later stages of a project, because, often unexpected other, newer demands arise which are seen as being of higher priority. This can lead to resources that were originally allocated to the project being taken away, or reduced in quantity or quality, almost certainly to the detriment of the project. The answer to this dilemma is not easy, but in essence, the project management team must include "conflict over resources during the life of the project" as a major potential risk and plan for it accordingly by securing agreements and then monitoring the situation continuously. If a dispute does arise, there is a role here for the project champion and or the client to ensure that the allocated resources are not taken away.
Fundamental to many of the issues that we discuss here is the question of who should be responsible for risk assessment and management. Too often the responsibility for risk identification, assessment and management, are left to the project team, especially once the project has started. But there are other individuals and groups, including some external stakeholders, who should be continuously monitoring particular activity and feeding back regularly to the project team leader. Some are easy to identify. They include of course, the client, the sponsor, key specialists in the project team's organisation, or organisations, the major external participants, such as emergency services, local authorities and contractors.
The easy way to identify other individuals and groups is to look at your list of stakeholders. Each one has a responsibility, to a greater or lesser degree, to help identify potential risk and give information on this to the project team. Again, the answer to managing the question of risk responsibility is to build discussion, planning and action, on this into the project planning and operational activity.
management consultant management project
Senin, 24 Januari 2011
ISO 31000 : 2009 Risk Management International Standard
Time until Events:
Materi
ISO Manajemen Risiko akan menjadi standar internasional untuk proses manajemen risiko. Workshop ini membantu manajemen untuk mengkaji kembali kesiapan dan kesesuaian praktik dan proses Manajemen Risiko perusahaan.
ISO (the International Organization for Standardization) adalah federasi badan standar nasional di seluruh dunia. Tugas mempersiapkan standar internasional biasanya dilaksanakan oleh ISO Technical Committee.
Standar Internasional untuk [...]
Materi ISO Manajemen Risiko akan menjadi standar internasional untuk proses manajemen risiko. Workshop ini membantu manajemen untuk mengkaji kembali kesiapan dan kesesuaian praktik dan proses Manajemen Risiko perusahaan.
ISO (the International Organization for Standardization) adalah federasi badan standar nasional di seluruh dunia. Tugas mempersiapkan standar internasional biasanya dilaksanakan oleh ISO Technical Committee.
Standar Internasional untuk manajemen risiko (ISO 31000) dimaksudkan untuk digunakan oleh berbagai stakeholders.
Banyak organisasi yang telah menerapkan praktik dan proses manajemen risiko termasuk komponen-komponen manajemen risiko dan banyak organisasi yang telah mengadopsi proses manajemen risiko formal untuk jenis-jenis risiko tertentu.
SESSI I : Improving Decision Making and Activities with Risk Management
SESSI II: Risk Management Principles
SESSI III: Risk Management System
SESSI IV: Process for Managing Risk
Materi
ISO Manajemen Risiko akan menjadi standar internasional untuk proses manajemen risiko. Workshop ini membantu manajemen untuk mengkaji kembali kesiapan dan kesesuaian praktik dan proses Manajemen Risiko perusahaan.
ISO (the International Organization for Standardization) adalah federasi badan standar nasional di seluruh dunia. Tugas mempersiapkan standar internasional biasanya dilaksanakan oleh ISO Technical Committee.
Standar Internasional untuk [...]
Materi ISO Manajemen Risiko akan menjadi standar internasional untuk proses manajemen risiko. Workshop ini membantu manajemen untuk mengkaji kembali kesiapan dan kesesuaian praktik dan proses Manajemen Risiko perusahaan.
ISO (the International Organization for Standardization) adalah federasi badan standar nasional di seluruh dunia. Tugas mempersiapkan standar internasional biasanya dilaksanakan oleh ISO Technical Committee.
Standar Internasional untuk manajemen risiko (ISO 31000) dimaksudkan untuk digunakan oleh berbagai stakeholders.
Banyak organisasi yang telah menerapkan praktik dan proses manajemen risiko termasuk komponen-komponen manajemen risiko dan banyak organisasi yang telah mengadopsi proses manajemen risiko formal untuk jenis-jenis risiko tertentu.
SESSI I : Improving Decision Making and Activities with Risk Management
- Pengantar
- ISO 31000: 2009 ‘RM Objectives’ (1)
- ISO 31000: 2009 ‘RM Objectives’ (2)
- Standart ini untuk siapa?
- Risiko menurut ISO 31000: 2009
- Faktor Pemicu Ketidakpastian
- Manajemen Risiko Organisasi
- Manajemen Risiko sebagai input
SESSI II: Risk Management Principles
- Value creation and value protection
- Risk Management and organizational processes
- Risk Management and decision making
- Risk Management and uncertainty
- Tailoring risk management align with
- Risk Management and cultural and people issues
- Risk Management and transparancy
- Risk Management and eksternal and internal changes
SESSI III: Risk Management System
- Pengantar
- Framework implementasi
- Framework continues improvement cycle
- Risk Management Process menurut ISO 31000
- Risk Management Information system
- Risk Management System
- Mandate and Commitment
- Peran penting dalam manajemen risiko
- Critical success factors
- Continual Improveme
- From crisis management to risk management
- From traditional organization to learning organization
- From compliance to strategic tool/enabler
SESSI IV: Process for Managing Risk
- Risk management system
- Risk management process ISO 31000
- Communication and Consultation
- Establishing the Context
- Risk Assessment technic
- Swot Analysis
- Risk Register
- Risk Analysis
- Graphical presentation
- Value-at-Risk]
- Earning-at-Risk
- Peta Risiko
- Risk Evaluation
- ALARP Principle
- Risk Treatment
- Proses iterasi untuk risk treatment plan
- Types of treatment
- Type of Unpredictable risk
- Treatment plan
- Risk monitoring and review process
- Risk Evaluation
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:
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
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.
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
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:
Here are seven of those questions you should ask (and answer!) when initiating a project:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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:
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:
Other areas worth capturing on projects, detailing what worked well and where improvement is needed include:
For each area (process) reviewed, capture:
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
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
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
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
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
Using a PMO to Achieve Results in Your Agency
Government agencies continually strive to produce better results. With regular mandates and quarterly score keeping by the President's Management Agenda, agencies are constantly working to become more efficient and better spenders of taxpayer dollars. Distressingly, recent surveys have found that half of all projects exceed budget, are completed past scheduled deadlines and do not meet original business objectives. One solution to this problem that has been slow to gain popularity in the public sector is the implementation of a Project Management Office (PMO). By incorporating a successful PMO into the overall project management strategy, government agencies can reduce delivery costs, improve the quality of project deliverables, improve resource management and produce more effective results.
The Project Management Office is a unique and critical tool for the success of any agency. The PMO provides oversight for the overall management of projects and programmes within an organisation. Even though responsibilities and services will vary between agencies, the unification of all projects within one overall standard will help to improve efficiency, costs and execution of project deliverables. Currently, government employees are frustrated with the variance in project policies, standards and procedures that shift from project to project. Establishing a Project Management Office would curb this frustration and unite standards, procedures and policies to make them uniform, thus improving project processes.
Diagram A
There are four common characteristics that define a Project Management Office. Diagram A highlights which benefits are directly produced from each characteristic. For example, a PMO can aid in keeping projects on budget because they coordinate the enterprise management of budget resources.
Agreeing that PMO implementation is vital to the overall future success of an agency, the next question one would ask is, "How can a Project Management Office be created within a governmental agency?"
Following the lead of the private sector, most experts agree that there is a three-step process in order to successfully implement a Project Management Office into any organisation. These three steps, which will be further analysed, are the assessing, planning and implementing.
Diagram B
Diagram B illustrates the flow path of the three phases and breaks down the actions inherent to each.
The assessment phase is the shortest phase of implementing a Project Management Office; during this phase the agency confirms its goals and understands where the PMO will lay within the organisational structure. Agency leaders should affirm the logistics of the Project Management Office by asking such questions as: "Who will the PMO report to?" "What types of project management methodologies are currently being employed in the enterprise?" or "What support does the enterprise see providing the PMO in five years?" It is important to understand that establishing a Project Management Office is a project within itself.
After making a proper assessment of the PMO within the agency, officials then begin deliberation concerning the role and responsibility of the Project Management Office. Often times dictated by tight budgets and limited resources, agencies would need to illustrate the staffing needs for the PMO. From this information a "project implementation plan" will be created. This plan will serve as the key transition from phase two to phrase three. The "project implementation plan" defines the project scope using the work breakdown structure (WBS). The plan also describes the work which needs to be performed and estimates the resources will be needed to execute that work. Using these descriptions, the plan proposes a project schedule and a budget. When this is completed, the organisation can easily transfer into the last phase, implementation.
The final phase of PMO implementation strives to guarantee success of the Project Management Office by establishing long-term measures and metrics by which results will be measured. These results will guide officials to determine the future role of the PMO and whether or not to encourage its growth and facilitate organisational adaptation. The project management methodology implemented during this phase should include language and practices that illustrate the value derived from the Project Management Office and should highlight the organisation's goal of improving deliverables and minimising risk.
Project Management Offices are an untapped tool that government agencies need to improve quality and produce better and more efficient results. Implementing PMOs can open up agencies to be beneficiaries of improved budget estimations and successful project execution. Both of which will ensure that taxpayer dollars are not being wasted. The Performance Institute understands the values that Project Management Offices can bring to any organisation and has planned the 2006 Project Management Office Summit in Arlington, VA to further the exchange of best-practices surrounding this tool.consultant management Construction Management
The Project Management Office is a unique and critical tool for the success of any agency. The PMO provides oversight for the overall management of projects and programmes within an organisation. Even though responsibilities and services will vary between agencies, the unification of all projects within one overall standard will help to improve efficiency, costs and execution of project deliverables. Currently, government employees are frustrated with the variance in project policies, standards and procedures that shift from project to project. Establishing a Project Management Office would curb this frustration and unite standards, procedures and policies to make them uniform, thus improving project processes.
Diagram A
| A. Reduce Risk | B. Keep Projects on Budget | C. Keep Projects on Time | D. Ensure Improved Project Quality |
|---|---|---|---|
| Centralised repository for shared risk | Coordinates overall resources | Sets overall policies and procedures | Operates and manages overall project tools |
| Centralised proactive management initiatives to combat project risk | Enterprise management of budget resources | Provides universal templates and documentation | Centralised communication management |
| Enterprise management of project timelines | Provides mentoring and skill development | ||
| Repository of best practice information |
Agreeing that PMO implementation is vital to the overall future success of an agency, the next question one would ask is, "How can a Project Management Office be created within a governmental agency?"
Following the lead of the private sector, most experts agree that there is a three-step process in order to successfully implement a Project Management Office into any organisation. These three steps, which will be further analysed, are the assessing, planning and implementing.
Diagram B
| Assessing | Planning | Implementing | ||
|---|---|---|---|---|
| Define the goals of the organisation. |  | Define the function of the PMO and its responsibility. | | Establish corporate project management methodologies. |
| Understand how the organisation view the PMO. | | Define the staffing of the PMO. | | Establish quality metrics and tools which will be the guidelines for PMO assessment. |
| Identify what project management methodologies, procedures and systems exist or are already planned. | | Create a Project implementation plan. | | Define PMO internal procedures. |
The assessment phase is the shortest phase of implementing a Project Management Office; during this phase the agency confirms its goals and understands where the PMO will lay within the organisational structure. Agency leaders should affirm the logistics of the Project Management Office by asking such questions as: "Who will the PMO report to?" "What types of project management methodologies are currently being employed in the enterprise?" or "What support does the enterprise see providing the PMO in five years?" It is important to understand that establishing a Project Management Office is a project within itself.
After making a proper assessment of the PMO within the agency, officials then begin deliberation concerning the role and responsibility of the Project Management Office. Often times dictated by tight budgets and limited resources, agencies would need to illustrate the staffing needs for the PMO. From this information a "project implementation plan" will be created. This plan will serve as the key transition from phase two to phrase three. The "project implementation plan" defines the project scope using the work breakdown structure (WBS). The plan also describes the work which needs to be performed and estimates the resources will be needed to execute that work. Using these descriptions, the plan proposes a project schedule and a budget. When this is completed, the organisation can easily transfer into the last phase, implementation.
The final phase of PMO implementation strives to guarantee success of the Project Management Office by establishing long-term measures and metrics by which results will be measured. These results will guide officials to determine the future role of the PMO and whether or not to encourage its growth and facilitate organisational adaptation. The project management methodology implemented during this phase should include language and practices that illustrate the value derived from the Project Management Office and should highlight the organisation's goal of improving deliverables and minimising risk.
Project Management Offices are an untapped tool that government agencies need to improve quality and produce better and more efficient results. Implementing PMOs can open up agencies to be beneficiaries of improved budget estimations and successful project execution. Both of which will ensure that taxpayer dollars are not being wasted. The Performance Institute understands the values that Project Management Offices can bring to any organisation and has planned the 2006 Project Management Office Summit in Arlington, VA to further the exchange of best-practices surrounding this tool.consultant management Construction Management
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.
- 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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. - 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.
Project Planning in a Nutshell
Improvement happens one project at a time. But often projects fail because they are poorly planned, or even completely unplanned. This article provides an overview of why it is important to prepare a project plan. It also shows what elements a good project plan will include.
Improvement happens one project at a time, but without proper planning these project may well fail to deliver their objectives.
consultant management Construction Management
Why Create a Project Plan?
There are several reasons why one should plan carefully before starting a project:- The plan is a simulation of prospective project work, which allows flaws to be identified in time to be corrected.
- The plan is a vehicle for discussing each person's role and responsibilities, thereby helping direct and control the work of the project.
- The plan shows how the parts fit together, which is essential for co-ordinating related activities.
- The plan is a point of reference for any changes of scope, thereby helping project managers deal with their customers.
- The plan helps everyone know when the objectives have been reached and therefore when to stop.
Elements of a Good Project Plan
The project plan shows the "why" and the "how" of a project. A good project plan will include the following elements:- Statement of the goal.
- Cost/benefit analysis.
- Feasibility analysis.
- Listing of the major steps to be taken.
- Timetable for completion.
- Description of the resources required (including human resources) to carry out the project.
Project Decomposition
Most projects important enough to have a significant impact on quality are too large to tackle all at once. Instead, large projects must be broken down into smaller projects and, in turn, into specific work elements and tasks. The process of going from project objectives to tasks is called decomposition. Project decomposition begins with the preparation of a preliminary plan. A preliminary project plan will identify, in broad high-level terms, the objectives of the project and constraints in term of time and resources. The work to be performed should be described and precedence relationships should be sketched out. Preliminary budgets and schedules will be developed. Finally, subplans will be developed for each subproject for the following:- Control plans.
- Quality control plans.
- Cost control plans.
- Schedule control plans.
- Staffing plans.
- Material plans.
- Reporting plans.
- Other plans as deemed necessary.
Improvement happens one project at a time, but without proper planning these project may well fail to deliver their objectives.
consultant management Construction Management
Minggu, 23 Januari 2011
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:
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.
And once you have a difficult client, take these steps:
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.
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.
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.
The Beginning of the End: Defining Project Closure
How do you know when your part of the development race is over? Learn how to establish a clear finish line for your project!
When undertaking a software development project, an effectively designed closure plan serves as an outline of required tasks that must be carried out appropriately in order to result in successful project delivery, and adequate preparation is one significant element when it comes to ensuring a smooth transition to implementation. The closure plan must be considered at the outset of the project, as the client outlines their specific software requirements. With a detailed description of the desired end result communicated and understood, the expected capabilities and deliverables of the software are established. But as you enter the final stages of a software development project, what can be done in order to ensure that the program is completely suitable and fully primed for implementation?
Many of these last-minute additions or necessary changes can be uncovered during the building and testing phases of the software development project. Not only can the exact capabilities of the software be established, but limitations will be identified as well. Often, it is ultimately the end user who will have the best perspective when it comes to specifying the software requirements where implementation and daily application use are concerned. It is the responsibility of the chosen software development company to determine the most effective approaches to fixes and additions, as well as to implement project resources effectively in order to do so in the most efficient and timely manner possible.
Coley highlights that another main challenge to overcome is to ensure that the technology meets the real needs of the end users, which can be addressed by having a method in place to obtain feedback from the end users regarding the software's capabilities. "Happy users a successful project makes! It's not over until the end user sings!" he says. The focus should continually be on the needs of the clients.
Writing software specific to the needs of a client can have a dramatic impact on the timeline for the program building phase. The tasks demanded of the software can become great, especially as the client delves further into their detailed notes as to individualised performance expectations. More often than not, a client may find that as the development phases continue and as they come to further understand the program's capabilities, they will want it to do more than originally expected.
Each individual program developed will present unique, specific challenges. While some of these are visible immediately, others will be uncovered throughout the process of development. The results that will be delivered at the close of the project are those that were seeded from the beginning, which is why it is so critical that effective lines of communication be established before, during, and even after the project's completion to ensure the satisfaction of the end users following implementation.
The demands of the client can potentially present its own set of challenges-another reason why it is imperative to keep lines of communication open and clear. The client must feel confident that their needs are being met, and it is monumentally important for the staff creating the program to be made aware of needed changes immediately as they arise. A first-rate leader will find the appropriate balance of communications on both sides of the conference room. As Coley emphasises, "Communicate, communicate, communicate! When developing as a team, effective communication among those working on a project as well as effective communication with the customer is crucial. It's elementary, my Dear Watson."
Scheduling of appropriate tests, the build phases based on the project's demands, and the client's expectations of delivery are all important areas where an effective leader should be communicating and reacting as the circumstance dictate. It is through these efforts that the project may maintain its proper flow toward the delivery deadline.
As with any project, there's always a degree of variable or unknowns that will occur and must be overcome. By testing regularly, from the early stages through to the end of the project, you are addressing the risk of potential errors and ensuring a timely delivery for a satisfied client.
When it comes to determining the degrees and stages of testing to be carried out throughout a project, Coley encourages first considering the nature of the project itself. "Is the project the result of a detailed specification prepared well in advance of coding and basically a design pretty much cast in stone? If there is pretty much a hard and fast design to which you must adhere, then certainly as one enters the closing phases of the project, testing to determine adherence to all specifications is critical," he asserts. "I believe this often is not the case, perhaps because there is too much to test, so testing is not performed completely , with reliance instead placed on the testing done throughout the creative process and only minimal 'final' testing."
In an environment where a client requests the creation of software suited specifically to their unique business structure, Coley uses his experience to suggest, "This kind of project requires the most extensive testing. Testing throughout the creative process should be applied consistently, and the affects of the changes/additions of new or newly coded functionality should be tested thoroughly as the project progresses. This extensive testing often conflicts with unrealistic schedules and often is not completed," Coley notes.
"I believe that all too often, the challenges of testing incorporated changes and/or additions becomes more than a development team can handle effectively. In my opinion, the best testers are the end users themselves. Closing phases of a project are smoother with more user input," he adds. "I realise that not all projects can include user input and that getting user input itself can be a huge challenge." However, obtaining their input during any project that allows for it makes such communication an invaluable resource.
These components, however, are unique to each project and must be considered on a individual basis; while there may be similarities among projects, what may have worked well during a project in the past might not be best suited for a current project. Establishing and maintaining a plan with the end user in mind makes for a smoother transition and successful close of a software development project.
consultant management manajemen konstruksi
When undertaking a software development project, an effectively designed closure plan serves as an outline of required tasks that must be carried out appropriately in order to result in successful project delivery, and adequate preparation is one significant element when it comes to ensuring a smooth transition to implementation. The closure plan must be considered at the outset of the project, as the client outlines their specific software requirements. With a detailed description of the desired end result communicated and understood, the expected capabilities and deliverables of the software are established. But as you enter the final stages of a software development project, what can be done in order to ensure that the program is completely suitable and fully primed for implementation?
Key Components
According to Joe Coley [1], "Projects that I've been involved with have been very much subject to additional needs and desires of the user community." In effect, this means that the end deliverable becomes the focus of the closure plan, that is, to ensure a high level of end user satisfaction with the software requested and therefore created. Coley has 20 years of experience in the information technology industry and offers much insight on the subject. When it comes to key components for successful closure plans, he highlights three main aspects to consider, presented below:- Assess the project requirements. In order to determine the best course of action throughout the cycle of a project, it is necessary to first consider the scope of the project. Establishing a clear outlook and complete understanding as to the required deliverables will greatly improve the ability to adequately determine exactly what tasks must be carried out in order to meet these deliverables in an efficient and timely manner.
- Communication. While communication is always essential throughout the cycle of any project or initiative, it is imperative to establish a specific plan for obtaining end-user input, as needed and where feasible. Therefore, a key component to a successful close is establishing and maintaining open lines of communication with the appropriate groups. The end users comprise the group of those who will be utilising the software in real-time business applications; they have the critical business knowledge as to ways in which the software can be created or functionality that can be incorporated so that the result will be a valuable tool with the capability to enhance their business functions.
- Offer continuing support. When it comes to considering a focus on the continuing support needs of the end-user community, Coley cites a specific reason to do so, "There is always an expectation of continuing support in the form of application tweaks, bug fixes, and enhancements." By extending continuing support to the end users, they have more confidence in the software program as well as in their chosen developer.
What Impacts Implementation?
Each project has its own specific design layout and requirements, thereby making every delivery unique. In creating a closure plan, a key initial imperative is to clearly define the client's objectives in relation to their software needs, which should include key elements from the earlier discussion regarding the functionality and other requirements communicated by the end user. Client communication is essential from the beginning in order to have an appropriately formed program structure, ensuring that no important features are overlooked. Establishing and maintaining strong and regular communication during the early phases of the project can help to prevent last-minute additions that the client may want or later decide are necessary to incorporate into the software.Many of these last-minute additions or necessary changes can be uncovered during the building and testing phases of the software development project. Not only can the exact capabilities of the software be established, but limitations will be identified as well. Often, it is ultimately the end user who will have the best perspective when it comes to specifying the software requirements where implementation and daily application use are concerned. It is the responsibility of the chosen software development company to determine the most effective approaches to fixes and additions, as well as to implement project resources effectively in order to do so in the most efficient and timely manner possible.
Coley highlights that another main challenge to overcome is to ensure that the technology meets the real needs of the end users, which can be addressed by having a method in place to obtain feedback from the end users regarding the software's capabilities. "Happy users a successful project makes! It's not over until the end user sings!" he says. The focus should continually be on the needs of the clients.
Writing software specific to the needs of a client can have a dramatic impact on the timeline for the program building phase. The tasks demanded of the software can become great, especially as the client delves further into their detailed notes as to individualised performance expectations. More often than not, a client may find that as the development phases continue and as they come to further understand the program's capabilities, they will want it to do more than originally expected.
Each individual program developed will present unique, specific challenges. While some of these are visible immediately, others will be uncovered throughout the process of development. The results that will be delivered at the close of the project are those that were seeded from the beginning, which is why it is so critical that effective lines of communication be established before, during, and even after the project's completion to ensure the satisfaction of the end users following implementation.
Right Resources, Right Words, Right Time
One element to consider in ensuring the development of an effective closure plan is that the employees assigned to critical tasks within the organisation must be those who are best suited for their respective positions, with appropriate, applicable knowledge and experience and necessary resources. Also, by displaying strong, confident leadership continually throughout the project cycle, a valuable manager can keep the entire staff focused on the ultimate goal of satisfying the client's requirements. This is where the communication aspect of any development plan comes into play. Project managers act as diplomats; they must establish and maintain ongoing effective communication with the client about their needs and relay this critical information to their own workers who are responsible for meeting the requirements of the software build.The demands of the client can potentially present its own set of challenges-another reason why it is imperative to keep lines of communication open and clear. The client must feel confident that their needs are being met, and it is monumentally important for the staff creating the program to be made aware of needed changes immediately as they arise. A first-rate leader will find the appropriate balance of communications on both sides of the conference room. As Coley emphasises, "Communicate, communicate, communicate! When developing as a team, effective communication among those working on a project as well as effective communication with the customer is crucial. It's elementary, my Dear Watson."
Scheduling of appropriate tests, the build phases based on the project's demands, and the client's expectations of delivery are all important areas where an effective leader should be communicating and reacting as the circumstance dictate. It is through these efforts that the project may maintain its proper flow toward the delivery deadline.
Test...Test...Test
If appropriate testing is not carried out in accordance with end-user requirements, delivery of a project may be severely hindered. Overlooking even a seemingly simple test can lead to poor software performance. Testing the software is the most critical of the phases in a closure plan, and it must be done throughout the build of the software.As with any project, there's always a degree of variable or unknowns that will occur and must be overcome. By testing regularly, from the early stages through to the end of the project, you are addressing the risk of potential errors and ensuring a timely delivery for a satisfied client.
When it comes to determining the degrees and stages of testing to be carried out throughout a project, Coley encourages first considering the nature of the project itself. "Is the project the result of a detailed specification prepared well in advance of coding and basically a design pretty much cast in stone? If there is pretty much a hard and fast design to which you must adhere, then certainly as one enters the closing phases of the project, testing to determine adherence to all specifications is critical," he asserts. "I believe this often is not the case, perhaps because there is too much to test, so testing is not performed completely , with reliance instead placed on the testing done throughout the creative process and only minimal 'final' testing."
In an environment where a client requests the creation of software suited specifically to their unique business structure, Coley uses his experience to suggest, "This kind of project requires the most extensive testing. Testing throughout the creative process should be applied consistently, and the affects of the changes/additions of new or newly coded functionality should be tested thoroughly as the project progresses. This extensive testing often conflicts with unrealistic schedules and often is not completed," Coley notes.
"I believe that all too often, the challenges of testing incorporated changes and/or additions becomes more than a development team can handle effectively. In my opinion, the best testers are the end users themselves. Closing phases of a project are smoother with more user input," he adds. "I realise that not all projects can include user input and that getting user input itself can be a huge challenge." However, obtaining their input during any project that allows for it makes such communication an invaluable resource.
Success from Beginning to End
It is essential to be prepared throughout the entire life cycle of a software development project, and an important element of preparation is to have established an insightful closure plan. In order to create a successful closure plan, key components to consider include communication both among the team and with the client, testing throughout the life of the project, and clearly defined expected results from the client at the outset as to how they wish the software to perform.These components, however, are unique to each project and must be considered on a individual basis; while there may be similarities among projects, what may have worked well during a project in the past might not be best suited for a current project. Establishing and maintaining a plan with the end user in mind makes for a smoother transition and successful close of a software development project.
consultant management manajemen konstruksi
Survey Bisnis Konstruksi Indonesia 2009
Beberapa waktu lalu, suatu survei tahap-1 terkirim yang bermaksud mendapatkan masukan tentang dampak dari factor-faktor dan dan luar terhadap strategi bisnis konstruksi. Perusahaan anda termasuk dalam populasi dari perusahaan konstruksi yang beroperasi di Indonesia. Survei merupakan proyek penelitian mahasiswa pasca sarjana yang dibiayai oleh Queensland University of Technology Australia.
Jika anda telah menyelesaikan dan mengembalikan survey tersebut kepada kami, perkenankan kami mengucapkan terima kasih. Jika belum, sebagaimana Survey Tahap-2 ini merupakan survey tindak-lanjut dengan anda tentang survey sebelumnya, dan kami akan sangat menbghargai jika anda dapat melengkapi daftar pertanyaan hari ini. Kami memahami bahwa ini adalah waktu yang sangat menyibukkan tahun ini, tetapi adalah hal yang sangat penting bahwa informasi tentang asset dan kapabilitas perusahaan anda termasuk dalam studi kami untuk memberi gambaran yang luas tentang bisnis konstruksi yang beroperasi di Indonesia. Survei ini memerlukan waktu sekitar 15 - 30 menit untuk dilengkapi versi cetak.
Untuk melengkapi survei ini, dimohon untuk memperhatikan instruksi sebagai berikut:
1. Survey ini akan mengkaji hubungan antara asset, kapabilititas dan kinerja perusahaan, kami menganjurkan untuk dengan singkat membaca semua faktor di Bagian Pertama, dan Daftar definisi yg tersedia sebelum membuat tanggapan akhir.
2. Untuk setiap item pertanyaan, mohon lingkari nomor yang tepat sesuai dengan jawaban anda. Terdapat tiga (3) bagian untuk diselesaikan ( Section/Bagian I, II, dan III)
3. Semua informasi dari sini akan diperlakukan dengan sangat rahasia. Semua data yang terkumpul akan dianalisa dan semua informasi tentang perusahaan/responden akan disimpan terpisah dari data survey.
4. Jika nada berkenan untuk menerima souvenir dan ringkasan hasil survey dari kami, mohon mengisi data respondend pada tempat yang tersedia di bagian akhir survey ini (hal.9).
5. Dimohon untuk melengkapi survey ini sebelum tanggal 31 Maret jika memungkinkan.. Survei yang telah diselesaikan agar dikirim melalu fax atau surat elektronik kepada M. Sapri Pamulu / Stephen Kajewski, BEE-QUT Brisbane, Australia 4001, Fax +61-7-31381170 (Internasional) or +62-21-7817235 (Lokal) atau email to m.pamulu@qut.edu.au
management consultant management project consultant management manajemen konstruksi
Jika anda telah menyelesaikan dan mengembalikan survey tersebut kepada kami, perkenankan kami mengucapkan terima kasih. Jika belum, sebagaimana Survey Tahap-2 ini merupakan survey tindak-lanjut dengan anda tentang survey sebelumnya, dan kami akan sangat menbghargai jika anda dapat melengkapi daftar pertanyaan hari ini. Kami memahami bahwa ini adalah waktu yang sangat menyibukkan tahun ini, tetapi adalah hal yang sangat penting bahwa informasi tentang asset dan kapabilitas perusahaan anda termasuk dalam studi kami untuk memberi gambaran yang luas tentang bisnis konstruksi yang beroperasi di Indonesia. Survei ini memerlukan waktu sekitar 15 - 30 menit untuk dilengkapi versi cetak.
Untuk melengkapi survei ini, dimohon untuk memperhatikan instruksi sebagai berikut:
1. Survey ini akan mengkaji hubungan antara asset, kapabilititas dan kinerja perusahaan, kami menganjurkan untuk dengan singkat membaca semua faktor di Bagian Pertama, dan Daftar definisi yg tersedia sebelum membuat tanggapan akhir.
2. Untuk setiap item pertanyaan, mohon lingkari nomor yang tepat sesuai dengan jawaban anda. Terdapat tiga (3) bagian untuk diselesaikan ( Section/Bagian I, II, dan III)
3. Semua informasi dari sini akan diperlakukan dengan sangat rahasia. Semua data yang terkumpul akan dianalisa dan semua informasi tentang perusahaan/responden akan disimpan terpisah dari data survey.
4. Jika nada berkenan untuk menerima souvenir dan ringkasan hasil survey dari kami, mohon mengisi data respondend pada tempat yang tersedia di bagian akhir survey ini (hal.9).
5. Dimohon untuk melengkapi survey ini sebelum tanggal 31 Maret jika memungkinkan.. Survei yang telah diselesaikan agar dikirim melalu fax atau surat elektronik kepada M. Sapri Pamulu / Stephen Kajewski, BEE-QUT Brisbane, Australia 4001, Fax +61-7-31381170 (Internasional) or +62-21-7817235 (Lokal) atau email to m.pamulu@qut.edu.au
Langganan:
Postingan (Atom)