PMP Success Story: I Wanted To be A PMP And I Did It – My PMP Journey

By Vipin Kodiyath Radhakrishnan, PMP

‘I want to be a PMP®’ -I wanted to achieve this title quick and easy. But I realized nothing in the world that’s worthwhile ever comes easy unless you are focused and dedicated. One has to dedicate quality time towards sincere preparation.  


Perseverance is the key to achieve this title. 

I knew about PMP certification few years back and since then, I have attended 3 training sessions – first by my organization, second by Simplilearn and third by Knowledgehut. These I had to, primarily because my work commitment always took over and I postponed preparing for the exam and hence forget as long time passes in between.

Do not postpone your exam, schedule exam right after your training. If you procrastinate, you will never be ready for the exam.
 
Coaching Experience
Of the three sessions, I found Knowledgehut better, reason purely due to the trainer. Satya is one of the best trainers in this field. He has in-depth knowledge and very passionate about what he is doing. He is always ready to help no matter what time you call him. By the end of 4 days' training I was able to plot all 47 processes with little help. Lot of tips were shared throughout the training and these tips helped me during my exam preparation. 

Own Preparation
I blocked my exam on 28th October, 2016. I opted for 14th December, morning time. Until I blocked the slot, my approach towards the exam was very casual. Right after blocking the slot my approach changed. I was constantly thinking about exam, making plans, trying to find time during office hours to quickly run through few pages or attend few mock questions.
My actual preparation started just 3 weeks before the exam. I would wake up by 4.00 am and study for about 2.30 hours and again continue in the night for about 1.30 - 2 hours (mornings are the best time to study). Next 3 Saturdays and Sundays I was glued to my computer. 

Books I referred

• Satya’s book, “I Want to Be a PMP” -  read 3 times (a must buy book for the exam).
• PMBOK Guide once.
• RitaMulcahy’sExam Prep 8th Edition once.

I took couple of mock tests and I was scoring 70-80%.  

Mock Exams Attempted
I had planned to take minimum 1000 plus questions, but due to time constraint I couldn’t attempt all questions. Last 3 days I ran through the

• Exams from Satya’s eBook, “I Want To be A PMP”.
• ChristopherScordo’s book.
• Oliverlehmann
• Simplilearn
• Few questions from Rita’s.

Mock tests helped me identify weak areas. These tests also helped me think the way PMI does.
Mock tests had lot of ITTO related questions and I was not scoring well here. I spoke with Satya on it. Post speaking with him, I was determined that I am not going to let ITTO shatter my dream. Fear of failure and fear of unknown is the worst enemy which can shatter your dream and confidence. It is a good decision to connect with your mentor when you are confused and fear creeps in. 

The Exam Day
I stopped reading the previous night. I was totally relaxed and never allowed panic to set in. Ensured I leave early and reach the exam centre at least half-hour before the schedule. Please carry latest document where your signature is clear (if required practise to sign the same way before you leave for the exam). 

Questions I faced

• Lot of situational questions and most of them were word puzzles, long paragraphs intentionally written to confuse.
• Had few maths questions – questions on performance indices (SPI, CPI).
• Questions on Pareto Diagram, Deming’s life cycle, Ishikawa Diagram.
• Questions on Critical Path Measurement (CPM).
• Few ITTOs questions.

Dos and Don’ts

• Most questions are situational. Read and re-read the questions, if not clear.
• Please do not hurry in selecting the answer. Read questions properly and chose the correct answer.
• Eliminate the wrong once; this will help you in choosing the best answer.

Four hours passed by quickly. Finally, exam ends with a CONGRATULATIONS message. This is something you would want to see on your screen on THE day.

Satya’s ‘I WANT TO BE A PMP’ eBook
If you are serious with your certification and need a book which can help you understand every process and knowledge area for the PMP exam in simple and crystal clear way, then search no more. You should buy Satya’s “I WANT TO BE A PMP”eBook. 

I was the first person to receive Satya’s eBook. 

When I read through the first chapter, I knew this was the book I was searching for. Satya has well thought and compiled only what is required for the exam. I had read PMBOK and Rita’s PMP exam prep before going through Satya’s “I WANT TO BE A PMP”. One book is not sufficient and you may need to refer at least 2 or more books to prepare for the exam.

Unique features which I found in this book, but not available in other books are:

• This eBook contains lots of tips and tricks which are very helpful for exam preparation.
• Complex formulas are explained in simple way. Practise it once or twice and you will never need to remember the formulas by rote learning.
• You need not remember all ITTOs. Satya has marked important ITTOs in each process. Understand the marked once and that should be sufficient to answer all ITTO related questions.
• Book contains 3 sets of mock test; each set covers 200 Questions and Answers (Q&A). If you score 75% in Set 3 then you are ready for the exam. Also, at the end of each chapter you have multiple questions. Overall book contains more than 750 Q&A.

This eBook helps develop thinking the way PMI does.This eBook was my main study material and I believe I passed my exam because of this eBook. I had read this eBook 3 times.

Along with PMBOK, this eBook is a must read for all PMP aspirants.

Brief Profile: I work with 3i Infotech Ltd. as Senior Project Manager; I have over 14 years of experience in Product development in ERP and BFSI domains.  

PMP LIVE LESSONS - Guaranteed Pass:

• PMP LIVE LESSONS: Guaranteed Pass or Your Money Back

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

PMP Success Story: PMP Test is Not Difficult, If You Have Prepared Well

By Nutsa Datuashvili, PMP

Introduction
I’ve been planning on PMP® for last couple of years. However, only after I left my job to relocate to another country with my family, I was able to find time and prepare for the exam.

PMP Coaching Experience
I have had university level education in Project Management. But, I thought it would be best to refresh my mind, so I looked at the options available in the country I was living at that time. Nicosia University offered training on PMP. 

I really wanted to have a classroom training but ended up taking online course. Satya Dash was my coach for the PMP exam preparation, which frankly was very helpful.

My Own Study
I had 2 months of preparation. Last month I sat for 3-4 hours each day (exclusive weekends). I read Rita’s book 2 times - chapters and questions. I suggest you read the book twice. Do all the questions in the book. then every day do mock test. Analyze your results and revert back to book to understand wrong answers/gaps. Try looking up topics on the internet and reading further about those gaps. this was very helpful to me. 
    
Materials Referred

• Rita’s book
• PMBOK® Guide 
• Oliver Lehman’s mock tests

I didn’t have a plan until I scheduled the exam. But, after scheduling for the exam, everything got real. I chose the book to stick with, I wrote down a plan. 

My PMP Exam Experience
I scheduled at Nicosia University, Cyprus. I took the exam in November 2016.

I didn’t have any except I wrote down formulas and flowcharts – flowcharts deliverable flow, CR flow, data flow etc., which I had from Sayta. These I wrote down before starting the exam. I took couple of breaks, had water and chocolate at the end as I was getting exhausted :)

Frankly, test was not difficult. I remember doing mock tests which seemed much more difficult. Mathematical questions were very easy.

Suggestions for PMP Aspirants
- Dos:

• Have a plan/timetable and follow it. 
• Pay and schedule the exam in advance according to your plan.
• I strongly suggest you read relevant chapter after every training session.
• Do read Rita’s Book twice. 
• Mock tests are a must. 

- Don’ts:

• Do not procrastinate. 
• Don’t need many sources that will cause confusion.

Brief Profile: Nutsa Datuashvili, experience in construction and development, infrastructural projects, cultural heritage.

PMP LIVE LESSONS - Guaranteed Pass:

• PMP LIVE LESSONS: Guaranteed Pass or Your Money Back

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

5 Metrics for Agile Development

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

This article was first published by MPUG on 12th September, 2016. 

***

Let's say you were to meet gold medal winning sprinter Usain Bolt and say to him, "Here's a great track in front of you. You run. We'll monitor your running and declare you the fastest!" Would he run? His response would probably be, "Run against what?" If you said, "Just run, man! Don't worry about the distance!" would he listen to you?

Measurement, it seems, is inevitable and will be expected in many facets of life. In competitive sports or activities, measurement is used to gauge performance and prove who's the fastest or strongest. Judges measure against a baseline, such as 100 meters of distance, which is fixed and sacrosanct -- inviolable so that earlier World records or Olympic records will not be questioned.

But measurement in software development is different. Measurement isn't one developer against others. It's not about declaring someone as the fastest or cleanest coder or quickest bug fixer compared to others. Nor is anybody vying to break an existing organizational record. And baseline, while it should be respected, need not be sacrosanct. The idea of measurement in an unpredictable and complex environment such as software development tends to examine answers to these kinds of questions:

• What have we done so far?
• How far away are we from our current iteration goal and overall project goal?
• What are the areas of trouble in the development team's work? How the team can be helped to do better?
• Are we improving or what should we focus on for the team's improvement?
• Are we producing better products with fewer defects?

When it comes to agile development, specifically, those questions apply as well as one of the principles, as outlined in the "Manifesto for Agile Software Development": "Working software is the primary measure of progress."

But how do you measure that kind of progress? In this article I'll share five metrics and their requisite charts, which are important in agile development:

• Iteration burndown chart;
• Release burndown chart;
• Release velocity histogram;
• Cumulative flow diagram; and
• Iteration burnup chart.

To understand iteration, velocity and story points, I suggest you read my earlier post on the subject, "Understanding Project Estimation in Agile Development."

Iteration Burndown Chart

A burndown chart such as the one below shows the progress of the team in the iteration. (For Scrum, an iteration is called a "sprint.") Simply put, it's chart that shows the remaining cumulative work for an iteration.

The horizontal or X axis shows the number of days in the iteration; and the vertical or Y axis shows the number of remaining cumulative hours. To plot, start with the number of hours left in the day -- in other words, the total remaining hours. As your team progresses, at the end of every day, plot the remaining hours. Now draw a line connecting the two. Note that many times burndown charts tend to go up in the initial few days as the team may have underestimated or certain earlier unplanned tasks are added, but that need not be the case always. 

A variant of this chart adds baseline information, as shown with the dotted red line in the figure below. You may choose to include it if everyone is familiar with it. But if that isn't the case, adding the baseline may communicate misinformation that your team is doing less work than planned.

You might ask, "Should the non-working days in the iteration be shown?" If you do show it, you are likely to get a reverse S curve. 

Release Burndown Chart

The burndown chart can also be plotted for the release. The horizontal axis shows the number of iterations and the vertical axis displays the number of story points.

In this case we started with 300 story points – the total number of story points for the release. At the end of iteration one we have 270 remaining cumulative story points. If story points are added, then the curve will go up as it has happened for iteration four. 

Release Velocity Histogram

Velocity, as noted in my earlier post, is the sum of story points completed in an iteration. The histogram used to display this metric represents the velocity for each iteration in a vertical bar chart -- planned and actual.

Velocity may not remain uniform throughout the iterations in releases; hence, it's a good idea to show the stakeholders the trend for the last few iterations to give them an idea about what to expect in the future. You can communicate this by drawing over a mean line.

Here I show two types of velocity data: planned or committed velocity by the team and actual velocity. The dotted lines show the averages of the last 10 iterations.

Cumulative Flow Diagram

This flow diagram is cumulatively represented to provide insight into how many items are completed and where the bottlenecks are in the process flow.

In my example I've taken the cumulative diagram for the number of issues coming to the development team on a weekly basis. There are three workflow states: TODO, DOING and DONE.

Obviously, the TODO items are getting added up at a faster rate and becoming fattened, whereas the DOING items aren't able to catch up and flow through a narrower patch, indicating the presence of a bottleneck. Also the team can't seem to move the DONE items well either. From a technical standpoint, this suggests that either the items taken may be very big in size and hence needed to be broken up or that the team is unable to deliver on the issues taken up.

You need to be judicious while using cumulative diagram. It doesn't inform how big or small the tasks are. I've also seen people use a number of workflow states and have lower timescale on the X axis when a high number of issues are being worked upon on a daily basis. There it won’t add much value.

Iteration Burnup Chart

This chart is different from the burndown chart. Here, it's not about remaining cumulative work, rather cumulative work – planned and actual. In this chart, the X axis shows number of days and the Y axis shows number of hours. At the end of every day you plot the number of hours you've worked and connect those points.

Compared to a burndown chart, in this chart the scope changes are visible. If the project has big scope changes (also called "scope creep"), a burndown chart won't help. However, the burnup chart shows both the actual cumulative work done and the planned cumulative work, which, if there's scope creep, will show change.

As shown above, the planned hours started with 600 hours of work. That changed on day 4, where around 50 more hours of work (due to scope change) was added. Then on day 7 there was a scope reduction.

This chart communicates either internally or externally that scope creep is happening. By adding trend lines to it, you can show that if the creep it continues, the items taken for the current iteration won't be fully complete and will require some more time. Otherwise, you can request that the customer stop adding work if they want the features initially requested within the current iteration. Some practitioners don't advise change in scope within the iteration; the scope remains fixed, once the iteration has started. However, scope changes is a reality in many projects.

Final Notes on Metrics

Just as with iterations, you can have both a release burndown chart and a release burnup chart. Other charts I've seen in use are:

• Release burndown bar chart;
• Bug counts;
• Impediment counts;
• Impediments created vs. resolved;
• Bugs created vs. resolved;
• Predicting the end date with trend lines; and
• Combinations of these, such as release velocity burndown with bug and feature count.

Your goal as the project manager is to choose and use the metrics that primarily help your team identify problems and improve productivity.

To return to the running analogy, by using metrics, you're not asking your team members to run like Bolt. Rather, Bolt inspires us to try new things and to continue trying to get better every time we do it -- that is the idea of measurement and metrics.

The Agile Manifesto references this value: "Individual and interactions over Process and Tools."

While there's value in the item on the right (the italicized font), we value the item on the left more (in the bold font).

Metrics aren't there as a substitute for interactions with or among the team members. They're not there to identify which developer is good or bad. Metrics should move your team's path forward, make the development work better and help build valuable software.


Wish all my readers a Very Happy New Year, 2017. 

You may also like:

• PMI-ACP Prep: Understanding Project Estimation in Agile Development
• PMI-ACP Prep: Introduction to Kanban, Kanban System and Kanban Development
• 30 PMI-ACP Free Questions with Answers (Part - 1 and Part - 2)
• Changing PMI-ACP Exam in 2015: What is New and What Has Changed? (Part – 1 and Part - 2)
• PMI-ACP Prep: Agile Scrum - Sprint I/O (Inputs and Outputs)
• My Experience – PMI ACP Examination
• PMI-ACP Prep: Scrum and Kanban – Similarities and Differences