Insights into the Critical PM Items across the 6 Domains
The purpose of this blog post is to add specific Project Management items for each of the Project Management Domains to explain the third circle of the MPM model in the context of managing projects.
The previous blog covered the second circle, the Project Management domains of knowledge (Motive, People, etc.) and the blog before that covered the inner circle (Why?, Who?, etc.).
MPM Items (the outer ring) are specific to Project Management
The MPM model outer leaf Items are specific to project management
Building on the project management knowledge domains we now add the items which are specific to each project management domain.
These are the items that you need to keep a focus on when you are managing your project on a daily and weekly basis.
This blog post has a brief definition of each of the project items, however each item is covered in more detail, including with a relatable example, plus how to integrate them into your daily and weekly routines, in subsequent blog posts.
Motive
Purpose
The Purpose is the core of your “Why?” for your project. Your reason for the project. Companies have their “Why”, as Simon Sinek covered in his TED Talk, their purpose cause or belief.
Your project has a “Why” too and it can be stated in one or two sentences. Why are you doing this project?
Description
The purpose may need more supporting information, and this is provided in the description. It could be a few paragraphs or a half a page.
Sometimes to clarify for stakeholders, you can create two subsections to this area: Current State and Target State. Current State describes what is experienced now, and Target State describes what is experienced after the project is done.
Assumptions
When you state your project’s purpose it comes with some assumptions and this is where those are listed, such as in bullet point form.
There is an initial list created during the early stages of the project and it can be updated as the project progresses.
Typically, when the draft document introducing the project is circulated to those you are looking to get feedback from, those individuals usually raise questions about what is included or not included in the project and that prompts an update to the set of assumptions.
Risks
Risks are potential issues that, if they occur, can cause problems leading to negative impacts on your project or organization. More detail on developing and phrasing risks see this article
Risks are Issues that can negatively impact your project
Risks are also items frequently raised through feedback on your initial project description in the beginning of the project and develop into a comprehensive list, and this risk list remains active throughout the project.
People
Roles
Project roles are labels attached to the description of the skill sets needed to complete the project.
This is best done, initially, independent of the actual people who are expected to be on the project because it creates an objective perspective about what kind of person is needed, before the bias of choices of who actually is going to help is applied.
Define your roles to ensure you have the right people
Organization
The organization is the hierarchy of decision making in the project. Typically, it is a little mini org chart showing top-down all of the roles, committees and teams, externals and internals, including where the project manager fits in.
This org chart helps define the communications for the project.
Stakeholders
Stakeholders can be from inside, internal, or outside, external, the organization. They can be regulatory or legal entities, or associations or any parties who have a vested interest in the outcome of the project.
A lot of project management literature refers to the project team as stakeholders, that is internal ones of course.
As the project proceeds it may be helpful to use stakeholder labels to distinguish among the different kinds of stakeholders to avoid confusion, and some of that is articulated in this blog post.
Communications
Communications is your plan for how to communicate with both internal and external stakeholders.
This is sometimes not defined in projects but it is best clarified with stakeholders early on and put into a table and then it becomes a process to follow, taking the guess-work out of who to provide what information to when, and under what conditions. There is a blog post here that covers some of that in detail.
To save time, create a plan for how you communicate
Adoption
Adoption is when your eventual “customers” of the project, even if it is just your team, adopts the outcomes of the project and integrates that into their daily and weekly habits so they have new ways of operating.
Your project’s “customers” can have all the learning and training available, but if they do not adopt the new ways of working with whatever the project outcomes are then the project is not successful.
I have a saying that I developed after leading and living through 40+ projects that speaks to this:
The project team thinks the project is done when the solution works. The business team thinks the project is done when business changes.
Adoption is change management the way John Kotter refers to it, but some more technical project management sources refer to change management as strictly the act of managing change of scope requests, not necessarily helping the project customers adopt the new solution, so the word Adoption has been chosen here to differentiate definitions.
Things
Objectives
Objectives are statements about things that can be measured, and when these things are achieved, and meet their measures, the project successfully achieves its purpose.
They should be kept high-level enough that a range of requirements can satisfy their measures and still successfully complete the project purpose.
Objectives are covered in a number of blog posts, but here is a little more detail if you are interested at this point.
Project objectives need to be objectively measurable
Scope
Scope describes the boundaries of the project. This helps project stakeholders and team members understand the expected boundaries for analysis, design, and implementation.
Scope can change, and often does, as the project proceeds, and as more knowledge is gained about the solution, so this tends to be a fairly active project item.
Requirements
Requirements describe the details about the options for satisfying the objectives within the scope specified.
Requirements can be described as mandatory or optional and like the scope, these can also evolve and require updating as knowledge increases about the project solution and what is possible or not possible.
Deliverables
Deliverables are the things the project produces that you can touch and feel. They are the outcomes that the tasks or activities produce.
Deliverables are often confused with tasks, but they are not the same, as tasks describe the actions that the project team is going to take to create the outcomes or project deliverables.
How something is going to be achieved is more susceptible to modification than what is being achieved.
This link provides detail to a blog post that describes creating deliverables, if you want to go into more detail at this time.
Deliverables are outcomes you could trade for money
Quality
Quality is a relative measure of how well the deliverable conforms to the requirements and expectations of the customer.
Project solutions can be given as completed to a customer even if it has aspects of it that do not work according to requirements. It just may mean, for example, that the customer has more manual steps than originally expected, but the outcome they achieve is still acceptable.
Some detail about how to create a quality framework and set of tests is covered in this blog post.
Money
CAPEX
CAPEX is Capital Expenditures, those items that are assets and therefore subject to depreciation because at some point in the future, a new version, upgraded version or entirely new asset purchase is needed to replace the one that has outlived is useful life and is fully depreciated.
What is considered a capital expense can vary from one organization to the next, so it is best to get the definition from your accounting arm that then you use for allocating your project’s expenses.
OPEX
Operational expenses are those project expenses which are consumed as a normal course of operating and do not add to the value of the organization.
What is considered an operational expense versus capital expense can vary from one organization to the next, so it is best to get the appropriate definition for which is which from your financial team.
Your budget is a weekly and monthly flow for CAPEX and OPEX
Budget
The project budget is where the CAPEX and OPEX amounts are listed over the time period of the project to show expected cash flow per month or week.
The budget also contains potential CAPEX and OPEX amounts that need to be carried by an operational arm of the organization after the project is complete.
The transfer of these amounts from the project to the appropriate organizational team is covered in the final part of the project, which is called TRANSITION.
Procurement
Procurement covers project purchasing for RFx that is done as part of the project. RFx includes: Request for Information (RFI), Request for Quotes (RFQ), and Request for Proposals (RFP).
Managing these can be very involved and complex and engage a wide group of team members on the project, so if that is a requirement of the project, then Procurement covers the steps and procedures that are used for the RFx.
Map
Methodology
A methodology is a documented set of steps, procedures, and outcomes that someone has put together that is like a template to follow when creating your approach.
I obtained my professional engineering designation based on my work in methodologies, have presented seminars and workshops on the differences between CMM and ISO, have led part of an organization to CMM level 5 – documented in a published article, and have been engaged as a methodology expert in Fortune 500 organizations. Throughout this experience, I can state that the methodology always needs to be adapted to your particular situation.
Your project never follows a documented methodology exactly, and that is where your Approach comes in. The Approach is your interpretation of the methodology for your specific project.
Your Approach is your project management map
Approach
The approach uses your project’s unique deliverables to create a map or path to the achievement of your project’s deliverables.
Determine the best path or route by looking at all of your deliverables, their order and dependency, what can be done in parallel and what is required to be completed serially. This foundation is important before applying timing constraints to create a schedule.
Timing
Schedule
The schedule is the application of timing constraints, or a calendar on top of your project approach.
Applying calendar dates often causes the need to iterate back to the Approach to modify it by re-examining some of the assumptions that went into the creation of the Approach, for example regarding what needs to be done sequentially versus coincidentally.
Sometimes to save time in the schedule, further analysis reveals that two deliverables can be done at the same time, rather than waiting for one to start until the other is complete.
The schedule imposes calendar dates on your project timing
Milestones
Milestones are particular points in the schedule that are markers of progress, that the stakeholders can use to determine project progress or problems.
Milestones can also represent key integration points with external projects, regulations, or any kind of external critical constraint.
Milestone slippages, where dates are pushed out due to problems that occur, often become very political and require significant justification, so it is best to keep this set small and significant.
Summary
Project management items represent very specific project focus areas that involve daily and weekly activities by the project manager.
These activities are integrated into the manager’s daily habits, amongst all of their other management responsibilities.
Subsequent blog posts, and certainly an item covered in the workshops, is how to create an efficient integration so it takes the least amount of a manager’s time yet still gets the job done and produces a successful project.
This blog post was just an introduction to these PM items and subsequent blog posts cover each in more detail, with examples, and suggestion on how to integrate activities that support the PM items into a manager’s daily and weekly habits.
Action Steps / Apply This Knowledge
- Labels and names used for project items may differ slightly from what you, your organization, or your methodology uses.
Print out a picture of the MPM model at the beginning and map project items you are familiar with to the corresponding MPM model PM Item.
- For any areas on the MPM model that are not mapped, ask whether you need to do them or not, or what you may be missing by not doing them.
- To understand PM items in more detail follow the links to other blog post articles, where they appear in the text above, or search through the blog post articles using the PM Item tag. Each PM item has a matching tag in the Blog Posts accessible through the Learning Hub on the site (simplepmstrategies.com).
Learn More
In an upcoming workshop, for which you can subscribe to be notified when it’s available, we cover project management examples in detail.
Also, in the workshop, we go into greater depth on many of the project management items in the Manager Project Mastery (MPM) model. As well you can ask questions about any of your current projects during the Q&A.
MPM - PM Items
© Simple PM Strategies 2021