MANAGEMENT YOGI

Monday, November 21, 2016

PMP Success Story: Don't Delay, Read PMBOK Thoroughly, and Get Your Certification as Early as Possible

By Divakar Eshwarappa, PMP

Introduction

My Preparation for the PMP exam started six months before the date of exam. I had completed the training many months before:). The general recommendation is to take up the exam within 3 months after your preparation training. I had no way to take it before this date, due to hectic office work. So, had to wait to schedule my exam date.

PMP Coaching Experience
Sometime in May 2016, the first thing I did was to go through Satya's notes & Videos and materials to recap the initial learnings. I was able to recollect many PMP concepts as explained by him in the class.

Satya is power house of knowledge when it comes to PMP. I had lost in touch with him after training. But kept receiving his mails on numerous write-up I was able to go through.

Own Study
I had read half of Head First PMP before taking the training. I took up this book next and started reading. As my office work was hectic, I could only study during weekends. Family with two kids, functions, festivals were all blockers for studies. I had a tough time balancing the study, work and family.

Meanwhile in July, I fell ill with Dengue fever and was completely hospitalised. I lost so much of time in recovering the health and that was very important.

When the month of August started, I was much better and was lucky to get my hands on Rita Mulcahy's PMP Prep book. The first couple of chapters was total bouncers. Her explanation of project management is at a different level. I could now recollect many points which we went through in Satya’s training when I correlated. I spent couple of hours after office hours every day to complete the book.

The month of August 2016 ended, but I had still had not booked the exam date, and had not read PMBOK® guide (highly recommended that you read multiple times) completely. Neither, I had practised 4-hour full length mock up tests.

So, I started counting the available weekends and festival holidays and planned my remaining studies. I came across ExamCentral.net site, which is very useful for mock tests and would recommend it for everyone. They give unlimited online mock-up test for free. The paid version has much more questions to offer.

In September, I got a remainder from PMI® to schedule the exam date or loose the one year timeframe / validity period to complete the exam. I used weekends to practise the full-length paper. I would start my day at 5AM in the morning and start studying. This gave me some confidence and hopes of passing :).

Mock tests, that I took:

Exam Central full length prep question
Oliver Lehmann online questions
Head First PMP’s 200 questions
Rita Mulcahy Book's questions

PMP Exam Experience
By end of September, I finally booked the exam dates for a morning slot. The D-day was set for 2nd November, 2016.

I spent whole of October reading the PMBOK guide and relating all the topics read so far in various books, all the question taken so far along with practising mock tests.

Exam Day: With my preparation, by the D’day of 2nd November, I had good confidence and by God’s grace was able to clear the exam. It was a long journey for me. But, I do believe it was all worth the effort.

Thanks to:
- Satya, for initial foundation through the training.
- ExamCentral.net for the free mock-up tests.
- My Family (for supporting me a lot and unlimited supply of Tea :))

Suggestions for PMP Aspirants

If you want to be an PMP, please take up certification as early as possible in your life and as soon as you are eligible. In later years, it will be very difficult.
Spend more time in understanding the concepts or ideas behind the process groups or knowledge Areas.
Taking mock up tests is a MUST, but just DO NOT go after every website or apps out there. They can be misleading.
PMBOK Guide - Must read and read as many times as you need to.

Brief Profile

Divakar Eshwarappa, Project Manager, Wipro Technologies

Book Available for PMP Exam:

New Book for PMP Exam Prep: "I Want To Be A PMP"

You may also like:

PMP Success Stories of Year 2020s
PMP Success Stories of Year 2010s

Friday, November 18, 2016

Book Available for RMP Exam Prep: "I Want To Be A RMP"

[NEW Book: I Want To Be A RMP - 2nd Edition (Link)]

Over the years, I've coached many professionals on risk management. While leading and guiding them, they have also taught me invaluable lessons about their needs, aspirations, expectations and the pain points they have in understanding the concepts of risk management. This book is a culmination of those learning with my students, fellow professionals and colleagues. A big thank you to all of you, who enabled me to write this book.

I've seen many professionals who want to crack the Risk Management Professional (RMP®) Exam, but unfortunately there is no book available which exhaustively covers the various aspects of the exam.

For the RMP exam:
A) you need to understand the principles, practices, and concepts in Practice Standard for Project Risk Management from Project Management Institute (PMI®);
B) you need to understand PMI's Project Management Body of Knowledge (PMBOK®) Guide 5th Edition with high focus on risk management processes, which comes with various inputs, tools and techniques and output (ITTOs);
C) you also need to be fluent with the Examination Content Outline (ECO), which is focused on performance domains. In addition, there is a list of reference books for the exam.

Unfortunately, there is no available material available, which covers them together.

Considering these, I have written this book - 'I WANT TO BE A RMP - The Plain and Simple Way to be A RMP'. This book exhaustively covers the needed areas to crack the RMP exam.

Top 7 Features of the Book - "I Want To Be A RMP"

Synchronised with the 5th Edition of the PMBOK Guide, PMI's Pratice Standard for Risk Management and the latest Examination Content Outline (ECO, 2016). Wherever needed, the concepts from the reference book list are covered, too.
Over 400+ practice questions for the RMP exam, including 2 full length question sets with detailed answers.
Exhaustive coverage with many examples on mathetical concepts such as

Earned Value Analysis (EMV),
Decision Tree Analysis (DTA),
Various Probability Distributions (PD),
Monte Carlo Simulation (MCS),
Latin Hypercube Simulation (LHS),
Earned Value Management (EVM) and Risk Adjusted EVM etc.

Many tips shared across the book to help crack the RMP exam.
Lots of diagrams and flow-diagrams to clearly understand the concepts on risk management.
Impact of Project Risk Management on other aspects of Project Management such as Scope, Schedule, Cost, Quality, Procurement, Communications, Human Resources, Stakeholders.
Real time examples on Risk register, Risk Probability and Impact Matrix, Risk Manageability, Risk Urgency, Risk Audit, Contingency Reserve etc.

Overall Content of the Book

Number of Chapters: 12
Number of Pages: ~500
Number of Questions: 400+
Number of Full Length Question Sets: 2
Two full length question sets, each with 170 questions and detailed answers (total 340)

The book exhaustively covers the areas for the RMP exam, but written in a simple way, with a number of examples related to our real lives - both professional and personal lives, where we do risk management.

To know the breakdown content of the book, please check the below index (partial one). The detailed index is part of the book.

Index of the Book

The partial index of the book is shown below (embedded document) You can scroll or open in larger screen by clicking the arrow on right in the embedded frame, to see the content.

If you are want to buy or have any queries on this book, please send a mail to managementyogi@gmail.com.

Reviews of this book:

You May Also Like:

Tuesday, November 15, 2016

PMP Protein: Understanding Risk Attitude

By Sindhu Sreenath, PMP, RMP

Risk attitude is an important concept in risk management. While taking the PMP® exam, you may expect questions on risk attitude and associated terms. Here, I’ll take an example on changing roles or jobs and relate it to the terms associated with risk attitude.

Through the course of our career, inevitably there comes a cross-section in our pathway requiring a choice in changing roles or jobs to pursue different goals and aspirations. The need to make this swap can be influenced by a number of factors such as the quality of work, the capacity of the deliverable(s), responsibility, pay, reputation and many other individually driven intangibles. But with each change we are faced with foreseeable and unforeseeable risks that can result in better opportunities or greater threats to existing responsibilities. Applying the concepts of risk management is imperative even though we do not realize that we do. And prior to our assessment it is important to understand the attitude we possess in our appetite for a new role, how much change we can tolerate and what threshold we are willing to withstand. Let's analyze each through examples associated with the constraints.

Risk attitude of a stakeholder is impacted by many factors and as per PMBOK® Guide 5th edition, it is broadly classified into three themes – Risk Appetite, Risk Tolerance, and Risk Threshold.

Risk Appetite: It is the degree of uncertainty a stakeholder is willing to take in expectation of a reward. In the light of changing roles or jobs, risk appetite can be defined by the need or desire for betterment in the workplace or career ladder, taking into account certain level or degree of uncertainty.
Example: You are willing to take up a new job that gives you more responsibility (the award) but might require you to work longer hours (the risk) due to meetings with team members located in different geographical locations.

Risk Tolerance: It describes the degree of uncertainty a stakeholder can withstand or tolerate. The differences between appetite and tolerance is that - tolerance will set a limit. In other words, compared to risk appetite, risk tolerance is more specific and measurable.
Example: You are willing to take up a new job that gives you more responsibility (the award) but might require you to work around 50 hours/week (the risk tolerance) due to meetings with team members located in different geographical locations.

Risk Threshold: It is the measure of risk exposure above which the stakeholder won’t accept the risk. It defines the stakeholder’s view on acceptable levels of risks. In other words, you can say, risk threshold is the highest level of risk tolerance. Below the risk threshold, the stakeholder will accept the risk, but above risk threshold, the stakeholder won’t accept the risk. In the context of changing roles or jobs, it will denominate the point until which certain factors regarding role or job selection are acceptable. Beyond this point, you won’t consider them.
Example: You are willing to take up a new job that gives you more responsibility (the award) but might require you to work longer hours (the risk) due to meetings with team members located in different geographical locations. You are willing to stretch yourself to a maximum of 50 hours/week (threshold).

Now, are you wondering where in project management these are listed? These will be part of the risk management plan, which you create as part of your planning. The risk appetite, tolerance and threshold may be revised as they are applicable to your project.

In your projects, you need to understand the stakeholders’ attitudes toward risks before you proceed with risk analysis and risk response planning. These parameters are also many times known as risk governance parameters.

Written by Sindhu Sreenath:

Sindhu Sreenath is an IT Professional & Product Technologist working with Intel Corporation, India as a Program Manager. She is a certified PMP from Project Management Institute (PMI). She has been applying Project and Program practices for over 4 years on managing Product Enabling teams and is now keen on developing her IT Product management skills. She has represented India in Rugby and has played Basketball and did Athletics for her state, at national level. In her spare time she enjoys Travel, Videography, Fitness and sports and is involved in several community and volunteering activities.She can be reached at Sindhu.sreenaths@gmail.com and her travel account can be accessed on Facebook or Instagram.

PMP LIVE LESSONS - Guaranteed Pass:

PMP LIVE LESSONS: Guaranteed Pass or Your Money Back

You may also like:

New Book Available for PMP Exam:

New Book for PMP Exam Prep: "I Want To Be A PMP"

Sunday, October 30, 2016

Introduction to Kanban, Kanban System and Kanban Development

[NEW: ACP Exam Prep Book Available - "I Want To Be An ACP" (Link)]

Imagine this situation: You have food items in your refrigerator. Some of them are running out. You figure out what items you need — when and in what quantity — and put sticky notes on the door of the refrigerator. Let’s call those “withdrawal cards.” As one of the items is running out, you pull off a withdrawal card and go to the nearest supermarket to replenish those items.

The supermarket manager also has a similar card system, which signals that those items are being emptied from its shelves. Let us call the cards used by the supermarket “production cards.” As the items fall below a certain limit due to withdrawals by customers like you, the store manager informs the supplier by this card. The supplier can check the production card sent, produces the quantity mentioned on the card, and has those items replenished in the supermarket.

If any other food item in your refrigerator is running out, you pull off another sticky note and follow the same process. The supermarket does the same with its production cards, and the supplier follows up.

Congratulations! With the help of signaling cards — sticky notes and production cards — you have just experienced “Kanban” and the “pull system.”

Concepts on Kanban and Kanban development are important to understand if you plan to prepare for the Project Management Institute’s Agile Certified Practitioner credential. Also, in the recently updated exam for the Project Management Professional Kanban has been introduced as one of the knowledge and skills in its exam content outline.

What is Kanban?

Kanban is a Japanese word for signal card, signboard, visible card or instruction card. Kanban signals are typically physical in nature, such as containers or cards, but they can take the form of a fax (“faxban”) or an email or even something web-based (“e-kanban). Kanban was first used by Taiichi Ohno on the factory floors of Toyota Motors. The Kanban system — so called because it uses Kanban – later became an integral part of Toyota Production System (TPS)1.

In our example, we have two signaling cards — the withdrawal card (the sticky note) and the production card. Because they act as signals for us, let’s refer to those signal cards as “withdrawal Kanban” and “production Kanban.”

Why would you and the supermarket use Kanban?

Kanban is used to reduce waste. Waste (called “Muda” in TPS) surfaces in several parts of the production process: overproduction, waiting, defects etc. However, one of the major sources of waste is overproduction, which happens when we produce more than what is needed or before it is needed. Kanban stops this waste, because the system is based on a pull system and has a just-in-time (JIT) approach.

Consider the typical “push” scheduling system. In this approach goods (inventory) will be pushed into the supermarket by the suppliers whether they can sell it or not. This leads to waste. If you’re using a push system in your home, you would stuff the refrigerator with food items (again inventory) whether you immediately need them or not. Sometimes, you may end up not even using those items, because you end up going out or leaving town or forgetting you have them.

Just in Time and the Pull System

In a pull system, unlike the push system, you (the “downstream” process) buy the items from the supermarket (the “upstream” process) based on a signal card — those sticky notes on the fridge. This we have named “withdrawal Kanban.” This approach is just in time because you’re getting the items as and when you need them and in the quantity that you need. It’s also a pull system, because you’re pulling the items from the supermarket as and when you need them. They’re not pushed to you from an upstream process.

Similarly, the supermarket (now acting as a downstream process) fills up on items given by the supplier (the upstream process) only when you and other customers have pulled the items from the supermarket’s shelves. The signal to produce is triggered by another signal card, the production card or production Kanban. The complete workflow for these steps is shown in this figure.2

This two card scheduling system is the Kanban system in its most basic form. The cards used in the system act as the signals and hence are known as Kanban cards (or simply Kanban).

A Kanban is literally attached to storage or a container and comes in the form of laminated plastic card. If the card is attached to the container and sent from a downstream center to an upstream center, then the upstream center will fill up the items in the Kanban tray (the tray to which Kanban is attached). Then it will send the tray to the downstream center. However, if an empty tray is coming without any Kanban, then the upstream center doesn’t send the filled up tray back.

The two card just-in-time/pull system with Kanban cards can be scaled to include other upstream processes, as shown below. Here again the downstream processes are pulling work items as and when needed (just in time) and the upstream processes are replenishing the items. This is also known as the “Pull-Replenish-Pull” system or “Replenish-Pull-Replenish” system.

Here we have put pull systems between processes (or work flow states) to give correct production instruction to the upstream process. Still in this system, some waste will be there — simply because certain inventory lies in the supermarket, which is inevitable. The ideal condition would be to have a continuous flow. That’s what is strived for in Kanban systems: “Flow where you can; pull where you must,” as Jeffrey Liker eloquently expressed it in his book, The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer.

The key takeaway here is that we visualize the work and work flow with the help of Kanban. Remember that a Kanban card is attached to a tray (or bin of parts) to move. Hence, primarily it is about visualization and taking action based on that.

Work in Progress

The number of Kanban cards tells the amount of items that are being worked upon — work in progress (WIP). Why? Because Kanban cards are physically attached to the Kanban tray; hence, they’re fixed in number or limited. By limiting the Kanban cards, we limit the work in progress and minimize overproduction and also minimize waste. Limiting work in progress, along with the pull system, also forces us to focus on the items needed by the customer and work only on them.

Managing the Flow

It’s possible that in the Kanban system there will be “work states,” when work items are being developed or processed, and “wait states,” when the system is idle. For example, when the Kanban tray is moving with an attached Kanban card, it’s in a work state. But when the food items are lying in the supermarket without being used by customers, they’re in a wait state.

By managing flow, we manage the work states and wait states and also find out if there are any bottlenecks in the system. This leads to continuous process improvement, called “Kaizen” in TPS.

So, here are the key characteristics of a Kanban system:

Just in time
Pull system
Visual management
Limited work in progress
Management of flow

Now, let’s cover how these can be applied in Kanban development for products, including software products.

Kanban Development

Kanban development mainly revolves around a visual board. This board is divided into various work flow states. These can be in a very simple form such as “to do” “doing” and “done.”. Otherwise, we can have multiple work flow states as they happen in software development: “analysis,” “design,” “development,” “testing” and “deployment.”

Also, in product development there can be many types of tasks or work items. For example, in software development they might be: new requirement, requirement change, critical issues, bugs, refactoring work, impediments, blocking issues, or documentation work. Each can be represented with various color codes or color coded spots on top of a plain card. You can also use various shapes for the cards: triangular, slanted, diamond. Each card is a Kanban card presented on the visual board. After all, visual management is one of the key aspects of Kanban development.

A sample visual board for Kanban development is shown below. I have kept it simple with one-colored sticky note (yellow) to denote one type of Kanban card depicting a particular type of work item. There are three work flow states — “TODO,” “DOING” and “DONE.”

The system shown above is pull, because the downstream process pulls the items from the upstream process and starts working. For example, items under “TODO” are pulled from the “Backlog of Items.” The work items are prioritized. This system, as we have seen before, also minimizes waste. You may say this looks very much like task boards used in other Agile development approaches. However, there’s a distinction — the WIP limits. On top of every work flow state, there’s a WIP limit, marked in the red boxes.

How do you know what the WIP limit should be? Through experimentation. The Kanban system itself doesn’t specify the limit; you have to figure out the right WIP limit for your system’s workflow states.

To manage the flow, you can add (or remove) wait states to the work flow states. Remember the quote, “Flow where you can; pull where you must”? This adds a certain amount of slack to the system, when continuous flow isn’t sustainable. In the figure below, a wait state — “Analysis” — has been added into the “TODO” workflow state to have some slack. From the “Selected” column under the “TODO” workflow state again we have flow. Of course, you can strive for continuous flow by removing unnecessary wait states.

There you have it. The basics of Kanban, the Kanban system and Kanban development. Now if you’ll excuse, I’m hungry. I need to go grab a withdrawal card.

Notes

1 The Birth of Lean: Conversations with Taiichi Ohno and other founders of TPS, written by Koichi Shimokawa and Takahiro Fujimoto.

2 Learning to See: Value stream mapping to add value and eliminate Muda, written by Mike Rother and John Shook.

This article was first published by MPUG on 19th July, 2016.

Pages