Press "Enter" to skip to content

Posts tagged as “project management questions”

5 PMP® Exam Studying Techniques

I obtained the PMP® certification on December 30, 2020. It was not an easy exam. And for those wondering whether my recent blog posts still have value for the January 2, 2021 update of the exam, they still do, just that the new exam both increases the priority of understanding agile concepts and applies a new content outline. I will account for the exam update in my future blog posts, and while the new exam is still based on the 6th Edition of the PMBOK® Guide, there is more emphasis (approximately 50% of the exam) put on the companion Agile Practice Guide. For more details, see the PMI website.

During my December studying blitz, I learned a lot more about how to take the exam besides what people recommended. The typical recommendation was:

  1. Take a prep course while reading the PMBOK® Guide and take notes
  2. Take practice exams
  3. Take the exam

This recommendation is still a great high-level approach to preparing for the exam. It’s just three things, so it should be a piece of cake, right? There’s also the recommendation that test takers should spend 60 to 120 hours studying for the exam. The factors that would help an aspiring certification holder spend less time studying are the following:

  • Having substantive experience in performing project management tasks from beginning to ending a project
  • Having decent experience at taking multiple choice question examinations
  • Having experience at a combination of consuming large amounts of knowledge and being able to repeatedly apply the knowledge practically

In this post, I am going to focus on the last point because I believe that passing the exam regardless of project management experience is about understanding the material covered on the exam. The main reason for this focus is that the exam covers its own guidelines and standards for how project management should be performed. I do not believe that every successful project manager applies these standards in the same way as the Guide prescribes, and practically, they likely never will. The certification proves more than anything else that its holder passed the exam. I believe that holding the certification has value, and it can shorten the conversation as to whether I understand various theoretical concepts and the possibility that I may know how to apply them in practice.

5 Techniques for Consuming and Applying Knowledge in a Practical Manner

  1. Create Outlines of the Guide’s Chapters to Break Down Information
  2. Take Notes Mirroring:
    1. the Guide’s Chapters
    2. the Exam Domains
    3. the Inputs, Tools & Techniques, and Outputs (ITTOs)
  3. Remap Notes to Identify Inclusion into or Exclusion from Topics
  4. Bookmark and Refer to Key Reference Tables
  5. Take Practice Exams to Improve #2 and #3 Approaching 100% Scores

1. Create Outlines of the Guide’s Chapters to Break Down Information

It was daunting to start studying because of the exorbitant amount of reading recommended. However, focus on that massive set of scope is not practical, and as test takers will learn in the Scope Management Knowledge Area, it is important to break everything down into simpler to understand parts.

There are thirteen chapters in the PMBOK® Guide, with the first three dedicated to general points about projects, project environments, and project managers, and the last ten dedicated to each of the Knowledge Areas.

Once the thirteen chapters are broken down, each individual chapter can be broken down by the headings used in each chapter. In the case of Chapters 4 to 13, which cover the Knowledge Areas, the Knowledge Areas can be broken down further into Processes before breaking down the Processes into headings.

When outlining the Processes, these are broken down by a few headings aside from the Inputs, Tools & Techniques, and Outputs (ITTOs), and I believe it is important to understand all of the headings in each chapter, not only the ITTOs.

For the new exam update, I recommend to outline the seven chapters of the Agile Practice Guide and each of the Domains, the Domains’ Tasks, and the Tasks’ Enablers.

2. Take Notes Mirroring the Guide’s Chapters, the Exam Domains, and the ITTOs

This is the hard part, but it’s worth it. Take notes. I recommend to any test taker to write them down, type them into a document, record talking about understanding of the concepts – do more than just read the book or watch prep course videos!

With an organized outline as described in #1 above, it’s easy to insert notes according to the PMBOK® Guide’s thirteen chapters (and also included in the new exam, the Agile Practice Guide’s seven chapters).

To make things a bit more complex, I suggest taking notes according to the exam’s domains as well. For the pre-“January 2, 2021” exam, this would be “Initiating, Planning, Executing, Monitoring & Controlling, Closing”, and for the January 2, 2021 exam update, this would be “People, Process, Business Environment”. This additional level of studying complexity ensures the studying is done according to what the PMI expects PMP® certificate holders to understand. In this blog post, I will not go over deep details of the domains, but it is important to break the domains down further. For the new exam update, Domains consist of Tasks, and Tasks are explained by Enablers.

Finally, to get much deeper into the processes, I recommend taking notes on the Inputs, Tools & Techniques, and Outputs (ITTOs) associated with each process. The new exam has a different focus in terms of outcomes in the questions presented, so I recommend downloading the 2021 PMP Exam Content Outlines provided on the PMI website, as it may be necessary to take notes more from the perspective of the Domains, Tasks, and their Enablers more than on the Processes and their ITTOs.

This studying technique can be taken into various directions by organizing the concepts in ways that I have not outlined here. I believe a good prep course will provide additional ideas on how test takers might choose to organize their notes.

3. Remap Notes to Identify Inclusion into or Exclusion from Topics

This technique builds upon #2 by better understanding what is and what is not related to a specific topic.

Here is an example involving ITTOs relating to Change Requests:

Key ITTO points – Change Requests

  • Inputs
    • Approved Change Requests:
      • Direct and Manage Project Work
      • Control Quality
      • Control Procurements
    • Change Requests:
      • Perform Integrated Change Control
  • Tools & Techniques
  • Outputs
    • Approved Change Requests:
      • Perform Integrated Change Control
    • Change Requests:
      • Direct and Manage Project Work
      • Monitor and Control Project Work
      • Validate Scope
      • Control Scope
      • Define Activities
      • Develop Schedule
      • Control Schedule
      • Control Costs
      • Manage Quality
      • Control Quality
      • Acquire Resources
      • Develop Team
      • Manage Team
      • Control Resources
      • Monitor Communications
      • Plan Risk Responses
      • Implement Risk Responses
      • Monitor Risks
      • Plan Procurement Management
      • Conduct Procurements
      • Control Procurements
      • Identify Stakeholders
      • Manage Stakeholder Engagement
      • Monitor Stakeholder Engagement

How did this mapping help me? It reminded me that there are processes that take Change Requests as inputs, and there are processes that produce Change Requests as outputs. This is just one of many ways to organize the ITTOs, and while there is no guarantee what specific questions will be asked on the exam, creating these alternative mappings helped me to better structure my understanding of different topics. Beyond Change Requests, I organized which processes did not include Enterprise Environmental Factors as inputs, and I carried out this exercise especially when I struggled to answer some practice questions correctly.

I believe a similar approach can be followed for the new exam outline, not necessarily relating to ITTOs, but on grouping information according to the exam outline and distinguishing what is and what is not included in certain Domains, Tasks, or Enablers.

4. Bookmark and Refer to Key Reference Tables

There are various reference tables in both of the Guides. In the PMBOK® Guide, tables that I found interesting to review regularly included:

  • Earned Value Analysis (which contains numerous formulas)
  • Organizational Structure Types (such as Functional, Matrix, PMO, etc.)
  • Project Management Plan components
  • Project Documents

5. Take Practice Exams to Improve #2 and #3 Approaching 100% Scores

This involves:

  • Taking a timed practice exam
  • Remembering which questions were difficult to answer correctly and noting which questions were answered incorrectly
  • Studying and taking notes on the areas related to the difficult or incorrectly answered questions according to #2 and #3 above
  • Retaking the same practice exam at a later time, repeating the process until scoring 100%
  • Taking a new practice exam much later to determine overall improvements in understanding of the relevant knowledge

Summary

These five techniques can help a future PMP® exam test taker absorb and work with the relevant knowledge, but using them still requires dedicating a significant amount of time. There are no shortcuts, but there are practical ways to make the studying process smoother. I hope these help.

Featured photo by Green Chameleon on Unsplash

The Project Manager – visionary, leader, role model?

The PM could do it all as a supervisor, coordinator, and contributor, but this depends on the project’s focus and the resources they have at their disposal. Within the constraints of their organization, they can do much more.

Contributor to the Product Vision: an anecdote

In several projects, I have acted as the supporting product manager to a key product manager usually when the key product manager’s main contribution is a very high-level concept of what they would like built. In effect, such a vision is so high-level that there is no way to execute on the vision at all without properly describing and breaking down that vision into understandable parts, including defining the outcomes desired. I was in effect a technical product manager in that I could transform the idea into a technology solution, and the person I was reporting to or was obligated to deliver results to was in effect a client or sponsor that was not expected to understand how to execute on their vision. I was the person “on the ground”. Different product managers may have different visions on their level of contribution required, so there is no single rule on how product management should work and how the project manager may take on any product-related responsibilities.

PMs and especially product managers can turn a big vision into a real product. Photo by Scott Graham on Unsplash

As a person, I am often among the stars, but when I am working on a project, I stay grounded because I understand that execution requires understanding the stars while creating traceability back to the earth. That is what I have done for my clients. The further out they are, the more work I have done either on my own or with business analysts to define and break down what they want. It is critical to be able to work with a vision in a structured manner to manage scope.

Leader of the People: an anecdote

Before they can manage expectations, the PM must first be able to understand the people they manage as well as the people they may interact with outside of the project team. By understanding the behaviors and motivations of each stakeholder (whether internal or external), the PM can determine how to utilize project team members and interact with senior stakeholders. A part of empathy that I did not experience until setting up my own business was what drove the people that I hired.

Before I dove into the PMBOK®, I didn’t need to know these technical terms for being a relatable and empathetic human being, but I will admit it is helping me to structure my thoughts better. I learned through hiring and firing how to care about people before caring about my own small business, and it was a costly yet very rewarding exercise.

Getting the balance between management and leadership techniques was not a cakewalk for me in my initial experiences as I lacked structure. I used both techniques but did not know when to optimize them. For example, there were times when I would focus on maintaining the status quo to get the job done without considering how this would prevent my team from developing. I lost some people this way. There were other times when I would focus on R&D that would help projects long-term, but this created a risk leading to slower delivery.

Managing Expectations

All of the moving parts at the people level are following some sort of expected process regardless of whether it is the optimal one for achieving delivery. This is a major reason why PMs monitor and control the project’s activities, firstly to ensure nothing is occurring that would contradict another stakeholder’s expectations, but also to ensure that what was expected is refreshed, adapted, and communicated as needed.

Once expectations are set, changing them is a matter of the flexibility of the team members and the mechanisms put into place to deal with certain risks. Photo by Campaign Creators on Unsplash

Managing expectations is like managing promises. If I make a promise, I should keep it. So if I communicate information that gives a senior stakeholder an expectation about delivering a certain set of scope on time, then I should have checked with the delivery team beforehand that they can meet that expectation. Once the senior stakeholder has that expectation, it’s my job to manage daily activities with the team so that their expectations are continually managed to meet the senior stakeholder’s expectations.

In an agile execution approach, the work might be carried out in iterations. If the team runs into a roadblock and cannot deliver what they expected, I will need to have planned for that risk in advance, and I should have communicated to the senior stakeholder that such a roadblock could have happened. Whether I’ve done that will usually depend on whether I could have known about that risk (either due to my experience or if it was a truly unique and improbable situation in the circumstances).

Maneuvering Madness

Understanding the culture of an organization enables a PM to know how politics and power can be used to achieve outcomes. There are several forms of power referenced in the Guide, but I will go over the ones that I have observed or related to more often than the others:

  • Positional – determined in relation to someone’s formal position, indicating a level of authority
    • if a VP has input to provide about a project’s status, and they have the authority to affect what happens next on the project, it’s important for the PM to recognize when others have this power to be able to exert their influence onto an authority when needed to achieve goals
    • at the same time, within a project team, the PM can refer to their authority when suggesting that certain team members should execute certain tasks
  • Situational – when power is acquired due to a unique incident
    • if there is a production incident, the PM might have the authority to require operational engineers (system administrators or DevOps in the software application context) to start or stop certain systems
    • where the PM lacks this power, they could exert their influence onto a senior stakeholder such as a VP to make certain decisions; this is important especially when the PM has more technical knowledge (and therefore has more Expert power) than the VP in the circumstances
  • Guilt-based – when others are led to believe they have an obligation or a duty to execute
    • “we’re running out of time, we’re going to miss the deadline” – this is a mixture of power being utilized here, but the PM may have to apply Persuasion, Pressure, and possibly Coercion to help push the delivery of a task, but at what cost?
    • likewise, if a VP reminds the PM that they signed up for satisfying the customer’s business needs at all costs, it may signal a need that vacation should not be taken if the PM is unable to delegate their tasks

Acting with Integrity

Although there are times on projects when it is important to exercise influence and power, I have found it equally if not more important to act with integrity – never to compromise the trust the stakeholders have in me, and if I make any promises, to keep them unless an exceptional circumstance arises that makes it impossible to keep the promise.

I weigh the upside and downside of “letting things fail”. While it is important to delegate ownership to motivated leaders or to take excess work from a higher-up, I make sure to manage risk first and foremost. If for any reason I have knowledge about an area a higher-up should have had, but they acted upon not having that knowledge in a way that could trickle down to the project level, I will capture it regardless of whether it was delegated to me, adapt it to suit our project (if possible), and push it back into the process. The same goes for subordinates – if there is an overflow, then I determine what the cost of failure is, and I’ll lend a hand to keep things afloat if needed. To me, part of integrity includes not compromising others’ reputations, so this can take a lot of work, but I believe it’s part of good leadership.

While being overly cautious is not advisable for the unnecessary inefficiencies sustained, being just cautious enough not to cause an irreversible and unexpected negative impact on a chain of stakeholders is the professional approach. Photo by Valentín Betancur on Unsplash

If risks are managed properly, the PM can maintain their and others’ integrity by keeping processes smooth without carrying out any unexpected actions. Letting things fail is an option only if it’s easy to pick things back up without causing unnecessary strain. If it’s the only option available to bring a project back to sustainability, then I would vote for it.

Keeping Eyes on the Prize

Integration Management ensures all of the gears of the project management machine are running, and while a good PM will keep them running, their focus should be on utilizing a few skills that are not in the Guide’s standard, but are in my own standard:

  • energy
  • dynamism
  • flexibility

The good news is, the Guide covers the need for continuous prioritization, being attentive to the project’s key constraints, being flexible, and being able to filter out key details from various types of artifacts and communication. For me, it requires using those three skills I called out in order to be effective at achieving these needs.

By keeping priorities up to date with a focus on accounting for the project’s critical success factors, I can optimize all of my activities and that of my team members towards getting the prize.

Questions that might pop up: technical project management, PM expectations

Which project element is least relevant to technical project management skills?

A. Budget
B. Schedule
C. Sponsorship
D. Risk

Recall earlier that I wrote about competing interests and objectives. One of those answers is not equivalent to a Knowledge Area, and one of them is just closely related to an existing Knowledge Area. I think that is a good enough hint.

Which statement is least accurate? Project managers should be able to:

A. Apply strategy towards maximizing the project’s business value
B. Explain the project’s strategy, mission, goals, products, competition, etc.
C. Be aware of relationships with other people to get things done
D. Take on responsibilities of unavailable team members during an incident

For other mock questions, read more posts from this tag. To learn more about my stories and my experiences as a project manager, get in touch. I have scratched only the surface in this post (and in the previous one).

Featured Photo by Kace Rodriguez on Unsplash

The Project Manager – supervisor, coordinator, contributor?

The project manager (PM)’s role varies depending on the organization’s structure, but generally, the PM is responsible for achieving the objectives of a project, noting that “a project is a temporary endeavor undertaken to create a unique product, service, or result”. Chapter 3 of the PMBOK® Guide goes into more detail about the role of a project manager. I will go over some theory, but I am more excited to explain some of the experiences I have had.

Outside of the five domains, the PM may be involved in pre-sales involving business analysts, experience designers, and architects in addition to post-delivery support or other strategy tied to delivering projects. As another example, a PMO may have project managers that are involved in reviewing and providing consulting for different projects in the organization at various stages, and they could also be involved in assessing the organization in general to enhance its performance. It depends on the organization and the value a PM can provide outside of a five-domains project setting.

Who is not the project manager?

It must have been a discrete math course I took in college that helped me better understand the value of this concept, but we can know what “A” is by knowing what “not A” is. There can be other managers within the organization, and understanding them might help to understand a project manager a bit better. One often referred to in PMP® training materials is the functional manager (FM). The FM manages a business unit. They may have individuals within business units that are lent out to projects and could have some budgetary discretion that impacts projects, but in that specific role, they are not known for managing projects. Then there might be an operations manager. If a project is temporary, an operation is intended to be ongoing. Operations managers ensure that business operations run smoothly – it might be that the project manager has been responsible for the creation of a product that is then used and possibly maintained by that operations manager.

In one project, I was the project manager for a product-service used by hundreds of external customers. I say product-service because while the customers used a web interface for placing product orders, that product had to be put together in the form of an operations team gathering internally and externally sourced data, packaging that data into reports, and finally delivering them to the customer. That operations team would be run by an operations manager, but I was the project manager involved in improving that software. I interacted with various other managers as well, including the software’s product manager and sales managers.

I would also attend meetings with higher-ups who were in effect different senior functional managers that had oversight over the project manager, operations manager, and product manager, respectively. The person overseeing me was a director of project management, the operations manager a director of operations management, and so on. That was good to know, and it made life easier understanding what each person’s responsibility was, and where I fit into the picture.

The master supervisor and coordinator within the project

The project manager is involved in the management or execution of all of the project management processes depending on the stage of the project. Overall, they are delivering the project according to the agreed scope, schedule, and cost (alongside the other knowledge area components) with the aim of meeting the stakeholders’ needs according to critical success factors. They may be supported by various project coordinators along the way, depending on the size of the project. These coordinators will help to execute various aspects of the overall project’s processes, where the PM will oversee and ensure that all of these moving parts are working smoothly. As will be covered in the Initiation stage of the project, project managers Develop the Project Charter and Identify Stakeholders, though they may do this in assistance with other team members such as business analysts.

The PM never does it all alone, and they will be watching over and coordinating between various individuals along the way. Photo by Dylan Gillis on Unsplash

Juggling the various people, processes, and technology involves balancing a diverse set of competing interests, and this means managing the expectations of many different individuals. I wouldn’t want to trip up while performing my act, but a leader knows that when working within scarcity, priorities must be set. They might have to set down one of their juggling props during parts of the act to deliver a standout performance. Once priorities are set, the PM should manage every stakeholder’s expectations as to what those priorities are and minimize any risks or conflicts. More than ever, this post I wrote in 2013 makes more sense – although we’re still figuring out how to achieve global consensus, it is more possible at local levels, or in this case, the project level. A well-managed project can have the appropriate accountability, governance, and transparency to achieve consensus. Before I go on a tangent and talk about democracy (which I do enjoy discussing!), let’s get back to juggling.

As the master coordinator, the PM must be an excellent communicator making use of their soft skills to ensure the project’s goals are met and that value is delivered in the process. This involves managing various activities, the synchronization of people to align on variable-term objectives, and the execution of tasks towards achieving the goals. According to the Guide, PMs spend up to 90% of their time communicating, and I would have to agree. Before studying the Guide, I had a more conservative prediction that it’s about 75% of their time. The standard’s 90% validates what I have generally considered as the truth: communication is critical to getting any job done let alone achieving any real outcomes in any initiative. Whether it is a successful friendship, relationship, trading partnership, or anything that requires good reciprocity, including a project, communication makes it possible.

A good PM will make the effort to get to know their team members and set up a culture around applying productivity-focused communication techniques. Photo by LinkedIn Sales Navigator on Unsplash

Even outside of the project, the PM may have to engage in higher-level meetings in which they are not the key manager. For example, a program manager (PgM) may run the program in which the PM is just one of many project managers involved in the program. In this case, the PM may be engaged in discussions ensuring their project’s needs can be met through securing and sustaining people, budget, and other resources they need to get their project done. They will also be involved in clarifying or reporting that their project is in alignment with what is occurring within the program or above to the portfolio or organization level. The communicating never ends, and while I believe communication is positive, it can be quite the drain especially if the patterns are not optimized. “I was just in four back-to-back meetings… what did I sign up for?” Project management, possibly.

How I coordinated: an anecdote

Strong Matrix

Where I have acted as the PM within a strong matrix organization, it’s certainly the case that while I had to juggle the complexities of activities and people within the project, I had to do that while ensuring my higher-ups were happy with the progress of the project. It’s one thing to lead my immediate team in understanding the scope of what they have to work on (typically delegated to a business analyst) and ensure it’s developed according to the relevant testing strategy before the work is made live. It’s another to deal with the plethora of other competing objectives involved when doing the work.

Scope as a Competing Constraint

The product owner (PO) might want certain features to be delivered even if the execution methodology would not allow us to be that efficient. I may have to consider whether to overutilize resources, which could make the team upset about not having a reliable work-life balance. In some cases, I would have to consider whether to justify slower delivery even if in some cases the resources may have made mistakes. In other words, there were so many ways to lose, but I was responsible for balancing all of this and deciding what would happen next. Trying to solve this problem is all part of the fun!

Resources as a Competing Constraint

During a senior leadership meeting, I received feedback about having to decrease the number of team members, and this required that I assessed within the project what was best given that I could not negotiate to keep the same number of team members. It is not always the case that the best contributor is the best team member, but sometimes the project’s timeline might not be able to afford inefficiencies.

Technology as a Competing Constraint

The technology and architecture leadership may indicate that the corporation is switching to a new framework that must be adhered to within six months to comply with the agreed IT security policy, but this would cause a major increase in the workload which would certainly cause feature delays. It is possible I could use this information to try to retain the team I thought I was going to have to reduce, and if I am lucky, I could secure an additional team member to help streamline some of the product feature delivery, too!

Risk as a Competing Constraint

I had to take all of this into account, and in situations where risks shift towards one area or another, I have had to keep my eyes and coordination more in that area if the risks were not already managed by or transferred to someone else outside of the project team.

It’s better to manage all of the risks rather than to step on them barefoot. Photo by Xavi Cabrera on Unsplash

Part of the trick in being a project manager is not only juggling but in getting it all done while running across a tight rope. If I have set up a decent foundation, there will be a large mat on the ground to catch us when we fall in the form of highly supportive team members and supervisors.

Negotiations: Figuring out whether we can get to a win-win

In numerous projects, especially the ones that had multiple product owners, I would have to get in the middle of a prioritization battle to determine whose feature was more important to deliver on time. That battle can be won by getting creative and figuring out how to give both of them what they want without sacrificing the product’s quality, but that can’t always happen. There might be stakeholders who are not at the same level, and that can be difficult as well.

The business stakeholders might want to drive value out of the product and its use by customers, but the operations stakeholders might be suffering because of issues with the product such that throwing more people at it might not stop the flood. Or the program manager just wants to deliver the project on time with as much baseline quality as we can deliver, but the product owner will be disappointed if certain enhancements can’t be delivered despite being forecasted for delivery on the product roadmap.

If the PM can get agreements on scope prioritization to benefit multiple stakeholders, it’s getting the project one step closer to a smoother completion. Photo by Gabrielle Henderson on Unsplash

Beyond communicating with the stakeholders to ensure everyone would be in alignment, I made sure that any action I would take would create value not just for the client’s business but also for my higher-ups. The projects or products I worked on would affect company reputations. In one project, I knew that my success on it would lead to further income streams for the account, so I put in an inordinate amount of effort that was not planned in the budget. I did this beyond my role as just simply a PM, taking it further as a driver of business and sales credibility. I loved every minute of it even during the tougher times!

I have a few more stories to tell, covering product vision, the differences between leadership and management, and influence.

Question that might pop up: leadership style

I have seen variants of these questions around, and I have created my own variants. They are by no means exactly the ones that will pop up on an exam.

What is the leadership style when the leader is hands-off?

A. Servant leader
B. Interactional
C. Laissez-faire
D. Charismatic

My hint is that it’s mostly related to unfettered capitalism as expressed by Adam Smith (the answer is here).

For other mock questions, read more posts from this tag. To learn more about my stories and my experiences as a project manager, get in touch. I have scratched only the surface in this post (and in the next one).

Featured Photo by Karla Hernandez on Unsplash

Mission News Theme by Compete Themes.