Sunday, May 26, 2019

Book Excerpt: I Want To Be An ACP, 2nd Edition - Problem Detection and Resolution



This post is in continuation of the earlier post on the availability of new PMI-ACP Exam Prep book: 
Book for PMI-ACP Exam Prep: I Want To Be An ACP, 2nd Edition

The excerpt is from Chapter – 7: Problem Detection and Resolution. This is one of my favorite topics. In my sessions as well I focus many times on these areas because your ability to solve problems will enable you to be a better agile practitioner. The excerpt here talks about Technical Debt and Cost of Change.



*********

Problems, impediments, risks, issues will come up during the execution of projects in agile development. It is natural. As a project manager, you would be already aware of it. But how you handle these issues, as compared to traditional environment, will differ.


As our first yogic quote says, problems will come, but you have to address them proactively – by identifying, prioritizing, and resolving. Also, you should improve your processes so that they don’t resurface.

In Agile, a strong focus is on minimizing the technical debt – a form of debt which if accumulates unattended, will have a high cost impact, when you try to change the system. Let’s take a real-world example. Many poor countries are poor because they took a lot of debt from outside bodies in their initial formation stages to build their countries, after being impoverished by colonial rule. Subsequently, due to bad fiscal management, poor governance and many times due to very high corruption, the debt kept on accumulating.  In fact, most of the yearly revenue generated by these countries goes into paying off the debts, which is euphemistically called “debt-servicing”. 

Real-world projects are similar. When you make a quick fix to meet a deadline or increase your delivery speed by cutting down the quality, avoid any form of documentation while coding, they lead to technical debt. And as is the nature of the debt – it never goes off, if you don’t work hard on it. Rather, it accumulates. When the debt reaches a very high level, you just can’t pay it off – because by that time cost of making those changes with respect to coding or documentation is going to be prohibitively high. Like our previous example with respect to countries, here, software systems or products developed with high technical debts are called as “legacy systems” – easier words in place of saying “unchangeable system”! 

In this domain, we see about cost of change, technical debts, impediments/impediment backlog, risk management; metrics to detect the problems such as lead time, cycle time, escaped defects and analyzing the variances and trends. We will also to see how to solve the problems that arise, the methodical steps to solve and various problem-solving techniques.

So, what this domain does? In simplified terms:
“Identify, prioritize and resolve problems, impediments and risks; Resolve and communicate status of them, have process improvement to prevent recurrence.” 

As per PMI’s Exam Content Outline, “Problem Detection and Resolution” domain has no sub-domains, but has 5 related tasks.



This domain, effectively, is about detecting the problems, visualizing the problems and resolving the problems.

Note: Going forward, I’ll be using the word “problem” as an umbrella one – for issues, threats, risks, impediments etc. Whenever needed specifically, I’ll be using the individual terms such as risks or impediments.

...
...

7.2 Creating a Safe Environment
The 5th principle in Agile manifesto says this:
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

You not only take motivated individuals in your project, but also give them the needed environment and support to succeed. Without a proper environment and associated safety, you just can’t expect the underlying/hidden issues or impediments to come up. This is why the first task in this domain is noted in the ECO as such.

“Task – 1: Create an open and safe environment by encouraging conversation and experimentation, in order to surface problems and impediments that are slowing the team down or preventing its ability to deliver value.”

As an Agile coach or manager, it is your job to provide the safe environment. Remember as a coach you also act as someone who guarantees safety? We have seen that earlier in Chapter – 5: Team Performance. A safe environment enables experimentation, failures and risk-taking ability. 


7.3 Detecting and Visualizing Problems   
Problems have to be detected early. The later they are detected, the harder they get to fixed and more importantly, the costlier it becomes to fix. There is a term, which notes this phenomenon – cost of change. 

7.3.1 Cost of Change 
Take the case of traditional development in waterfall model, which happens sequentially – from requirement analysis to deployment/operations. 

If a mistake has been made during analysis and it gets detected, then it is cheaper to fix. However, if the same mistake happens during the deployment or operation stage, then it becomes costlier (may be 100X costlier) to fixed. This is shown in the below diagram [3].


Simply put, cost of change is the cost involved to make changes possible in a system. As the time progresses, cost of change also increases – exponentially. 

The agile approach minimizes this exponential increase in cost of change. Here, we try to keep the cost of change as low as possible regardless of the point in the project’s life. The key idea here is this: a small change in requirement should result in a small change in implementation and hence cost. But, how does one do that?
  • Iterative approach: where we take a certain amount of work items (product backlog items) to be delivered in a small timebox. The work items are delivered just in time (JIT) fashion, without having high inventory of documentation or artifacts as in sequential waterfall development. 
  • Detecting problems and deficiencies early. And resolving them early too. In other words, keeping the technical debt – debt related to unclean code, low quality code, deficiencies in document - as low as possible. 
In Agile development, the cost of change is kept low. The inflection point – when the curve starts go up exponentially – happens early in sequential/traditional development. This is due to high upfront planning and a lot of documentation and hence high cost of change [3]. However, the curve is more flattened in agile as compared to the sequential because of JIT approach and keeping technical debt low. This is shown below. 



7.3.2 Technical Debt 
Like debt, which if not worked upon and allowed to keep on accumulating, can create serious financial problem, technical debt if not removed, makes it very hard to work with code. However, technical debt is not related only to code; other factors such as quality of code, development environment etc. can also come into play. 

Dan Rawthrone and Doug Shimp have defined technical debt in their book “Exploring Scrum: The Fundamentals”, which is noted below [21].  

“Technical Debt consists of deficiencies in the code, technical documentation, development environments, 3rd-party tools, and development practices, which makes the code hard for the Team to change.” 

Extreme Programming (XP) has been focused on producing clean code – code that the team can change easily. Technical debt is the one that prohibits in keeping the code clean. Also, as noted above in the definition, other than code, there are deficiencies which can also create technical debt.


Now, removal of technical debt is important as it helps in keeping the cost of change or flattening the cost of change, as seen in the earlier section of this chapter. 
If you plot the cost change with technical debt, the graph will come as follows. 

As the graph says, with low technical debt, the cost change remains pretty much flat over a period of time [3].





7.3.2.1 Types of Technical Debt
There are 4 types of technical debt according to Dan Rawthrone and Doug Shimp [21].  They are:
  • Lack of Tests: If the code isn’t tested, it will be very hard to change later. The developers working on the code later on to make the changes, will have very low confidence as the code has not been earlier tested. In fact, lack of tests, is the biggest reason for technical debt!
  • Bad Design:  Bad design happens when the code is structured in a poor way. 
  • Lack of Technical Documentation: Note that it is mentioned to be lack of technical documentation – not that you need to have exhaustive technical documentation. When a piece of code is written or changed, certain amount of technical documentation need to be there for the developers to understand. 
  • Poor Readability: These is primarily a piece of code which is difficult to read, popularly known as spaghetti code.

7.3.2.2 Preventing Technical Debt
There are ways to prevent technical debt. As the well-known saying goes: prevention is always better than cure. The ways can be:
...
...


*********

This chapter further explains on Risk Management in Agile environment covering: Risk Definition, Sources of Risk in Agile, Risk Management Workflow, Risk Probability and Impact Scales, Risk Map (Risk Grid), Risk Census, Risk Burndown Graph etc. Subsequently it addresses areas such as Impediments and Impediments Backlog, Metrics and Measurements, Cycle Time and Lead Time, Visualizing Problems with CFD, Escaped Defects etc.

Finally, it ends with "Resolving Problems", and "Problem Situations and Solutions", where many situational areas are covered and each one has been explained with possible solutions in addressing these problems. For example a problem can be: "too much complexity in product architecture leading to difficulty in estimation" with possible solutions such as "take a tracer bullet approach".

Some of the content in this chapter can be seen from the partial index of the book.


Book Available for ACP Exam Prep:

Monday, May 20, 2019

30 NEW PMI-ACP Free Questions and Answers (Part - 1)




These questions are based on feedback from many successful PMI-ACPs and my understanding of various Agile concepts. Some of the questions references the latest list of guide/books for the exam. The questions are primarily from the new book -  I Want To Be An ACP, 2nd edition. 

Questions in the PMI-ACP exam are mostly situational. You should have sound understanding of agile principles, values, practices as well as real-world experience to try out the questions. 

In this series, there are 15 questions, which you can try. I believe it will help you in your PMI-ACP exam preparation.

[This series - Part - 2] 



*********

PMI-ACP QUESTIONS (Part – 1)


Question – 1: You are working in a large industrial project to develop intelligent military devices. There are multiple Scrum teams working together. Your team is running daily meetings for every sprint. However, there is also need for representatives from each Scrum team to meet 2 to 3 times a week and synchronize the work for the Sprints completed. What team method or scaling method is MOST suitable for your project?
A Lean and Kanban.
B Scrum of Scrums.
C Large Scale Scrum.
D Extreme Programming.


Question – 2: You are working in a software development project which is following follow-the-sun model, where work is handed off at the end of every day from one development site to another due time-zone gaps. The entire team is following Scrumban method. Team members of one site had asked to have the burn down chart and velocity histogram is to be available to all. What should you do?
A Inform the team that it's not possible as the team members are geographically separated.
B Bring up the chart and histogram in the next retrospective meeting.
C Put an electronic information radiator with these charts within the fishbowl window.
D Assign a person to generate the chart and histogram and share with the site members.


Question – 3: An agile practitioner is leading a critical project to build a deep learning neural system. Several prototypes have been developed by team, but the top management is not satisfied with the results. In one meeting, the leader lost his cool and yelled at the team members for building useless prototypes, which are unable to satisfy management. Which one of the agile principles did the leader forget?
A Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 
B Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
C Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
D At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


Question – 4: Large scale scrum (or LeSS) is a scaling approach which uses Scrum, but with a large of number of teams at a larger scale. Which one of the following LeSS practices are similar to team based method of Scrum?
A Overall retrospective.
B Cross-team coordination.
C Cross-functional team.
D Overall Sprint Review.


Question – 5: You are negotiating for a contract with a prospective client. In the project high requirements churn is expected. Your organization has the domain expertise, but you are worried about the scope change and the client is also telling the price is fixed. However, the client agrees that if any higher priority feature is to be added in a future iteration, then the lower priority item has to be removed from the release plan. What should you do?
A Don't pursue this contract as scope is changeable, but prices is fixed.
B Ask for a premature clause for the contract closure, i.e., an early cancellation approach
C Propose a fixed price with allowed scope change contract
D Go for team augmentation approach with the client 


Question – 6: In a product backlog, there are 4 features shown below with cost of delay and duration. How should the product owner prioritize these features?

A Feature D will be of the highest priority.
B Feature C will be of the lowest priority.
C Both Feature A and Feature B will be of the same priority.
D Feature B will be of the highest priority followed by Feature D. 


Question – 7: Your team is working on an e-ticket reservation for booking flights and following a Kanban approach to development. The team has a board which has been divided into various workflow states such as Backlog, Selected, Develop, Deploy, and Live. What is the PRIMARY purpose of this board?
A To find the defects in the system and throughput.
B To self-organize and find out the bottlenecks in their workflow states.
C To create an expedite lane for high priority customer features.
D To visualize how features flow through a process and determine right work in progress limit. 


Question – 8: A product owner (PO) is prioritizing a list of capabilities, features, and stories considering various factors. While doing so, the PO notices that two items in the backlog can be completely eliminated altogether because these operation tasks are not needed. What factors did the PO consider for prioritization?
A Financial Value.
B Value and Risk.
C Cost of development.
D Knowledge gained. 


Question – 9: Your organization is building an Agile PMO as a center of excellence and help the agile practitioners engaged in various projects. Which one of the followings cannot be a service provided by the Agile PMO?
A Facilitate organizational learning.
B Create and maintain the product backlog of the teams.
C Ensure that teams’ work fits into the overall organizational strategic vision.
D Inform on compliance and amplify the teams’ external needs regarding compliance. 


Question – 10: You are working as an agile practitioner for a network hosting services project. A new stakeholder in a release planning meeting is unsure about this project and wants to know who benefits from this project and how they benefit. What should you do?
A Share the benefits management plan with the stakeholder.
B Request the stakeholders to participate in the iteration planning meeting.
C Send the project charter of the project to the stakeholder.
D Use the team charter to explain the benefit details. 


Question – 11: Your team is working on a smartphone project and has created a number of user stories which will be implemented over multiple iterations. Your sponsor wants to ensure that all possible scenarios addressed and have stories you would be likely to miss otherwise. He gives an example of how about the smart phone being used in very cold climate. What should you do NEXT?
A Use the 20:20 vision collaboration games.
B Specify requirements in form of executable customer tests.
C Consider using low fidelity prototypes. 
D Build extreme characters to get such type of users.


Question – 12: Your team is rebuilding an existing product for a client organization. Your client does not remember all the usages, pitfalls or lacunae in the product and hence asked you to actively participate with them while using the product. These will uncover the hidden requirements and hence build a better version of the product. Which innovation game will be MOST effective for this purpose?
A Me and My Shadow.
B Start Your Day.
C The Apprentice.
D Remember the Future.


Question – 13: A project team has been building a mobile commerce application product. The earlier version of the product didn't work in the market because of one particular reason - lack of customer empathy. The client organization informed that the earlier product built by individuals with good domain knowledge, but no real on-the-field experiences of users working on the product. If you were the leader of the project, what would you do?
A Build an exhaustive product backlog with fine-grained requirements.
B Involve users in the iteration planning meeting.
C Use innovation game of "The Apprentice" to have customer empathy.
D Ensure active stakeholder participation.


Question – 14: Your team is following Scrum framework for product development. Currently, you are documenting the roles and responsibilities for all the roles of your team including development team members, product owner and scrum master. You are using RASCI matrix for this purpose. Which one of the following roles will fall under "S" category?
A Development team members.
B Product Owner (PO).
C Scrum Master (SM). 
D Business owner and external stakeholders. 


Question – 15: You are the project manager for a mono-rail project in an organization, which has been following XP practices. Your sponsor wants to spread knowledge gained during the execution of the project and thinks knowingly keep one member at a reduced load, but keeping the overall team load will help in knowledge spread. This way you can also free-up a team member. Which XP practice will help you the MOST in this aspect?
A Slack.
B Team continuity.
C Pair programming. 
D Shrinking team.


The question set is available in the embedded document below. 

For all answers with detailed explanation, subscribe to this site and send a mail (from your GMail id) to managementyogi@gmail.com.




Wednesday, May 15, 2019

Book Excerpt: I Want To Be An ACP, 2nd Edition - Agile Principles and Mindset



This post is in continuation of the earlier post on the availability of new PMI-ACP Exam Prep book: 
Book for PMI-ACP Exam Prep: I Want To Be An ACP, 2nd Edition 

The excerpt is from Chapter – 2: Agile Principles and Mindset. 



*********


Agile Principles and Mindset is a new domain since the PMI-ACP examination changed in 2015. Note the wordings in the domain’s name: it is about principles and also mindset. Principles are like natural laws such as gravity, daily sunrise. They don’t change. Rather, practices underlying the principles change, e.g., waking up before sunrise or after sunrise. 
Next is mindset, which informs about a way of thinking, an established set of beliefs and attitude. For example, it may be your belief that waking up early makes your day’s work better. It may be true for you, your group or community, but may not necessarily hold good for another person or another group’s way of thinking and working. 

As mentioned in the earlier quote, you as an Agile Practitioner, should strive to be agile, i.e., follow the values, principles for Agile development and develop the needed mindset for it. 

In fact, an agile mindset is defined by the 4 agile values, guided by 12 agile principles and enabled by many practices such as servant leadership, iterative and incremental development etc. This is represented in the below diagram [9].



We will see about these 4 agile values and 12 agile principles shortly. These values and principles are described in the “agile manifesto”. Also, we will discuss various agile practices, as we proceed. Don’t get confused between the values such as human values like honesty, trustworthiness, integrity with agile values. Rather, here values mean certain core beliefs which agile practitioners came up with in 2001 after continuous practice. These values are basically “a set of understanding”. Combining them, you can say:
  • Agile Mindset: A way of thinking and behaving by the 4 values and 12 principles of agile manifesto.
  • Agile Values: A set of 4 core beliefs or understanding as documented in the agile manifesto.
  • Agile Principles: A set of 12 principles for agile delivery, which are also documented in the agile manifesto.
  • Agile Practices: A number of practices that agile practitioner use while doing agile delivery. 

The key concept behind this domain as per the ECO is this:
“Understand and apply the agile principles and mindsets within the project team and organization.”

This domain has no sub-domains. It consists of 9 individual tasks. 


What exactly are the tasks in this domain? The tasks, in simplified terms, are:
  1. Advocate for agile values and principles and develop an agile mindset.
  2. Ensure understanding of agile values and principles as well agile practices and terminologies.
  3. Support agile related change at the organization and system level.
  4. Practice visualization with information radiators.
  5. Ensure a safe and trusting environment.
  6. Enhance creativity by experimentation
  7. Share knowledge by collaboration and co-operation.
  8. Encourage emergent leadership, self-organization and empowerment.
  9. Practice servant leadership.

Following notations have been used in this chapter. 



2.1. Mapping with T&T and K&S
As earlier noted in “Introduction” chapter, every domain is sitting on top of a number of tools and techniques (T&T) as well as knowledge and skills (K&S). This domain does that too. It doesn’t have any subdomains, but has 9 tasks, which are sitting on multiple T&Ts and K&Ss. 


In this chapter, we will discuss the following T&T and K&S related to this domain. 




2.2. The Agile Approach
Many people confuse what the word “Agile” actually means, i.e., is it an approach or framework or methodology or practice or tool/technique? PMI’s Agile Practice guide uses the team “Agile Approach”, which is an umbrella term that covers a variety of agile frameworks and methods, e.g., Scrum, Kanban, Lean etc. Any framework or method that follows agile values and principles will fall under this umbrella term of “Agile Approach”.

To understand agile approach, we need to first understand what are project life cycles (and projects) are. Because, at the end of the day, agile approaches will be used in the project life cycle. 

2.2.1 Project Life Cycles
Projects are undertaken by an organization to create products or services or even results. The Project Management Institute (PMI) in the Project Management Body of Knowledge (PMBOK) guide defines project as below [9]. 

“A project is a temporary endeavor to create a unique product or service or result”.

There are many life cycles to project as per PMI’s Agile Practice Guide [9]. After all, a project will go through a set of stages to deliver a product. PMI defines a project life cycle as below. 

"The process through which a product is imagined, created, and put into use."

Every project will have a life cycle associated with it. At the end of a project’s life cycle, a product will be created.  There are four types of life cycles defined.
  • Predictive Life Cycle
  • Iterative Life Cycle
  • Incremental Life Cycle
  • Adaptive Life Cycle

2.2.1.1 Predictive Life Cycle
This life cycle is also known as “Plan Driven,” “Fully Plan Driven,” or as the “Waterfall Model.” The later term has been used in the last century mostly to refer to software development. The scope is known early in the life cycle, and you know exactly what the time needed and cost requirements are to deliver. In summary, this life cycle is used when the product to be delivered is well-understood.

In many projects; however, requirements and scope are rarely known in detail before the project begins. As details and finalized scope is not known in advance, you can’t have the time and cost known in detail either. And so, this leads to another life cycle – the iterative life cycle.


2.2.1.2 Iterative Life Cycle
Here, you deliver in iterations by progressively refining the product every step of the way. The concept of progressive elaboration fits in here. Progressive elaboration is basically an iterative process of increasing the level of detail as greater amounts of information becomes available.

Both the product containing unclear requirements and the plan having unclear estimates are progressively elaborated. The product is developed over a series of iterations – hence the name iterative. The detailed scope for the current iteration is only known at the beginning of the iteration. You incorporate the feedback from previous iterations into the subsequent iterations.

2.2.1.3 Incremental Life Cycle
In some projects, there can be complexities with respect to technology or the platform being used. Now, this is different from low agreement or lack of clarity on requirements. This is the case where the customer wants to have the deliverables quickly. 

Also, many times, it’s not important how well-refined your product is or how beautifully it’s done. Rather, the focus is on speed of delivery. In such cases, you can use the incremental life cycle.  Here, the delivery that you give to the customer can be immediately used and/or the product increment is potentially shippable

2.2.1.4 Adaptive/Agile Life Cycle
Our next cycle is the adaptive life cycle. It is also known as the Agile life cycle. Agile development is both iterative and incremental (or I&I), i.e., the work item is refined at the end of every iteration (iterative) and also delivered at the end of every iteration (incremental). 
. . .
. . .

*********

This section is further explained in the book with: 
  • What are the characteristics of these life cycles?
  • How uncertainties and complexities are considered via Stacey's diagram?
  • How agile makes a paradigm shift in management thinking?
  • Why agile delivers value early (single release vs multi-release economics)?
  • What are empiricism, empirical process and empirical process control?

It is further followed by Agile Values and Principles, Agile Project Management (APM), APM Framework, Information Radiators, Leadership types and styles in Agile, Various team based methods in Agile such as Scrum, XP, Kanban, DSDM, FDD, ASD etc and various scaling approaches such as Lean, SAFe, LeSS, DA, ES etc. Some of these can be seen from the partial index of the book.


Book Available for ACP Exam Prep:

Thursday, May 09, 2019

PMP Live Lessons Success Story: Stay Focused and Prepare Consistently to Succeed

By Shivakumar Viswanathan, PMP




Introduction
I wanted to take a moment to express my gratitude for Satya’s help and support in helping me pass the PMP® exam and gain my PMI® credentials. I kept studying on and off for a while but took an in-depth dive into the studies about 6-7 week before the PMP exam. 

Like Satya says – “It’s not a candy certification that would be handed over to all and sundry”. Indeed, it requires serious preparation and here is my experience with the process. 



Primary study materials
These were the three primary materials I used during the last 6-7 weeks.

Preparation Process
My primary course prep material was the "PMP Live Lessons" videos and the PMBOK guide. Anyone reading this might think, “Oh No! One more guy writing about the PMBOK guide. I can’t read that big 976-page tome!” Well, I’ll get to the PMBOK guide in a minute. 

The big plus point of the Live Lessons videos was that it felt like being in a private class with Satya - very informal, yet focused. I had done perhaps one full round earlier. 


In the last one month before the exam, I would have done perhaps 2-3 more full rounds of the Live Lessons. One round was going across the knowledge areas (KA) one by one and each of the processes in those KAs. The other round was going down vertically - down the process groups (PG). So, if I start with Initiating PG, I would watch the videos for Develop Project charter and then Identify Stakeholder processes. Next, I move on to Planning and go through the videos for the 24 processes and then move on to Executing, M&C and Closing. 

In a nutshell, if you take the 49-process table, one round of studying was horizontal row-wise and another round was vertical-column wise. I actually would have done 2 rounds vertical column-wise and 1 round of horizontal row-wise studying in the last 6-7 weeks. I also did additional rounds of the process flow videos that Satya was constantly updating and informing us via emails. Without trying to commit anything particularly to memory, I re-watched the process and document flow videos multiple times. I think that was crucial to get a good feel for what was happening among the PGs and KAs. 

I then went through the practice questions and the explanations. The PMBOK Guide is vast. It will bog you down because it’s heavy and dull. I’ll read a few chapters and give-up after reading. 

Hence, in the last 6-7 weeks I used the new approach while I was using with the PMP Live Lessons. I would, after finishing the videos for Initiating group, read the 2 processes under Initiating group in PMBOK guide. Likewise, for every process group, I would read the lessons under that group, straddling the various knowledge areas in that process group. An additional advantage of this method was that it helped in slowly grasping commonalities among processes within the Process group under the 10 KAs. With this approach, I found I was able to rapidly go through the PMBOK guide without feeling the full weight of the 976 pages to complete.


PMP Live Lessons Review
I found the lessons and practice exams at the end of the PMP Live Lessons chapters very useful to gauge two things: 
  • Understanding of the subject
  • Approach to answering the multiple-choice questions

To get the feel for the actual computer based simulation, I used simulator of Prepcast. But in terms of content, the “PMP Live Lessons” course is miles and miles ahead of other prep materials in the market. The sheer depth and breadth of the course coverage is by far the best I have seen. Even the Prepcast exam simulator comes with its own video lessons in the form of Podcasts. While it’s professionally produced, it would pale in comparison with the vastly superior content of Live Lessons.

I practised writing the 49 processes and list of mathematical formulae many times. I would take an A4 sized paper and write it. I practised writing the formulae for EVM, PERT estimations etc. many times.

It is also very important to know why a particular choice is wrong. In the exam, you may face a question with all 4 choices being correct. In that case, you are expected to choose the best among the 4. Understanding why a seemingly correct answer is to be discarded was helpful. 

Final Exam
I reached the Prometric center an hour before my slotted time. I started the exam and spent the first 5 minutes to write the 49-process table. I didn’t want to utilize any more time by writing a list of formulae. 

Exam Strategy and Approach to Questions
I’ve followed these steps during my exam.
  • I paced myself with a target of about 50 questions per 1-hour block. 
  • As noted earlier, I had written down the 49 processes to refer during the exams, which came in very handy. There were many questions which would ask to choose an answer which can be arrived at by merely referring to the table at hand.
  • For all 200 questions, I would first read the 2nd half of the write-up, which had the actual question. Next, I would quickly run through 4 choices and read the full question again. 
  • For some questions, elimination of 1 or 2 choices can be arrived at quickly. That itself raises the probability of getting the answer right. 
  • I had practised reading the question part with an emphasis on critical words during the simulation. 
  • For example: 
    • “…which project DOCUMENT should the Project manager refer?” or 
    • “…the project manager to do all of the following EXCEPT…”
      Reading the emphasized words loudly (in the mind!) helped. 

I took a 3-minute break during the exam, came back and continued at the previous pace and completed the exam. 

The message “Congratulations on passing the PMP exam….” was a massive relief coming at the end of studying for an average of 6-8 hours a day for the previous 6-7 weeks. 

I was able to score Above Target on 4 of the 5 process groups and On Target for the Closing group.

Conclusion
Thanks to Satya, and his really superb training material, PMP Live Lessons, I am now a certified Project Management Professional (PMP). I would highly recommend this material to any aspiring PMP candidate. 

I also want to thank Satya for responding to all my emails and clarifying questions. Every single email of my mine has been responded within 24 hours. That speaks of his professionalism and concern for his students. So, a big thanks to him again and again.

Brief Profile:
Shivakumar Viswanathan
I am based out of Toronto, Canada and in a transitional phase to move into full-fledged project management consulting.





Book  for PMP exam:
You may also like: