Products without security risk becoming irrelevant. Projects lacking governance to comply with organizational security policies will find themselves unable to operate. A Software Development Life Cycle (SDLC) that accounts for security only in the testing, or worse, just after deployment, is increasing the risk of the occurrence of and the cost of fixing exploitable security vulnerabilities. Despite the normalcy surrounding cyberattacks, the unacceptability of them remains at a critical level.
My academic training in security dates back to 2006 when I studied Information Assurance and Security, and my practical experience dates back to 2000 when I regularly released software to the public. Every time I published a release, I thought about all of the “hacked” or “cracked” versions of popular competing software. While my product was widely used, it did not get hacked in any notable manner because I added encryption and anti-decompiling mechanisms into the software prior to release. Additionally, I included multiple authentication mechanisms including serial key distribution to control the use of the software by authorized individuals. While sophisticated hackers would have been able to bypass these controls, I made the work more difficult. Making the work more difficult is the key.
Information Security and the Secure Software Development Life Cycle
The next set of blogs will cover two important security areas: Information Security from the perspective of overall information systems security management, and the Secure Software Development Life Cycle (Secure SDLC). It is important to note: there is no such thing as 100% security. There is always a way to affect the Confidentiality, Integrity, and Availability of a system. The important consideration is whether the defender of a system is doing what they can to make sure attackers have a very difficult time accomplishing their goals to the point that the risks to the system are minimized and actions can be taken to prevent catastrophic consequences. As I had done with the PMP® exam, I will go through concepts and details helpful for taking the CISSP® (the gold standard for information security just as the PMP® is for project management) and CSSLP® (for Secure SDLC) exams.
A product is not by definition temporary, but if it’s decommissioned/retired, then it’s over. A product exists to solve an ongoing business need or want. If there is no need nor any want, then there is likely no product (worth sustaining).
A project is a temporary endeavor undertaken to create a unique product, service, or result. I would take it further and say this is undertaken taking into account one or more business cases.
The software development life cycle (SDLC) is often part of product development generally (where there’s software to be made as part of a product life cycle) and the project life cycle (especially planning through the end of execution, which includes monitoring & controlling).
The SDLC is a process for delivering software and is commonly known as consisting of the following phases (or some associated variants):
Analysis – understand what should be made to achieve the relevant goals (business need or want)
Design – determine the way in which the implementation should be done so that it is sustainable
Implementation – make it
Testing – make sure it works as expected
Deployment – get it out to the relevant environment
Maintenance – keep it running and resilient
The development methodology selected will determine when any of the above phases of the SDLC are active. The ones I have worked with are waterfall and a few agile variants (Scrum, Kanban, and XP). I will not go into detail on these methodologies in this post.
How are products, projects, and software development related?
As my role has often been a mixture of project manager and product manager, I have seen how my involvement in the product vision ends up affecting the delivery of project outcomes resulting in the desired product.
For product management, I refer to the phases referenced in the ProdBOK® maintained by the Association of International Product Marketing and Management (AIPMM):
Conceive – generate and prioritize ideas prior to putting in product planning efforts
Plan – define the product more clearly by covering experience design and other market validation to ensure this product is worth developing
Develop – build the product according to the plan with deliverables and beta preparation
Qualify – conduct beta testing through select external users to refine the product and prepare for the launch with relevant marketing and sales training
Launch – get it out there with the appropriate messaging and acquire users
Deliver – scale the product to maximize opportunities and increase sales
Retire – take steps to end support for the product including preparation of any necessary license terminations or documentation on migration to other products
For project management, I refer to the domains referenced in the PMBOK® Guide maintained by the Project Management Institute (PMI):
Initiate – get buy-in and approval to progress
Plan – detailed analysis of the scope, schedule, cost, and other variables that will affect the final outcome of the project
Execute – deliver the outcome according to the plan
Monitor & Control – take relevant steps to ensure execution is going according to plan
Close – wrap up once the project outcome has been achieved (or some other event happens that ends the project)
From my experience the way this would work conceptually (taking into account what I said about the development methodology above) is as follows:
I have seen that according to the Optimal Product Process™ that “Launch” and “Deliver” (or Maximize) are not traditionally associated with the SDLC, but I don’t believe there is a hard rule suggesting that they do not apply in those two product life cycle phases. There are numerous professional perspectives on how the overlap works, and all of them are valid in different contexts.
In my product perspective, which is focused on non-stop momentum and sustained value delivered to customers, there should be continuous software delivery without unreasonable stoppage until the product is set to be decommissioned or retire. That includes continuous delivery during the Launch and Deliver phases where necessary.
Additionally, regarding “Deployment” and “Maintenance” in the SDLC, it’s entirely possible that there is not much to consider in a “pre-production” (Pre-Launch) phase of the product, but I believe they still apply whether we are in pre-prod or prod due to how the development operations may be set up.
To recap, when “doing the work” to get the product made, many projects can take place to build and improve the product throughout its life. If we are talking about software and in an agile development context, then the phases of the SDLC will take place throughout this building and improvement of the product typically in scope of one or more projects. The level of formality and process strictness applied depends on the standards applied by the relevant product, project, and delivery managers. Business analysts will often have a role to play in all three distinct life cycles to bridge the relationship between the three.
There is no one-size-fits-all approach in managing desired outcomes for a product or project, though I am generally a proponent of applying lean practices to focus on results over process.
The difference is clearer, so how does the SDLC work?
I will cover more about the SDLC and the associated development methodologies in another post.
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:
Take a prep course while reading the PMBOK® Guide and take notes
Take practice exams
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
Create Outlines of the Guide’s Chapters to Break Down Information
Take Notes Mirroring:
the Guide’s Chapters
the Exam Domains
the Inputs, Tools & Techniques, and Outputs (ITTOs)
Remap Notes to Identify Inclusion into or Exclusion from Topics
Bookmark and Refer to Key Reference Tables
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
Approved Change Requests:
Direct and Manage Project Work
Perform Integrated Change Control
Tools & Techniques
Approved Change Requests:
Perform Integrated Change Control
Direct and Manage Project Work
Monitor and Control Project Work
Plan Risk Responses
Implement Risk Responses
Plan Procurement Management
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)
5. Take Practice Exams to Improve #2 and #3 Approaching 100% Scores
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
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.
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.
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.
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.
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).
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.
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:
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).
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.
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.
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
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.
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.
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).
All of the EEFs and OPAs influencing a project and the extent to which they influence the project is dependent on the organizational systems within the organization. In order to delivery the project successfully within this dependency, the project manager must understand how accountability, authority, and responsibility work within the organization. Without having various competencies to maneuver through the organization smoothly, the project manager will have a difficult time getting things done.
The interaction between management approaches, governance frameworks, and the organization’s structure will all determine what competencies and role someone should have in order to be effective within the organizational systems.
Getting theoretical with systems
I am reminded of Niklas Luhmann’s systems theory, which is an elaborate analysis of various systems including organizations. He would compare different structures with varying formality especially to understand each structure’s ability to adapt within the wider system that it exists. Every structure has its own attributes that enable it to understand itself in order to simplify its operations. A structure that becomes simpler allows objects within that structure to operate more effectively and efficiently.
Taking Luhmann’s theory and extending it to project management, depending on the formality of an organization, a project manager will understand the organization in a certain manner to know what they can or cannot do to get the project moving forward. If they are unaware of how the organization works or lack authority, they might not be in a good position to make any difference. Taking Luhmann’s theory even further, philosopher Jiddu Krishnamurti said, “To understand is to transform what is.” Practically speaking, a project manager’s effectiveness within an organization, especially at delivering results in the project they manage, is proof of their ability to understand that organization in order to drive change. Stepping back to Luhmann’s theory, the ability for the project manager to repeatedly effect change within the organization through repeated successful delivery makes that organization and its system much stronger and simpler over time.
Combining the above theories with the project management theory discussed in the PMBOK® Guide, we understand that systems are unique, they are complex and consist of various components and their associated functions, their complexity can be adjusted to enable efficiency, and they are dynamic enough that it is not simple to predict what the consequences would be in changing the system.
This reminds me of an “Internet of Things” (IoT) product I was working on, and I referred to this yaml sample on digital twins. Within a venue there is are spaces, and within a space there are devices, and within a device there are sensors. The sensors may communicate with an IoT hub that is tied to the venue itself, allowing the devices to all interact with one another depending on their attributes. Why is this important in understanding systems?
We can break down any object into smaller objects, and it is the way in which all of these objects and sub-objects interact that will determine the overall output of the highest level object. The same applies to an organization, its systems, the systems’ components, and the components’ functions. By understanding this, an organization can develop and maintain a governance framework that enables the organization and its various systems and sub-systems to operate in a more predictable manner.
Given that an organization and everything within it is managed to some degree, a closer look reveals that the degree and structure of management at each level allows the organization and its participants the ability to influence each other. By understanding people and process, project managers can understand what factors within the organization should be considered as well as the data that is required to be able to understand and maneuver through the organization to deliver change.
Governance is about authority and how it can be exercised within a particular context. An organizational governance framework is the context on how authority is exercised within an organization. A project governance framework is the context on how authority is exercised within a project.
By understanding all the various ways the organization can work through its governance framework, a project manager will be in a position to know how their project will be affected by the way in which the organization sets and achieves objectives, manages risk, and addresses performance. They can in turn determine the best governance framework for their individual project (or, in more complex settings, programs and portfolios).
Because of my interest in jurisprudence and legal practice generally, easily found in other places where I write, I find governance fascinating. While it is not incredibly critical to obtaining the PMP® certification, I am curious to know more about the four governance domains:
each domain’s functions of:
and each function’s supporting processes and activities.
A project’s governance will depend on the organization’s structure, and there are many types:
Organic or simple – usually a solo entrepreneur getting it all done or with other part-time contributors
Functional or centralized – separate departments getting things done
Multi-divisional – similar to functional, where each division has its collection of departments mirroring other divisions
Matrix (strong, weak, and balanced) – organization with functional and project-level control over project management in various degrees, with a strong matrix being more like a project-oriented organization, and a weak matrix being more like a functional organization
Project-oriented – one that is based on projects being delivered
Virtual – centralized organization that outsources and networks with various other processes
Hybrid – mixtures of other structures
PMO – one with a department dedicated to project (or program or portfolio) management that has significant influence on how projects and more complex forms of work are managed; they can be supportive, controlling, or directive
Summary: Revisiting data privacy and political beliefs
As I mentioned earlier, the project manager (in this case) needs to maintain auditable records regarding amounts of personal data processed and how often political beliefs are referenced for the purpose of judging testing results.
Within the organization, which is a hybrid consisting of a functional structure with a PMO there are various systems such as departments within the project manager’s company including the project management office (PMO), legal, IT security, and compliance.
The PMO has its own processes which guide the project manager (PM) in knowing to connect with their legal, security, and compliance counterparts. Legal refers the PM to the organization’s legal knowledge base which informs them about the privacy legislation and how it is incorporated into contracts. Security refers the PM to the project-level controls that should be followed to implement the required auditability. Compliance refers the PM to other guidance and considerations they should follow at an organizational level.
Every three months, the compliance department requires all projects to report their compliance with various rules, policies, and procedures of the organization, and the PM will provide a report to this effect. At the organizational governance level in this example, the compliance department has the authority to compel the PM to provide those reports, and the PM lacks the authority to decline the compliance team’s request. As a result, the PM has set up their project governance framework to ensure all report details are regularly collated and generated into a report that can be smoothly sent to the compliance team.
Within the project itself, because of how it deals with personal data, the project governance framework also explains how change requests to the system in relation to personal data should be reviewed and approved. This was a recommendation provided by the legal team and turned into policy detail by the security team, which the PM has enshrined into the project’s management.
The story above briefly expresses the PM’s influence over both the organization and the project they manage based on how they work with the relevant OPAs and EFFs in the context of the organization and its systems.
Enterprise Environmental Factors (EEFs) are the policies, rules, and other conditions that must be adhered to in the process of carrying out certain activities, and in the context of project management, EEFs need to be accounted for when conducting any project activities.
Organizational Process Assets (OPAs) are the resources a project manager can make use of in projects such as historical information, templates, and other organizational knowledge that all may assist in the progression of the project.
Organizational Systems determine how the project life cycle might work due to the structure of the organization managing the project.
All three of these items are covered in Chapter 2 of the PMBOK® Guide, Sixth Edition.
Data privacy and political beliefs: An example
Together, EEFs and OPAs can determine how the project will be managed. If EEFs restrict the project manager from working with data in a certain way – for example the handling of personal data – the project manager may have additional layers of activity that should be performed to work with that data. An example might be that beyond what any data privacy legislation may require (which are also EEFs), project managers need to maintain auditable records on the amounts of personal data used in testing the software and how often sensitive data such as political opinions are used on the basis of accepting or rejecting test results.
The organization might have a policy relating to discrimination on the grounds of political beliefs, and though it might not relate to employees, as a matter of policy they want to ensure the software they are working with cannot be used to discriminate as well. During the development of the project,
The test automation framework (TAF) used by the project may be based on a standard structure used by the organization, which would make the TAF derived from an OPA, and it could be configured and updated to enforce the anti-discrimination policy to ensure testing is conducted objectively. The way in which this scenario is handled in the project could be affected by the coordination required with the relevant legal personnel, data privacy and IT security specialists, as well as corporate compliance teams. The coordination required reflects the Organizational Systems that will affect the project management approach.
Enterprise Environmental Factors: A closer look
EEFs that are internal to the organization include policies, rules, and other forms of compliance required that will directly influence how the project can be managed. The example above included policies on anti-discrimination, information security, and testing strategy.
Those that are external include contracts, laws, regulations, and other items not within the organization’s control. In the case of a contract, while portions of the way the contract work is internal in nature, the other portion of control belongs to an external party which can influence how the project works. For example, the organization’s contract with a vendor to secure licenses to use the project management software might change in price next year, and because the contract does not contain a way of avoiding this, the project is influenced by this external EEF, and it will need to account for this price change in the Cost Management.
Organizational Process Assets: A closer look
Details on the processes, policies, and procedures used by the organization are assets which allow the project teams to work in a certain manner. There may also be details on past project historical information, change control procedures, analytics data, testing strategies, and useful reports.
These details may be stored in one or more organizational knowledge repositories. Some organizations have a “knowledge base” or KB that documents all of these various materials for reference by the project team. This includes project records, closure information, task management information, and various other records.
EEFs and OPAs both have processes and policies?
The difference between an EEF and an OPA in this context is that we use the information on the processes, policies, etc. as organizational process assets to benefit our work. The fact that there are processes or policies may be an internal enterprise environmental factor the project needs to account for, and they do so in assistance with the relevant organizational process assets such as the organization’s compliance guide.
According to a loose estimate generated in 2011, there are more than 16.5 million project managers in the whole world. I am not sure what estimates are reliable in 2020, but access to education and the demand for managers to organize activities to perform has increased especially thanks to remote working opportunities and the increased adoption of project management by numerous sectors, with the Project Management Institute (PMI) suggesting that by 2027, over 85 million individuals will be needed in roles related to project management. What technological unemployment?
The PMI’s PMBOK® Guide (Sixth Edition) and the PMP® Exam (until the new one launches on January 2, 2021) covers five domains (process groups) within project management covering the following details:
Initiating (~26 Questions, 13% of the Exam, 2 Processes, 8 Tasks)
Perform Project Assessment
Identify Key Deliverables
Perform Stakeholder Analysis
Identify High Level Risks, Assumptions, and Constraints
Participate in Development of Project Charter
Obtain Project Charter Approval
Inform Stakeholders of Project Charter Approval
Planning (~48 Questions, 24% of the Exam, 24 Processes, 13 Tasks)
Assess Detailed Project Requirements, Constraints, Assumptions with Stakeholders
Develop Scope Management Plan
Develop Cost Management Plan
Develop Project Schedule
Develop Resource Management Plan
Develop Communications Management Plan
Develop Procurement Management Plan
Develop Quality Management Plan
Develop Change Management Plan
Develop Risk Management Plan
Present Project Management Plan to Stakeholders
Conduct Project Kick-Off Meeting
Develop Stakeholder Management Plan
Execution (~62 Questions, 31% of the Exam, 10 Processes, 7 Tasks)
Acquire and Manage Project Resources
Manage Task Execution
Implement Quality Management Plan
Implement Approved Changes
Implement Approved Actions for Risk Management
Maintain Stakeholder Relationships
Monitoring & Controlling (~50 Questions, 25% of the Exam, 12 Processes, 7 Tasks)
Measure Project Performance (EV, etc.)
Verify Project Deliverables Quality
Monitor and Assess Risk
Review Issue Log
Capture and Analyze Lessons Learned
Monitor Procurement Activities
Closing (~14 Questions, 7% of the Exam, 1 Process, 7 Tasks)
Obtain Final Acceptance
Transfer Deliverable Ownership
Obtain Financial, Legal, and Administrative Closure
Prepare and Share Final Project Report
Collate Lessons Learned
Archive Project Documentation
Obtain Stakeholder Feedback
What does project management have to do with technological unemployment?
In the context of software or hardware that automates the execution of any pre-defined steps, a human is no longer needed to execute those steps, but the system and its maintenance very well might be should be managed. It is important to make sure that technology does precisely what it was intended to do when it was designed in the first place. A project manager in the case of already launched technology could be involved in observation of certain defects or risks that might arise while the system is in use, and fixes for those defects or improvements to address risks are then planned for execution by an engineering team. A project manager involved in building that technology for the first time would have to deliver results guaranteeing a more automated outcome. As I wrote earlier, there are plenty of structural adjustments that can and should be made to sustain the economy. Project managers will be critical in delivering those adjustments.
Managers of technology projects will appreciate the body of knowledge covered in the PMBOK® because it provides a framework for understanding how to start up, plan, and get things done. I do not suggest the PMI is the only brand in project management, nor do I suggest they have ownership over the legitimacy of any project management initiative. I will say though that the associated body of knowledge is not only a great framework but also one that has been used and replicated throughout project management, so the jargon may well be familiar with those in project management regardless of their certifications.
What are all of those tasks?
Besides for Initiating and Closing, there are fewer Tasks than Processes covered in each Domain.
The tasks represent “the general things you do” to achieve what is expected of a project manager for each domain.
What is the difference between a process and a task?
There are three types of processes according to the book, and they are ones that are:
Used once or at predefined points,
Performed periodically, or
Tasks are things that need to be done that in the case of Initiating or Closing might all fit within one or two processes. In Planning, there are 24 Processes and 13 Tasks. When conducting those 13 tasks, doing so successfully requires accounting for those 24 processes.
A task is just one of the important things a project manager does in their role, and a process is the repeatable approach as to how part of a task, a whole task, or even multiple tasks might be performed within a single domain.
49 Processes? How does that work?
The 49 Processes are organized both by Domain and by Knowledge Area.
I am not going to pretend to be the expert with all of the answers, but I am the expert that knows where to look for the answers. Through diligent searching online, I have found some pretty useful guides. Firstly, the PMBOK® itself (the source), this great Udemy course (which applies breadth and depth in understanding what the exam covers), this helpful set of YouTube videos (which articulates the thought process behind answering questions quite well), and this amazing processes flow diagram (which shows the processes organized spatially by domain and color-coded by knowledge area).
The 49 Processes are organized by 10 Knowledge Areas as follows:
Project Integration Management
Develop Project Charter
Develop Project Management Plan
Direct and Manage Project Work
Manage Project Knowledge
Monitor and Control Project Work
Perform Integrated Change Control
Close Project or Phase
Project Scope Management
Plan Scope Management
Project Schedule Management
Plan Schedule Management
Estimate Activity Durations
Project Cost Management
Plan Cost Management
Project Quality Management
Plan Quality Management
Project Resource Management
Plan Resource Management
Estimate Activity Resources
Project Communications Management
Plan Communications Management
Project Risk Management
Plan Risk Management
Perform Qualitative Risk Analysis
Perform Quantitative Risk Analysis
Plan Risk Responses
Implement Risk Responses
Project Procurement Management
Plan Procurement Management
Project Stakeholder Management
Plan Stakeholder Engagement
Manage Stakeholder Engagement
Monitor Stakeholder Engagement
How does one absorb all of this?
It certainly requires dedication and hard work, but it also requires smart work.
By combining multiple resources discussing the consensus that is the body of knowledge and how it was intended to be used in practice, I can be more confident that whether I take the exam or apply the knowledge in practice that it is based on the industry standard.
In the series of blogs I will be writing on this topic, I will cover in more detail the domains (process groups), the tasks, the knowledge areas, and the processes, and I will do that in many different ways.
When I mentor students on new concepts, I do so through “boxing”. I position six sides and close them in on the meaning I aim to convey (yes, I meant that literally).
There are five domains that form the project management life cycle, and in those domains there are tasks that should be performed by the project manager.
Those tasks are accomplished through the use of processes, and each process is specific to a domain, which means it happens during a certain part of the project management life cycle.
Each process is also tied to a certain knowledge area, which is related to a discipline of sorts – such as scope, schedule, budget, and more – and there are several processes within a knowledge area that exist across the five domains.