Refleksi Surgawi - Renungan - Dari : Pelita Hidup

“Diamlah dan ketahuilah, bahwa Akulah Allah! Aku ditinggikan di antara bangsa-bangsa, ditinggikan di bumi!” Mazmur 46:11

LetJesusHelpYou.Com

Seorang teman menunjukkan foto yang dia ambil di Taman Nasional Shinjuku Gyoen, sebuah taman yang besar di tengah kepadatan kota Tokyo. Foto itu menunjukkan langit biru yang indah dengan sebuah pohon di tengah foto.

Ketika saya puji dia atas keindahan hasil jepretannya, dia menjadi geli. Dia berkata, “Kamu melihatnya secara terbalik. Itu adalah gambar pantulan langit pada danau.

Ketika saya perhatikan dengan seksama, saya menyadari bahwa dia berkata benar. Yang sebelumnya saya pikir adalah pemandangan yang indah merupakan pantulan pada permukaan danau, yang persis seperti cermin. Saya kagum betapa bersih langit dan sekitarnya yang tercermin pada air yang tenang. Hal itu membuat saya merenungkan betapa indahnya jika hidup saya mencerminkan kedamaian dan ketenangan surgawi.

Tuhan mengajarkan saya untuk mengetahui bahwa Dia mengawasi dan memegang kontrol atas hidup kita. Dia berkata, “Diamlah dan ketahuilah, bahwa Akulah Allah.”

Tetapi ketika ada masalah yang datang menimpa, hal itu dapat mengacaukan kehidupan roh saya dan membuat saya tak berdaya. Orang lain dapat melihat gelombang yang mengacaukan hidup saya, dan bukan pantulan ketenangan surgawi.

Saya tidak dapat menghindari badai kehidupan, tetapi badai tersebut tidak boleh merampas damai sejahtera Allah dalam hidup saya. Saya dapat berpegang teguh pada janji Tuhan bahwa pencobaan ini tidak akan melebihi dari yang dapat saya tanggung; Tuhan akan senantiasa menyediakan jalan keluar.

Tuhan juga siap, bersedia dan sanggup memberikan kebaikan dari setiap situasi dan keadaan, jika hati saya siap dan saya mengandalkan tuntunan dan pertolongan dari Tuhan.

Jadi, ketika masalah datang menimpa, saya punya pilihan: apakah saya akan mencerminkan badai laut yang bergelora, atau orang lain akan melihat bahwa hidup saya tetap mencerminkan damai surgawi di dalam setiap tindak dan perilaku saya.

“Pencobaan-pencobaan yang kamu alami ialah pencobaan-pencobaan biasa, yang tidak melebihi kekuatan manusia. Sebab Allah setia dan karena itu Ia tidak akan membiarkan kamu dicobai melampaui kekuatanmu. Pada waktu kamu dicobai Ia akan memberikan kepadamu jalan ke luar, sehingga kamu dapat menanggungnya.” 1 Korintus 10:13

“Kita tahu sekarang, bahwa Allah turut bekerja dalam segala sesuatu untuk mendatangkan kebaikan bagi mereka yang mengasihi Dia, yaitu bagi mereka yang terpanggil sesuai dengan rencana Allah.” Roma 8:28

Sumber : Pelita Hidup

A Way To Know Who I Am

Long, I endure for this feeling ..
Waiting for you open your heart ..

I tried many ways to reach you ..
But still, you lock your heart ..

I felt unsure about this feeling ..
When I knew, everything is so confusing ..

I have learned from the past ..
That love can not be forced ..

Now leave the past behind, walk into the future ..
All I wanna do is find a way ..
A way to know who I am ..

Boss Selalu Benar ( Anekdot )

Sekedar iseng mencari bahan di internet tentang bos dan staff / karyawannya, saya menemukan anekdot yang menarik. Bagi yang belum tau anekdot itu apa berikut adalah pengertian yang saya ambil dari wikipedia : sebuah cerita singkat dan lucu atau menarik, yang mungkin menggambarkan kejadian atau orang sebenarnya. Anekdot bisa saja sesingkat pengaturan dan provokasi dari sebuah kelakar. Anekdot selalu disajikan berdasarkan pada kejadian nyata melibatkan orang-orang yang sebenarnya, apakah terkenal atau tidak, biasanya di suatu tempat yang dapat diidentifikasi.

Anekdot: Bukti Bahwa yang Namanya Boss itu Memang Selalu Benar

Bagi Anda para boss, yang ingin melanggengkan kedudukan anda sebagai boss, perlu sekali memperhatikan tips di bawah ini yang harus anda tekankan kepada bawahan anda supaya dihayati.

PERATURAN BOSS:

Nomor 1: Boss selalu benar.
Nomor 2: Apabila boss melakukan kesalahan. Baca aturan Nomor 1.

Bila boss bersikukuh dengan pendapatnya, itu artinya beliau konsisten.
Bila staff bersikukuh pada pendapatnya, itu artinya dia keras kepala, kepala batu!

Bila boss berubah-ubah pendapatnya, itu berarti beliau fleksibel.
Bila staff berubah-ubah pendapatnya, itu berarti dia plin-plan! Tidak punya pendirian!

Bila boss bekerja lambat, itu artinya beliau teliti.
Bila staff bekerja lambat, itu artinya dia tidak “perform”!

Bila boss bekerja cepat, itu artinya beliau “smart”.
Bila staff bekerja cepat, itu artinya dia terlalu terburu-buru!

Bila boss lambat dlm mengambil keputusan, itu artinya beliau berhati-hati.
Bila staff lambat dlm mengambil keputusan, itu artinya dia “telmi”!

Bila boss cepat mengambil keputusan, itu artinya beliau berani mengambil risiko.
Bila staff cepat mengambil keputusan, itu artinya dia gegabah! Ceroboh!

Bila boss meng-by-pass prosedur, itu artinya beliau proaktif-inovatif-kreatif.
Bila staff meng-by-pass prosedur, itu artinya dia melanggar aturan!

Bila boss curiga terhadap mitra bisnis, itu artinya beliau waspada.
Bila staff curiga terhadap mitra bisnis, itu artinya dia negative-thinking! Paranoid!

Bila boss mengatakan” “Sulit,” itu artinya beliau predektif-antisipatif.
Bila staff mengatakan: “Sulit,” artinya dia pesimistik!

Bila boss mengatakan: “Mudah,” itu artinya beliau optimis.
Bila staff mengatakan: “Mudah,” itu artinya dia meremehkan masalah!

Bila boss sering keluar kantor, itu artinya beliau rajin ke customer, rajin dan sibuk.
Bila staff sering keluar kantor, itu artinya dia sering keluyuran!

Bila boss sering entertain, itu artinya beliau rajin meng-lobby customer.
Bila staff sering entertain, itu artinya dia menghamburkan anggaran!

Bila boss tidak pernah entertain, itu artinya beliau hemat.
Bila staff tidak pernah entertain, itu artinya dia tidak becus me-lobby customer!

Bila boss mengservis atasan, itu artinya dia meng-lobby.
Bila staff mengservis atasan, itu artinya dia menjilat!

Bila boss sering tidak masuk, itu artinya beliau kecapean karena kerja keras.
Bila staff sering tidak masuk, itu artinya dia seorang pemalas!

Bila boss minta fasilitas mewah, itu artinya beliau menjaga citra perusahaan.
Bila staff minta fasilitas mewah, itu artinya dia terlalu banyak menuntut, tidak tau diuntung!

yang terakhir ...

Bila boss membuat tulisan seperti ini, itu artinya beliau pandai membuat lelucon: humoris jempolan.

Bila staff membuat tulisan seperti ini, itu artinya dia sedang frustasi, kurang kerjaan, penggangguran, iri terhadap karier orang lain, negative thinking, tidak tahan banting, provokatif ,dan BSH alias Barisan Sakit Hati!

tambahan ...

Jika BOS mengirim Joke ini ke karyawan berarti PEACE.

Jika SAYA nekat mengirim Joke ini ke bos berarti REST IN PEACE. 

Tapi ingat karyawan bisa menjadi bos. Jadi kapan anda menjadi bos?
 

Sumber 1 : Kompasiana

Sumber 2 : Pintu Kerja

Mau Buka Cabang Usaha Tapi Tak Percaya Karyawan, Ini Solusinya

Pertanyaan:
Saya mau tanya ketika saya ingin membuka cabang untuk bisnis pakaian saya bagaimana saya bisa mempercayakan karyawan di toko cabang saya, sedangkan saya tidak bisa mengawasi semua cabang setiap hari. Apakah ada barang yang diambil karyawan atau mereka mengambil uangnya.

Jawaban:
Untuk menambah pendapatan dan mengembangkan usaha memang salah satunya adalah membuka cabang. Beberapa tips yang dapat saya berikan sebelum Anda membukan cabang yang baru sebagai berikut:

• Anda harus menguasai secara penuh operasional bisnis pakaian anda tersebut. Anda menjalani operasional sehari-hari bisnis anda tersebut secara penuh waktu dan Anda akan menjadi mengetahui secara penuh atas jalannya operasional bisnis anda dari semua lini. Dari pengalaman Anda menjalankan operasional sehari-hari tersebut maka anda akan menemui banyak pengetahuan dan juga mengetahui celah-celah kebocoran yang mungkin terjadi dari sisi operasional, manajemen, keuangan dan SDM.

• Susun dan tulislah secara rutin apa pun prosedur bisnis secara operasional sehari-hari/rutinitas dari hal yang terkecil hingga yang besar. Sehingga Anda akan mempunyai SOP (standard operational procedure) dan skema alur kerja dengan penjelasannya yang dapat diberikan kepada tim kerja anda. Misalnya prosedur pelayanan kepada pelanggan dan lain-lain.

• Jadilah pemimpin bisnis yang dapat menjadi contoh untuk para tim kerja Anda. Mereka akan mengikuti cara kerja Anda dan disiplin sehari-hari yang anda lakukan. Berikan mereka beberapa wewenang dan tanggungjawab yang dapat Anda nilai dan Anda dapat percayai. Sehingga Anda akan mampu menciptakan pemimpin baru bisnis Anda dari tim kerja Anda.

• Bangunlah sistem penerimaan karyawan baru dan sistem pelatihan. Jika diperlukan gunakan konsultan SDM untuk mendapatkan karyawan baru dengan personality sesuai yang Anda inginkan. Siapkan beberapa pelatihan keterampilan dari internal maupun eksternal untuk tim kerja Anda. Sumber daya manusia (SDM) dari cabang utama ini, yang sudah terdidik dan teruji, dapat anda jadikan pemimpin di cabang Anda yang baru. Sehingga juga ada jenjang karir yang jelas di usaha Anda untuk memberikan kepada para karyawan kesempatan dan tantangan.

• Buatlah perjanjian kerja dengan karyawan dan buatlah aturan kerja yang jelas. Jelaskan apa saja pekerjaan mereka sehari-hari yang harus dilakukan, standar prosedur yang harus diikuti dan tujuan bisnis yang ingin perusahaan capai.

• Lakukan pertemuan rutin untuk membantu para tim kerja bekerja lebih baik untuk mencapai target capaian pekerjaannya dan untuk memberikan mereka motivasi sehingga mereka akan merasakan nyamannya bekerja dalam satu tim yang saling membantu dan saling mempercayai. Dengan meeting rutin ini juga, Anda selalu mengingatkan atas apa saja visi, misi, budaya dan goal perusahaan yang Anda inginkan. Dan dari meeting ini akan tercipta juga jalur komunikasi yang efektif dan terbuka.

• Ciptakan sistem keuangan, sistem akunting dan sistem stok yang baik dan jika memungkinkan sudah komputerisasi sehingga dapat mengontrol dan mencatat dengan baik.

• Manfaatkan teknologi untuk efisiensi dan efektivitas serta keamanan usaha anda di cabang baru, seperti sistem komputerisasi, sistem security, jalur komunikasi via phone/email/internet/fax, CCTV, mesin absensi dan lain-lain.

Semoga bermanfaat dan dapat membangun cabang barunya.

Sumber : Detik Finance

Be Part Of Solution Not Problem - Ridwan Kamil

Selamat datang di bulan Februari... Berhubung kemarin adalah hari raya Imlek, saya ingin mengucapkan 'Selamat Hari Raya Imlek - Gong Xi Fa Cai'. Tidak terasa yaaa, 1 bulan telah terlalui di 2014. Bagi saya bulan Januari adalah bulan pemanasan dan persiapan menuju bulan yang akan datang. Dari target perusahaan dan departemen sendiri belum dijelaskan, jadi bulan Januari kemarin cenderung menyelesaikan segala pekerjaan yang tertunda di 2013 kemarin. Bersyukur saya juga masih bisa menikmati cuti dan suasana di kampung halaman sekarang ini.

Oyaaa, kemarin saya melihat tweet dari bapak Ridwan Kamil. Beliau adalah walikota Bandung. Berikut adalah tweet dari beliau :

"If you cannot be part of solution, at least you are not part of the problem."

Terjemahan Indonesia : Jika anda tidak bisa menjadi bagian dari solusi, setidaknya anda bukan bagian dari masalah.

Bahasa Sunda Versi Kasar : Mun maneh teu bisa jadi solusi, paling nteu ulah jadi masalah.

Apa yang disampaikan bapak Ridwan melalui tweet tersebut sangatlah merema bagi followers nya. Buktinya ada lebih dari 2000 re-tweet dan 300 favorites. Saya juga termasuk dalam golongan setuju. Tweet tersebut sangat cocok diterapkan dalam lingkup sehari-hari yang mana seringkali kita salah memposisikan diri kita sendiri dihadapan orang lain. Pilihan yang kita putuskan bisa menjadi solusi dan masalah, kecuali pilihannya adalah abstain / golput / tidak memilih. Melalui tweet ini kita diingatkan untuk menjadi lebih bijaksana lagi dalam menentukan pilihan atau segala sesuatunya. Akhir kata selamat menikmati akhir pekan, semoga postingan ini bermanfaat. :)

Business Analysis Performance (BA Planning & Monitoring)

At last we arrive at the end of chapter2. After a long sub-chapter about approach, stakeholder, activities, communications, requirements and now the last is performance. We as a BA  must ensure all activities are executed correctly and efficiently. Managing performance is also helpful for review and improve business analysis performance. Let's learn more from BABOK about the this performance of business analysis.

2.6 Manage Business Analysis Performance

#Purpose
To manage the performance of business analysis activities to ensure that they are executed as effectively as possible.

#Description
This tasks covers determining which metrics will be used to measure the work performed by the BA. It includes how to track, assess, and report on the quality of the work and take steps to correct any problems that may arise.

#Input
Business Analysis Performance Metrics : Actual performance measures are captured, analyzed, and become the basis for taking corrective or preventive action. Capturing actual performance metrics is a process that occurs through the business analysis effort and is implicitly a potential output from every business analysis task.

Business Analysis Plan(s) : These plans describe deliverables, activities, tasks, and estimates for all business analysis work. Conformance to these plans may be the primary metric used to judge performance.

Organizational Performance Standards : May include mandated performance metrics or expectations for business analysis work.

Requirements Management Plan : The requirements management plan may also set expectations for the frequency of changes to requirements and the work involved in managing that change.

#Elements
1. Performance Measures
Performance measures are used to set expectations regarding what constitutes effective business analysis work in the context of a particular organization or initiative. Performance measures may be based on deliverable due dates as specified in the business analysis plan, metrics such as the frequency of changes to requirements or the number of review cycles required, or qualitative feedback from stakeholders and peers of the BA. Appropriate performance measures should enable the BA to determine when problems are occurring that may affect the performance of business analysis or other activities, or identify opportunities for improvement.

2. Performance Reporting
Reports can be in written format to provide for archival and tracking, or they can be informal and verbal, based on the needs of the project. Some reports may be made formally and orally as presentations to various levels of stakeholders and management.

3. Preventive And Corrective Action
The BA should assess the performance measures to determine where problems in executing business analysis activities are occurring or opportunities for improving the business analysis process exists. Once this assessment is complete the BA should engage the necessary stakeholders to identify the correct preventive or corrective actions. Preventive or corrective actions is likely to result in change to the business analyst plan.

#Techniques
1. General Techniques

Interviews (9.14) : Stakeholders may be interviewed to gather assessments of business analysis performance.

Lessons Learned Process (9.15) : Helps identify changes to business analysis processes and deliverables that can be incorporated into future work.

Metric and Key Performance Indicators (9.16) : Can be used to determine what metrics are appropriate for assessing business analysis performance and how they may be tracked.

Problem Tracking (9.20) : May be used to track issues that occur during performance of business analysis for later resolution.

Process Modeling (9.21) : Can be used to define business analysis processes and understand how to improve those processes to reduce problems from handoffs, improve cycle times, or alter how business analysis work is performed to support improvements in downstream processes.

Root Cause Analysis (9.25) : Can be help identify the underlying cause of failures or difficulties in accomplishing business analysis work.

Survey/ Questionnaire (9.31) : Can be used to gather feedback from a large number of stakeholders.

2. Variance Analysis
The purpose of this technique is to analyze discrepancies between planned and actual performance, determine the magnitude of those discrepancies, and recommend corrective and preventive action as required. Variances can be related to planned versus actual estimates, cost, scope, product expectations, or any measure that have been established during the planning process.

#Stakeholders
Domain SME and End User : Should be informed of the performance of business analysis activities in order to set expectations for their involvement.

Implementation SME, Operational Support, and Test : Dependent on the effective performance of business analysis activities to perform their role. Should be consulted when assessing those activities.

Project Manager : The project manager is accountable for the success of a project and must be kept informed of the current status of business analysis work.

Sponsor : May require reports on business analysis performance to address problem as they are identified. A manager of BA may also sponsor initiatives to improve the performance of business analysis activities.

#Output
Business Analysis Performance Assessment : This include a comparison of planned versus actual performance, understanding the root cause of variances from the plan, and other information to help understand the level of effort required to complete business analysis work.

Business Analysis Process Assets : When the analysis of the performance of the business analysis work yields less than satisfactory result, it is helpful to review not only the result themselves, but also the process that produced those result. This process analysis often result in recommendations for improvement to the business analysis process. The revised process and templates for business analysis deliverables should be analyzed and documented and lessons learned should be recorded. These may be incorporated into Organizational Process Assets.

Next : Chapter 3 - Elicitation

Requirements Management Process (BA Planning & Monitoring)

Every project initiated with requirements. Gathering requirement is a tricky thing. Sometimes it is hidden at first, and show up in the middle or last. It might be not BA mistakes only, but also can come from clients. It is very important that every requirements should be managed and approved, or the scope will become wider. Previously we talked about communication, and now from the same source : BABOK, let's improve our knowledge about requirements management process.

2.5 Plan Requirements Management Process

#Purpose
Define the process that will be used to approve requirements for implementation and manage changes to the solution or requirements scope.

#Description
This task determines the appropriate requirements management process. It includes determining the process for requirements change, which stakeholder need to approve change, who will be consulted or informed of changes, and by extension, who does not need to be involved. The task also include assessing the need for requirements traceability and determining which requirements attributes will be captured.

#Input
Business Analysis Approach : The selected approach may include a definition of appropriate requirements managements processes.

Business Analysis Plan (s) : The business analysis plan define which deliverables are to be produces and when. Deliverables cannot be managed until they are created.

Organizational Process Assets : Standard templates or processes for requirements management within the organization may exist.

#Elements
1. Repository
A requirements repository is a method of storing requirements, including those under development, those under review and approved requirements. Repositories may include whiteboards, word processing documents, diagrams and model, wikis, requirements management tools and application, or any other method of recording information that allows requirements to be single-sourced and available to all relevant stakeholders for as long as they are needed.

2. Traceability
Determine whether and how to trace requirements based on the complexity of the domain, the number of views of requirements that will be produced, potential impacts from risk, and an understanding of the costs and benefits involved.

***Manage Requirements Traceability (4.2)

3. Select Requirements Attributes
Requirements attributes provide information about requirements, such as the source of the requirement, the importance of the requirement, and other metadata. The information documented by the attributes helps the team efficiently and effectively make tradeoffs between requirements, identify stakeholders affected by potential changes, and understand the impact of a proposed change.

Some commonly used requirements attributes include :

 --Absolute reference is a unique numeric (preferred) or textual identifier. The reference is not to be altered or re-used if the requirement is moved, changed or deleted.

 --Author of the requirement. If the requirement is later found to be ambiguous, the author may be consulted for clarification.

 --Complexity indicated how difficult the requirements will be to implement. This is often indicated through qualitative scales based on number of interfaces, complexity of essential processes or the number and nature of the resources required.

 --Ownership indicates the individual or group that needs the requirement, or will be the business owner after the project is released into the target environment.

 --Priority indicates which requirements need to be implemented first.

 --Risks associated with meeting or not meeting the requirements.

 --Source of the requirement. Every requirement must originate from a source that has the authority to define this particular set of requirements. The source must be consulted if the requirement changes, or if more information regarding the requirement or the need that drove the requirement has to be obtained.

 --Stability is used to indicate how mature the requirement is. This is used to determine whether the requirement is firm enough to start work on. Note that the ongoing presence of large numbers of unstable core requirements may indicate significant risk to project continuance.

 --Status of the requirement, indicating such things as whether it is proposed, accepted, verified, postponed, cancelled, or implemented.

 --Urgency indicates how soon the requirement is needed. It is usually only necessary to specify this separately from the priority when a deadline exists for implementation.

 --Additional attributes may include information such as cost, resource assignment, and revision number, traced-from and traced-to.

4. Requirements Prioritization Process
Requirements do not all deliver the same value to stakeholders. Requirements prioritization focuses effort on determining which requirements should be investigated first, based on the risk associated with them, the cost to deliver them, the benefits they will produce, or other factors. Timelines, dependencies, resource constraints, and other factor influence how requirements are prioritized.

5. Change Management
Some considerations when planning for handling changes are:

 --Determine the process for requesting changes. The process can, but doesn't not have to, set authorization levels for approving changes.

 --Determine who will authorize changes. The planning activity needs to include a designation of who can approve changes after requirements have been approved.

 --Impact analysis. Specify who will perform the analysis of such impacts as business processes, information requirements, system and hardware interfaces, other software products, other requirements, test strategies and plan, to name a few.

 --Plan the wording of the request. It is important to set the expectation at the beginning of the business analysis activities. The requested change must be expressed in unambiguous terms. Therefore, it will be necessary to discuss the nature of the request with the requestor and other interested stakeholders.

The requirements process needs to spell out the nature of the components within a request for change. These might include :

• Cost and time estimates of change :

• For each item, work product, or technical product affected, a brief assessment of the expected cost of change is to be estimated.

• The estimate will provide an integrated view of the costs, resources needed, implementation timeframe, and any dependencies.

• Benefits and risks of the change.

• How the change aligns with the project and business objectives to help ensure all changes add business value.

• Since there are often unintended consequences to what seems like a favorable change, the request should include a well-structured change analysis form (written or verbal), statements of the expected risks, including both negative and positive influence on project objectives. Benefits considered may include not only financial benefits, but also technical aspects of product features, influences on project scope, time, cost, quality, resources, and the business case.

• Recommended course of action for change.

• The course of action for the change needs to be explained with the understanding of benefits and risks in the previous section.

• The various options considered and the reasoning for the option finally selected needs to be recorded.

• The recommended course of action needs to be complete enough to permit clear coordination of the parties affected by the change.

• Update to the communications plan and the method for communication of the change to affected stakeholders.

• Configuration management and traceability discipline should establish product baselines and version control practices, that will clearly identify which baseline is affected by the change.

 --Coordinate Prioritization Of Change. The priority of the proposed change must be established relative to other competing interests within the current project phase.

6. Tailoring the Requirements Management Process
An organization's requirements management process may need to be tailored to meet the needs of a specific initiative or project. Factors in the tailoring process include:

 --Organizational culture. In organizations where the culture does not support formality, but where informality jeopardizes the end product, it will be necessary to work with the stakeholders to negotiate an appropriate process.

 --Stakeholder preferences. Some stakeholders may require more or less formality.

 --Complexity of project, project phase, or product (product, service or result) being delivered. Formal processes for configuration management and change management are more likely to be used for:

• Projects that have many interfaces, many business and/or system impacts or span a variety of functional areas.

• Products that are built with many components and sub-components, have complex interfaces, will be used by a variety and number of stakeholders, or have other complexities.

 --Organizational maturity. Less mature organizations tend to be less likely to want to spend time or money creating a requirements process, and there may be outright resistance to the idea of having a process to define requirements.

 --Availability of resources needed to support the effort of creating such a process is a major consideration. Internal groups, such as a Project Management Office and external sources such as consulting firms and even vendors may be able to augment organizational resources.

#Techniques

Decision Analysis (9.8) : Can be used to assess the possible value delivered by a change and assess areas of uncertainty.

Problem Tracking (9.20) : Used to track possible changes and ensure that a decision is reached.

Risk Analysis (9.24) : Used to identify possible risks associated with the change management process and possible risks associated with making or choosing not to make the change.

#Stakeholders

Domain SME : Consulted in order to determine the importance of requirements and to assess the value of change requests.

End Users : Consulted in order to determine the importance of requirements and to assess the value of change requests.

Implementation SME : Consulted in order to determine the difficulty of implementing a requirement or proposed change.

Operational Support : Informed of changes to requirements to ensure that the solution can operate effectively.

Project Manager : Responsible for managing changes to the project scope and accountable for delivery of the project scope.

Tester : Informed of changes to requirements to ensure that test plans are effective.

Sponsor : Accountable for the solution scope and must approve prioritization of requirements and changes to requirements.

#Output
Requirements Management Plan. A requirements management plan describe the:

• Approach to be taken to structure traceability.
• Definition of requirements attributes to be used.
• Requirements prioritization process.
• Requirements change process, including how changes will be requested, analyzed, approved, and implemented.

Next : Business Analysis Performance

Business Analysis Communication (BA Planning & Monitoring)

Communication is something that cannot be separated from business analysis. As a BA, we have to prepare and plan for communication method in managing business analysis activities. BABOK will tell us about how and when the BA will work with stakeholders.

2.4 Plan Business Analysis Communication

#Purpose

A business analysis communications plan describe the proposed structure and schedule for communications regarding business analysis activities. Record and organize the activities to provide a basis for setting expectations for business analysis work, meetings, walkthroughs, and other communications.

#Description

Planning business analysis communications includes determining how best to receive, distribute, access, update, and escalate information from project stakeholders, and determining how best to communicate with each stakeholder.

Considerations for the business analysis communications plan include:

• What needs to be communicated.
• What is the appropriate delivery method.
• Who is the appropriate audience.
• And when the communication should occur.

Stakeholder needs and constraints relevant to communication include:

• Physical location/ time zone of the stakeholders.
• Communication approach for the stakeholder.
• What types of communications will be required(e.g. status, anomalies, issues and their resolutions, risks, meeting results, action item,s etc.)
• What type of requirements will be elicited (business, stakeholder, solution, or transition; high level vs. details) and how best to elicit them (see the Elicitation KA for options).
• How best to communicate requirements conclusions / packages, including authority level (sign-off authority, veto authority, or review only).
• Time and resource availability constraints.

#Input

Business Analysis Approach : May include standards and templates used for communication, and expectations regarding when and how communication should be occur.

Business Analysis Plan(s) : Determintes when work will be performed and the deliverables that will produced, and which need to be communicated.

Organizational Process Assets : May include a defined set of templates for use in business analysis communication, including presentation formats, requirements documentation templates, and others.

Stakeholder List, Roles and Responsibilities : Used to identify the stakeholders who will require information regarding business analysis work, determine when information needs to be provided, and how a stakeholder is expected to use that information.

#Elements

1. Geography

The communications needed for a team that is collocated will be different from communications required for a project with geographically dispersed stakeholders.

2. Culture

Cultural diversity should also be taken into account when planning communications.

 --Relationship to time.

Some cultures view deadlines as firm commitments, while others may view deadline as a goal to be balances against other concerns and interest.

 --Relationship to task completion.

Some cultures complete tasks because they have committed to the planned activities. Others complete tasks primarily when trust and the human relationship have been built.

 --Relationship to contracts.

Some cultures believe in the letter of the law, others in the spirit of the contract. This difference might surface when creating Requests for Proposal, for example.

 --Relationship to formal and informal authority.

Some cultures prefer a centralized power structure where decisions.

3. Project Type

Different projects will necessitate different deliverables, and the extent of documentation that is need in a requirements package will vary depending on the project. Some examples are :

 --A new, customized in-house software development project. 

In this scenario, all requirements may need to be included.

 --Upgrading the technology or infrastructure of a current system. 

In this scenario, only the technical requirements may need to be included in the package.

 --Change in a business process or new data for an existing application. 

In this scenario, the process and data requirements, business rules,functional and technical requirements will be needed.

 --Purchase of a software package. 

This type of project will likely require a request. For Proposal, and the package will need to include the business requirements, technical requirements, limited functional requirements and other vendor specification.

 --Short, focused, agile style iterations of software development. 

Agile focuses on creating the minimum necessary of documentation to deliver the requirements, and many agile teams will prefer to document the solution after it has been delivered.

4. Communication Frequency

Investigates the frequency required by various stakeholder for each type of communication.

5. Communications Formality
Planning communications requires taking into consideration the level of formality that is needed.

Communication tends to be more formal under the following circumstances:

• The project is unusually large (by organizational standards) and will be delivered in phases.The level of communications formality tends to increase as the scale of project increases. This is because more stakeholders are typically involved and more communication is required.

• The domain involved is very complex. Note that the domain affected by the project may span departmental and divisional boundaries within the organization.

• The technology employed, if any, will be new, or new to the organization.

• The project is considered to be mission critical, in that it is tied directly to strategic objectives.

• The executive sponsor and/or key stakeholders require formality.

• The requirements are likely to be subject to regulatory review.

• The requirements will be presented to suppliers in an RFQ/RFI/RFP.

#Techniques

• Prepare Requirements Package (4.4)
• Communication Requirements (4.5)
• Communication Skills (8.4)
• Structure Walkthrough (9.30)

#Stakeholders
Customer and Supplier : Major customers of an organization or suppliers to that organization (particularly institutional customers) may need to b e informed of planned changes well in advance of implementation.

Domain SME : May be involved in review and approval.

End User : May be involved in review and approval.

Implementation SME : May be involved in review and approval.

Operational Support : May be involved in review and approval.

Project Manager : In a project, the business analysis communication plan will generally be integrated into the overall project communications plan.

Tester : Will primarily be involved in verification and validation of the requirements.

Regulator : Regulators may require that requirements, decisions, and other regarding the execution of business analysis processes or the definition of the solution be retained and made available to the for review.

Sponsor : Communication needs for the sponsor are likely to focus on business requirements and high-level stakeholder and solution requirements.

#Output

Business Analysis Communication Plan : Describes how, when and why the BA will work directly with stakeholders. Components can include :

• The stakeholder communications requirements for business analysis activities.
• Format, content, medium, level of detail.
• Responsibility for collection, distributing, accessing, and updating information.

Next : Requirements Management Process

Work Breakdown Structure / WBS Overview

WBS is a tool that used by Business Analyst in order to plan business analysis activities. Today I will share about some great articles about it from workbreakstructure.com and tutorialspoint.com. As far as I read, I found that this WBS is also used by Project Manager. I think both BA and PM should collaborate to create a great WBS. This post is just an overview, maybe I will update about this later.

Tutorialspoint :

#Introduction
Dividing complex projects to simpler and manageable tasks is the process identified as Work Breakdown Structure (WBS).

Usually, the project managers use this method for simplifying the project execution. In WBS, much larger tasks are broken down to manageable chunks of work. These chunks can be easily supervised and estimated.

WBS is not restricted to a specific field when it come to application. This methodology can be used for any type of project management.

Following are a few reasons for creating a WBS in a project :

• Accurate and readable project organization.
• Accurate assignment of responsibilities to the project team.
• Indicated the project milestones and control points.
• Helps to estimate the cost, time and risk.
• Illustrate the project scope, so the stakeholders can have better understanding of the same.

#Construction of a WBS
Identifying the main deliverables of a project is the starting point for deriving a work breakdown structure.

This important step is usually done by the PM and the SME involved in the project. Once this step is completed, the SME start breaking down the high-level tasks into smaller chuncks of work.

In the process of breaking down the tasks, one can break them down into different levels of detail. One can detail a high-level task into ten sub-tasks while another can detail the same high-level task into 20 sub-tasks.

Therefore, there is no hard and fast rule on how you should breakdown a task in WBS. Rather, the level of breakdown is a matter of the project type and the management style followed for the project.

In general, there are a few "rules" used for determining the smallest task chunk. In "two weeks" rule, nothing is broken down smaller than two weeks worth of work.

This means, the smallest task of the WBS is at least two-week long. 8/80 is another rule used when creating a WBS. This rule implies that no task should be smaller than 8 hours of work and should not be larger than 80 hours of work.

One can use many forms to display their WBS. Some use tree structure to illustrate the WBS, while others use lists and tables. Outlining is one of the easiest ways of representing a WBS.

#WBS Diagram
In a WBS diagram, the project scope is graphically expressed. Usually the diagram starts with a graphic object or a box at the top, which represents the entire project. Then, there are sub-components under the box.

These boxes represent the deliverables of the project. Under each deliverable, there are sub-elements listed. These sub-elements are the activities that should be performed in order to achieve the deliverables.

Although most of the WBS diagrams are designed based on the deliveries, some WBS are created based on the project phases. Usually, information technology projects are perfectly fit into WBS model.

Therefore, almost all information technology projects make use of WBS.

In addition to the general use of WBS, there is specific objective for deriving a WBS as well. WBS is the input for Gantt charts, a tool that is used for project management purpose.

Gantt chart is used for tracking the progression of the tasks derived by WBS.

Following is a sample WBS diagram:

#Conclusion
The efficiency of a work breakdown structure can determine the success of a project.

The WBS provides the foundation for all project management work, including, planning, cost and effort estimation, resource allocation, and scheduling.

Therefore, one should take creating WBS as a critical step in the process of project management.

...

Work Breakdown Structure :

#Overview

A work breakdown structure is a key project deliverable that organizes the team's work into manageable sections. The Project Management Body of Knowledge (PMBOK) defines the work breakdown structure as a "deliverable oriented hierarchical decomposition of the work to be executed by the project team." The work breakdown structure visually defines the scope into manageable chunks that a project team can understand, as each level of the work breakdown structure provides further definition and detail.

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

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

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

#Work Breakdown Structure Guidelines
The following guidelines should be considered when creating a work breakdown structure:

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

Business Analysis Activities (BA Planning & Monitoring)

Previously we talked about stakeholder analysis, now we will talk about business analysis activities. As a Business Analyst we know or we must plan about our next activities. BABOK is a good foundation to understand more about that business analysis phase.

2.3 Plan Business Analysis Activities

#Purpose
Determine the activities that must be performed and the deliverables that must be produced, estimate the effort required to perform that work, and identify the management tools required to measure the progress of those activities and deliverables.

#Description
The BA Determines which activities are required for a given initiative, how those activities will be carried out, the work effort involved, and an estimate of how long the activities will take. This task includes activities to :

• Identify business analysis deliverables
• Determine the scope of work for the business analysis activities
• Determine which activities the BA will perform and when
• Develop estimates for business analysis work.

#Input
Business Analysis Approach : Defines the lifecycle, deliverables, templates, and tasks that should be included. Plan driven approaches seek to define requirements as early as possible to reduce uncertainty, while change-driven approaches encourage requirements to be defined as close to implementation as possible.

Business Analysis Performance Assessment : The BA must use prior experiences on this initiative or on others to determine the effort involved in performing business analysis work.

Organizational Process Assets : The organizational standards and process assets in place may mandate certain deliverables.

Stakeholder List, Roles, and Responsibilities: Stakeholders will exhibit individual behaviors and preferences that may need to be met. Understanding their roles and responsibilities on the project will help to  determine how much those preferences will shape the plan. The role of each stakeholder must be understood so that the appropriate activities can be scheduled and the necessary time alloted.

#Elements

1. Geographic Distribution of Stakeholders
The BA must consider the physical location of key stakeholders on the same project.

 --Collocated : All key stakeholders are located in the same local geographic area.

 --Dispersed : These more complex projects have some key stakeholders located in different geographic regions or countries.

**If stakeholders are dispersed. It may be necessary to have more teleconferences or video conferences rather than face to face meetings.

2. Type of Project or Initiative
The type of project or initiative to which the BA is assigned may have a significant impact on the activities that need to be performed. Different kinds of business analysis initiatives include, but are not limited to :

• Feasibility studies
• Process improvement
• Organizational change
• New software development (in-house)
• Outsourced new software development
• Software maintenance or enhancement
• Software package selection

3. Business Analysis Deliverables
A list of deliverables is useful as a basis for activity identification. Methods are identifying deliverables include, but are not limited to :

• Interviews or facilitated sessions with key stakeholder
• Review project documentation
• Review organizational process assets, such as methodologies and templates, which may dictate which deliverables are required.

An organization may have a standard set of deliverables, or multiple sets that are used to support different approved methodologies. The breakdown of deliverables may also be dependent on the techniques selected by the BA, and may include deliverables such as interview questions, meeting minutes, use case diagrams, and descriptions, and as-is/ to be business process models.

4. Determine Business Analysis Activities
An important tool in defining the scope of work and in developing estimate is the work breakdown structure (WBS). The WBS decomposes the project scope into smaller pieces, creating a hierarchy of work. A WBS may break down the project into iterations, releases or phases; break deliverables into work packages; or break activities into smaller tasks.

**Click here for further information about WBS..

Work packages include at least one and usually many activities, which can be further broken into smaller tasks. This decomposition activities and tasks creates the activity list.

The activity list can be created in different ways, such as by :

• Taking each deliverable, assigning the activities required to complete the deliverable, and breaking each activity into tasks.
• Dividing the project into phases, iterations, increments, or releases, identifying the deliverables for each, and adding activities and tasks accordingly.

Using a previous similar project as an outline and expanding it with detailed tasks unique for the business analysis phase of the current project.

The elements identified for each activity and task may include :

• Unique Number to uniquely identify each task.
• Activity description labeled with a verb and a noun, and describing the detailed tasks that comprise each activity. For example, an activity might be labeled "Update Requirements Document".

In addition, it may include other information, such as :

• Assumptions : For each task, there may be factors or conditions which are considered to be true. The BA can document these factors, and where present estimates will be development using these assumptions.

• Dependencies : Identify logical relationships, such as which activities have to be completed before subsequent tasks can begin.

• Milestones : Represent significant events in the progress of a project. Milestones are used to measure the progress of the project and compare actual progress to earlier estimates. Milestones can be used as a time to celebrate the completion or delivery of a major deliverable or section of project work. An example of a major milestone is the stakeholders' and sponsor's formal approval of a requirement document.

#Techniques
Estimation (9.10) : A variety of estimation techniques can be used to produce an overall assessment of the amount of business analysis work required.

Functional Decomposition (9.12) : Decomposition of the tasks in a project (using a work breakdown structure) or product (using a solution breakdown structure) can be used to facilitate an understanding of the work at a sufficient level of detail to enable estimation of tasks.

Risk Analysis (9.24) : Identify risks that might impact the business analysis plan(s).

#Stakeholders

Customer, Domain SME, End User and Supplier : Domain SME's will likely be a major source of requirements and their availability is critical when planning activities.

Implementation SME : The implementation SME's may participate in business analysis activities in order to facilitate understanding of stakeholder needs.

Operational Support : May use business analysis deliverables  a basis for planning operational support activities or developing appropriate documentation.

Project Manager : In a project, the business analysis plan is integrated with and a component of the overall project plan.

Tester : Will need to know in what form and when deliverables will be produces as inputs into their own activity planning.

Sponsor : Must participate in the approval of business analysis deliverables.

#Output
Business Analysis Plan(s) : This business analysis plan(s) may include information such as a description of the scope of work, the deliverable Work Breakdown Structure, an Activity List, and estimates for each activity and task.


Next : Business Analysis Communication