Insights into the Critical PM Pieces across the 3 Domains & 6 Segments
The purpose of this article is to explain some of the Project Management items or Pieces that are in the 6 segments.
In the MPM Model, the Pieces represent all of items you have to create to answer the 5 Ws and H questions for a Project: Why? Who? What? How Much? Where? When?
MPM Pieces answer the 5 Ws and H specific to Project Management
The Pieces are for specifically for project management
Good research starts with the 6 questions of Why? Who? What? How Much? Where? When? The MPM model starts with those questions as well, and they are on the inside of the 6 segments at the top of the stop-sign shaped MPM model.
Within each of segment in the detailed visual are the project pieces that answer those 6 questions.
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 article has a brief definition of pieces, however each is covered in more detail in subsequent articles.
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.
Constraints
Constraints are the external guardrails or boundaries that limit the scope, schedule, and costs.
A constraint could be a time dependency by which the project has to be delivered. Or it could be a cost limit, meaning a budget maximum above which there are no more funds.
A constraint could also be scope related in that certain aspects must be done as part of the project, but other aspects are optional.
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
Team
Some project documentation identifies the team as a type of stakeholder, and yes, they are stakeholders because they are involved in producing the outcomes.
However, the team is your core group who is going to work together to create a sum that is greater than the parts. The project team needs to be composed of particular roles and skills to get the project done. These must be described in the charter.
The team is the group that reports to the individual in the project manager role, so for the sake of the project they report to that role. The organization which outlines the governance will show the team as reporting to the project manager who reports to the project champion and then the stakeholders some of who are on the steering committee.
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, but it is beneficial to describe them separately as their roles as creators of the project outcomes is different than that of a stakeholder who is affected by the outcomes that are produced.
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.
Outcomes
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
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.
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.
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
Testing
Testing 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.
EV of Outcomes
Earned Value of Outcomes is the quantity of the outcomes that have been created at a particular point in time compared with what was expected to be created at that point in time.
If less has been created than what was expected then the project is behind in terms of outcomes. Conversely if more of the outcomes have been created than what was expected then the project is ahead for outcomes.
Financials
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.
EV for financials
Earned Value for financials is the project spend at a particular point in time compared with what was expected to have been spent at that point in time.
If less has been spent than what was expected then the project is ahead in terms of the financial spend. Conversely if more budget has been spent than what was expected at that time then the project is over budget from the financial perspective.
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.
EV for the plan
Earned Value for the plan compares the earned value for the outcomes versus the earned value for the financials for the entire plan at a particular point in time compared with what was expected to be created for the funds used at that point in time.
If the outcomes that have been created are more than what was expected to be spent for those outcomes at this point in time then the project is ahead and under budget.
Conversely if less of the outcomes have been created for the funds spent than what was expected at this point in time, then the project is over budget and behind regarding the entire plan.
Timing
Timing
The timing is the specific expected dates for the outcomes on the project and any external constraints identified around the what the project is producing and what the stakeholders are expecting.
While it is considered that they are three constraints, schedule, scope, and cost, the schedule constraint or timing around the delivery of the project outcomes is usually the most predominant constraint of the three.
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.
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
Summary
Project pieces represent very specific project management items 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 articles 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 article was just an introduction to these PM pieces and subsequent articles cover each in more detail, with examples, and suggestion on how to integrate activities 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 pieces.
- 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 articles articles, where they appear in the text above, or search through the articles using the PM piece tag. Each PM piece has a matching tag in the Learning Hub on the site (simplepmstrategies.com).
- Prompt engineering guidance for AI GPTs such as chatGPT: “I’m a business leader launching a project whose project is delivering X, Y, and Z. What are some detailed items that must be in the charter to ensure the project is successful?”
Learn More to Do More
Business evolves through change initiatives otherwise known as projects. The key to managing these change initiatives so you have more time, and less stress is to use simple strategies and tools.
Check out the Learning Hub’s other Articles with Actionable Steps, organized with a busy leader in mind, by topic or main idea, and with some AI GPT (e.g. ChatGPT) prompt engineering suggestions under the Action steps: https://simplepmstrategies.com/learning-hub-index
MPM - PM Items
© Simple PM Strategies 2024