I have a question regarding the PMBOK Guide and Method Statements in construction projects.
I have extensive experience preparing Method Statements for construction activities. While reviewing the PMBOK Guide, 7th Edition, I noticed that the term “Method Statement” is not explicitly defined or discussed.
From the PMBOK perspective, how should a Method Statement be understood and classified, and how does it fit within the PMBOK framework?
I would particularly appreciate perspective of PMPs and other Construction Project Managers regarding how such a construction-specific document relates to the broader PMBOK approach.
I actually already contacted PMI Customer Care (via WhatsApp and email). They advised me to post my question on ProjectManagement.com to get insights from the community.
Since this is a question regarding the interpretation of the PMBOK 7th Edition standard, and Customer Care redirected me here, is there a specific subject matter expert or department within PMI that handles standards-related inquiries? I would appreciate any guidance you can provide, as I seem to be going in circles
I actually already contacted PMI Customer Care (via WhatsApp and email). They advised me to post my question on ProjectManagement.com to get insights from the community.
Since this is a question regarding the interpretation of the PMBOK 7th Edition standard, and Customer Care redirected me here, is there a specific subject matter expert or department within PMI that handles standards-related inquiries? I would appreciate any guidance you can provide, as I seem to be going in circles Saving Changes...
Online Community Specialist| PMINewtown Square, Pa, United States
Hello Aleksandar - I was just notified from my colleague that you should have been directed to our Standards team at [email protected]. Apologies for the misinformation from customer care, and thanks for your patience!
...
1 reply by Aleksandar Loncar
Oct 03, 2026 1:27 AM
Aleksandar Loncar
...
Thank you very much, Kimberly. I will send my inquiry to the Standards Team email you provided. At the same time, I hope to hear from other members here as well, since I am sure there are many who know PMBOK and project management well and could share their view.
Hello Aleksandar - I was just notified from my colleague that you should have been directed to our Standards team at [email protected]. Apologies for the misinformation from customer care, and thanks for your patience!
Thank you very much, Kimberly. I will send my inquiry to the Standards Team email you provided. At the same time, I hope to hear from other members here as well, since I am sure there are many who know PMBOK and project management well and could share their view. Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Thank you, Aleksandar. I think your question is particularly interesting because a Method Statement does not map as neatly onto the PMBOK 7 taxonomy as its documentary form might initially suggest. I would start by separating three different units of analysis that construction practice can bring together: the means by which the work is to be performed, the Method Statement as a documented output, and the professional practice of developing and using it. Depending on the contractual, regulatory and organizational context, a Method Statement can perform a broader role than simply recording how work will be carried out. It may contribute to planning, communication and monitoring, and integrate aspects such as sequence of work, resources, risks and controls, quality requirements, interfaces, inspection arrangements and other conditions governing execution. If we then apply the PMBOK 7 Models, Methods and Artifacts taxonomy, the distinction becomes clearer. PMI defines a method as a means for achieving an outcome, result or project deliverable, and an artifact as a template, document, output or project deliverable. I have not found anything in that taxonomy establishing that these classifications must be mutually exclusive. If the unit of analysis is the Method Statement as a documented output, Artifact is, in my view, the most direct PMBOK classification. If the unit of analysis is the underlying means by which the work is to be performed, we are closer to Method. But neither observation fully describes the role a Method Statement may perform within a construction delivery system. Developing and using a Method Statement may itself contribute to defining and refining how the work will be executed, integrating risks and controls, coordinating interfaces, communicating requirements and monitoring execution. Depending on the project and contractual arrangements, the document may also have roles in technical review, quality assurance, compliance, approval or authorization processes. These are context-dependent functions, not universal characteristics of every Method Statement. This is where I think your “hybrid” question becomes particularly interesting. I have not found “hybrid” established as a separate category in PMBOK 7. But classifying the Method Statement as an Artifact when the unit of analysis is the documented output does not, by itself, tell us everything about the role that document may perform in practice. PMI-CP provides a useful construction-specific perspective here. It was developed through a Job Task Analysis of construction practice, and PMI explicitly states that its taskforce was not bound by the PMBOK Guide. Its Exam Content Outline does not explicitly identify a Method Statement, and its enablers are illustrative rather than exhaustive. However, in my reading, functions that may be associated with Method Statements can be found across contract and risk management, interface management, scope and change management, communication and governance. I would therefore distinguish: Method Statement as documented output → most directly Artifact Underlying means by which the work is performed → more closely associated with Method Development and use of the Method Statement → integrative professional practice I would then examine separately the role the Method Statement performs within the particular project delivery and governance system, because that role may vary with the contractual, regulatory and organizational context. So, rather than asking only “Which PMBOK category does a Method Statement belong to?”, I would also ask “What functions does it perform in this particular construction delivery system?” The first question leads me most directly to Artifact. The second explains why Artifact may not be the whole answer. So my answer would be: Artifact is the most direct PMBOK 7 classification when the unit of analysis is the Method Statement as a documented output. But that classification does not necessarily capture all the functions the Method Statement may perform within a particular construction delivery system. I would therefore see “hybrid” as a useful way of framing the question of whether its documentary classification fully captures its role in practice, rather than as a formal PMBOK 7 category. This is an analytical mapping using PMBOK terminology and PMI’s construction framework, not an explicit PMI classification of Method Statements.
...
1 reply by Aleksandar Loncar
Oct 04, 2026 11:29 AM
Aleksandar Loncar
...
Luis, Thank you for your detailed and comprehensive response. Your answer tells me that my question did not cover all aspects of the Method Statement, but it also tells me that the question was good and interesting enough to generate such a serious response. My question was not just a call for a simple classification, because I asked: "From a PMBOK perspective, how should a Method Statement be understood and classified?" To be honest, I was not thinking about its function and role at that moment. My goal was to get a substantive and detailed answer with reasoning — to avoid a response like “it’s an artifact, and that’s the end of the story.” You give much more than I asked for. You give my question a third dimension by introducing function and role. I also posted this question on LinkedIn. There were no comments there, but it brought me strong professional feedback in the form of two responses from Serbian PMP engineers, and one from you. My goal was not to rank them, but to get the widest possible picture — to put them side by side and compare them, to see where they overlap and where they different. In any case, your response is the most complex and the only one that introduces a third dimension. But the other two responses are also very serious and high-quality. I come from the field of construction and technical documentation, and your response will be very useful to me in my future work. As a practitioner, I really like the content of the Method Statement that you outlined, and I will try to incorporate as many of those elements as possible in my future work. You also spoke about the roles a Method Statement can have. In my practice, these documents undergo technical review and technical inspection, contain quality assurance and quality control elements, and I always try to align them with standards and tolerances. The process always ends with submission, review, and approval by the supervisor. I find it very interesting when you say that a Method Statement can be both an artifact and a method, depending on what is being observed. If it is viewed as a documented output — a physical document — then it is an artifact. If it is viewed as a way of working — what the document describes, how the work will be done — then it is a method. I intuitively felt that it must have some connection to a method, because the document itself contains the word “method,” but I did not know how to express it. I would like to hear other opinions as well — whether they fully agree with this and whether they have different views. At this moment, this seems very convincing to me. When I mentioned “hybrid”, I was exploring whether the Method Statement could represent a combination of processes rather than a single PMBOK category. I also asked whether it could be considered a process at all. In my LinkedIn post, the third option was actually “HYBRID PROCESS: Combination of processes across the Delivery, Risk and Resource Performance domains.” When I decided to ask PMI, I deliberately removed the suggested options so as not to lead the answer, and that is how I submitted the question. However, at the last moment, I added “Artifact, Method or Hybrid?” to the title instead of “Hybrid Process.” That was my mistake and may have caused some ambiguity. At the end, you say that this is an analytical mapping using PMBOK terminology, and not an explicit PMI classification of the Method Statement. Since I also sent my question to the PMI Standards Team, it will be interesting to see their view and what the exact explicit PMI classification is. Thank you again for taking the time to give such a detailed answer.
Thank you, Aleksandar. I think your question is particularly interesting because a Method Statement does not map as neatly onto the PMBOK 7 taxonomy as its documentary form might initially suggest. I would start by separating three different units of analysis that construction practice can bring together: the means by which the work is to be performed, the Method Statement as a documented output, and the professional practice of developing and using it. Depending on the contractual, regulatory and organizational context, a Method Statement can perform a broader role than simply recording how work will be carried out. It may contribute to planning, communication and monitoring, and integrate aspects such as sequence of work, resources, risks and controls, quality requirements, interfaces, inspection arrangements and other conditions governing execution. If we then apply the PMBOK 7 Models, Methods and Artifacts taxonomy, the distinction becomes clearer. PMI defines a method as a means for achieving an outcome, result or project deliverable, and an artifact as a template, document, output or project deliverable. I have not found anything in that taxonomy establishing that these classifications must be mutually exclusive. If the unit of analysis is the Method Statement as a documented output, Artifact is, in my view, the most direct PMBOK classification. If the unit of analysis is the underlying means by which the work is to be performed, we are closer to Method. But neither observation fully describes the role a Method Statement may perform within a construction delivery system. Developing and using a Method Statement may itself contribute to defining and refining how the work will be executed, integrating risks and controls, coordinating interfaces, communicating requirements and monitoring execution. Depending on the project and contractual arrangements, the document may also have roles in technical review, quality assurance, compliance, approval or authorization processes. These are context-dependent functions, not universal characteristics of every Method Statement. This is where I think your “hybrid” question becomes particularly interesting. I have not found “hybrid” established as a separate category in PMBOK 7. But classifying the Method Statement as an Artifact when the unit of analysis is the documented output does not, by itself, tell us everything about the role that document may perform in practice. PMI-CP provides a useful construction-specific perspective here. It was developed through a Job Task Analysis of construction practice, and PMI explicitly states that its taskforce was not bound by the PMBOK Guide. Its Exam Content Outline does not explicitly identify a Method Statement, and its enablers are illustrative rather than exhaustive. However, in my reading, functions that may be associated with Method Statements can be found across contract and risk management, interface management, scope and change management, communication and governance. I would therefore distinguish: Method Statement as documented output → most directly Artifact Underlying means by which the work is performed → more closely associated with Method Development and use of the Method Statement → integrative professional practice I would then examine separately the role the Method Statement performs within the particular project delivery and governance system, because that role may vary with the contractual, regulatory and organizational context. So, rather than asking only “Which PMBOK category does a Method Statement belong to?”, I would also ask “What functions does it perform in this particular construction delivery system?” The first question leads me most directly to Artifact. The second explains why Artifact may not be the whole answer. So my answer would be: Artifact is the most direct PMBOK 7 classification when the unit of analysis is the Method Statement as a documented output. But that classification does not necessarily capture all the functions the Method Statement may perform within a particular construction delivery system. I would therefore see “hybrid” as a useful way of framing the question of whether its documentary classification fully captures its role in practice, rather than as a formal PMBOK 7 category. This is an analytical mapping using PMBOK terminology and PMI’s construction framework, not an explicit PMI classification of Method Statements.
Luis, Thank you for your detailed and comprehensive response. Your answer tells me that my question did not cover all aspects of the Method Statement, but it also tells me that the question was good and interesting enough to generate such a serious response. My question was not just a call for a simple classification, because I asked: "From a PMBOK perspective, how should a Method Statement be understood and classified?" To be honest, I was not thinking about its function and role at that moment. My goal was to get a substantive and detailed answer with reasoning — to avoid a response like “it’s an artifact, and that’s the end of the story.” You give much more than I asked for. You give my question a third dimension by introducing function and role. I also posted this question on LinkedIn. There were no comments there, but it brought me strong professional feedback in the form of two responses from Serbian PMP engineers, and one from you. My goal was not to rank them, but to get the widest possible picture — to put them side by side and compare them, to see where they overlap and where they different. In any case, your response is the most complex and the only one that introduces a third dimension. But the other two responses are also very serious and high-quality. I come from the field of construction and technical documentation, and your response will be very useful to me in my future work. As a practitioner, I really like the content of the Method Statement that you outlined, and I will try to incorporate as many of those elements as possible in my future work. You also spoke about the roles a Method Statement can have. In my practice, these documents undergo technical review and technical inspection, contain quality assurance and quality control elements, and I always try to align them with standards and tolerances. The process always ends with submission, review, and approval by the supervisor. I find it very interesting when you say that a Method Statement can be both an artifact and a method, depending on what is being observed. If it is viewed as a documented output — a physical document — then it is an artifact. If it is viewed as a way of working — what the document describes, how the work will be done — then it is a method. I intuitively felt that it must have some connection to a method, because the document itself contains the word “method,” but I did not know how to express it. I would like to hear other opinions as well — whether they fully agree with this and whether they have different views. At this moment, this seems very convincing to me. When I mentioned “hybrid”, I was exploring whether the Method Statement could represent a combination of processes rather than a single PMBOK category. I also asked whether it could be considered a process at all. In my LinkedIn post, the third option was actually “HYBRID PROCESS: Combination of processes across the Delivery, Risk and Resource Performance domains.” When I decided to ask PMI, I deliberately removed the suggested options so as not to lead the answer, and that is how I submitted the question. However, at the last moment, I added “Artifact, Method or Hybrid?” to the title instead of “Hybrid Process.” That was my mistake and may have caused some ambiguity. At the end, you say that this is an analytical mapping using PMBOK terminology, and not an explicit PMI classification of the Method Statement. Since I also sent my question to the PMI Standards Team, it will be interesting to see their view and what the exact explicit PMI classification is. Thank you again for taking the time to give such a detailed answer. Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Thank you, Aleksandar. Your clarification about what you originally meant by “hybrid” adds an important dimension to the question.
Your description of your own practice is also particularly useful. Technical review and inspection, QA/QC requirements, standards and tolerances, followed by submission, review and approval by the supervisor, provide a concrete example of why I was reluctant to stop at “Artifact.” They show how a Method Statement, while remaining a documented output, can perform several functions within a construction delivery system.
I also think your interpretation of my Artifact/Method distinction is fair. The important qualification is the unit of analysis. If we are looking at the Method Statement as the documented output, Artifact remains the most direct PMBOK 7 classification. If we are looking at the underlying means by which the construction work is to be performed, we are closer to what PMBOK 7 calls a Method.
Your clarification of “Hybrid Process,” however, raises a different question.
I would distinguish four things: the Method Statement as a documented output; the method of performing the work that it describes; the workflow through which the Method Statement is developed, reviewed, submitted, approved, communicated, used and, where necessary, revised; and the functions that the Method Statement and its use perform across the project.
The workflow surrounding the Method Statement can certainly involve multiple processes. But classifying that workflow is different from classifying the Method Statement as a documented output. Describing, specifying or governing a process is not the same as being that process.
This is where I think your original intuition about “hybrid” becomes particularly interesting.
PMBOK 7 allows Models, Methods and Artifacts to be applicable or useful across more than one Performance Domain. Depending on its content, use and project context, a Method Statement can potentially contribute to Planning, Project Work, Delivery, Measurement and Uncertainty, and also to Stakeholder, Team and Development Approach and Life Cycle.
One terminology point is important. Within the PMBOK 7 architecture, Risk and Resource are not Performance Domains. Risk and resources remain important, of course, but they are addressed within and across that architecture.
For me, this leads to the key distinction:
Spanning multiple Performance Domains establishes functional reach; it does not, by itself, establish taxonomic identity.
So the fact that a Method Statement contributes to several Performance Domains does not, by itself, make it a “Hybrid Process.” Cross-domain applicability is already accommodated by the PMBOK 7 architecture.
I also checked this against PMI’s construction-specific framework. The PMI-CP Exam Content Outline uses a different domain architecture: Contracts Management, Stakeholder Engagement, Strategy and Scope Management, and Project Governance. The certification and its foundational training further illustrate how construction management functions interact across contracts and risk, interfaces, scope and change, and communications.
That reinforces, in my view, the integrative role that a Method Statement may perform in construction. I have not found PMI establishing “Hybrid Process” as a formal classification. More importantly, cross-domain applicability does not, by itself, require such a classification.
So I would refine my original answer rather than change it: Artifact remains the most direct classification when the unit of analysis is the Method Statement as a documented output. The underlying means of performing the work is closer to Method. The workflow surrounding its development and use can involve multiple processes, and its functions may span multiple Performance Domains. None of those observations, individually or together, requires us to classify the Method Statement itself as a “Hybrid Process.”
Your original “hybrid” intuition was therefore pointing, I think, to something real: the Method Statement can be highly integrative in practice. I would simply distinguish that functional integration from its formal classification.
And I agree that the response from the PMI Standards Team will be particularly interesting. I would be curious to see whether they distinguish between the document, the method it describes, the processes surrounding its development and use, and the functions it performs within the construction delivery system.
...
1 reply by Aleksandar Loncar
Oct 05, 2026 5:16 PM
Aleksandar Loncar
...
Luis, In your response, you have now made four levels of analysis: 1. The Method Statement as a documented output — Artifact. 2. The Method Statement describing the method by which the work is performed — Method. 3. The workflow surrounding the Method Statement — development, review, submission, approval, communication, use and revision — involving multiple processes. 4. The functions that the Method Statement performs within the project. So, it seems that we do not have simply Artifact / Method / Process (or Hybrid Process), but rather Artifact / Method / Workflow / Function. The most important part for me regarding the Hybrid Process is your definition: “Spanning multiple Performance Domains establishes functional reach; it does not, by itself, establish taxonomic identity.” This means that although a Method Statement may relate to multiple Performance Domains, that does not make it a Hybrid Process. It is rather a matter of its functional reach — its interaction with multiple areas. This brings us back to the question of whether the Method Statement is an Artifact or a Method. In other words, it can be both, depending on the perspective from which it is being observed. I am not familiar with PMI-CP, so I would not comment on that part.
Thank you, Aleksandar. Your clarification about what you originally meant by “hybrid” adds an important dimension to the question.
Your description of your own practice is also particularly useful. Technical review and inspection, QA/QC requirements, standards and tolerances, followed by submission, review and approval by the supervisor, provide a concrete example of why I was reluctant to stop at “Artifact.” They show how a Method Statement, while remaining a documented output, can perform several functions within a construction delivery system.
I also think your interpretation of my Artifact/Method distinction is fair. The important qualification is the unit of analysis. If we are looking at the Method Statement as the documented output, Artifact remains the most direct PMBOK 7 classification. If we are looking at the underlying means by which the construction work is to be performed, we are closer to what PMBOK 7 calls a Method.
Your clarification of “Hybrid Process,” however, raises a different question.
I would distinguish four things: the Method Statement as a documented output; the method of performing the work that it describes; the workflow through which the Method Statement is developed, reviewed, submitted, approved, communicated, used and, where necessary, revised; and the functions that the Method Statement and its use perform across the project.
The workflow surrounding the Method Statement can certainly involve multiple processes. But classifying that workflow is different from classifying the Method Statement as a documented output. Describing, specifying or governing a process is not the same as being that process.
This is where I think your original intuition about “hybrid” becomes particularly interesting.
PMBOK 7 allows Models, Methods and Artifacts to be applicable or useful across more than one Performance Domain. Depending on its content, use and project context, a Method Statement can potentially contribute to Planning, Project Work, Delivery, Measurement and Uncertainty, and also to Stakeholder, Team and Development Approach and Life Cycle.
One terminology point is important. Within the PMBOK 7 architecture, Risk and Resource are not Performance Domains. Risk and resources remain important, of course, but they are addressed within and across that architecture.
For me, this leads to the key distinction:
Spanning multiple Performance Domains establishes functional reach; it does not, by itself, establish taxonomic identity.
So the fact that a Method Statement contributes to several Performance Domains does not, by itself, make it a “Hybrid Process.” Cross-domain applicability is already accommodated by the PMBOK 7 architecture.
I also checked this against PMI’s construction-specific framework. The PMI-CP Exam Content Outline uses a different domain architecture: Contracts Management, Stakeholder Engagement, Strategy and Scope Management, and Project Governance. The certification and its foundational training further illustrate how construction management functions interact across contracts and risk, interfaces, scope and change, and communications.
That reinforces, in my view, the integrative role that a Method Statement may perform in construction. I have not found PMI establishing “Hybrid Process” as a formal classification. More importantly, cross-domain applicability does not, by itself, require such a classification.
So I would refine my original answer rather than change it: Artifact remains the most direct classification when the unit of analysis is the Method Statement as a documented output. The underlying means of performing the work is closer to Method. The workflow surrounding its development and use can involve multiple processes, and its functions may span multiple Performance Domains. None of those observations, individually or together, requires us to classify the Method Statement itself as a “Hybrid Process.”
Your original “hybrid” intuition was therefore pointing, I think, to something real: the Method Statement can be highly integrative in practice. I would simply distinguish that functional integration from its formal classification.
And I agree that the response from the PMI Standards Team will be particularly interesting. I would be curious to see whether they distinguish between the document, the method it describes, the processes surrounding its development and use, and the functions it performs within the construction delivery system.
Luis, In your response, you have now made four levels of analysis: 1. The Method Statement as a documented output — Artifact. 2. The Method Statement describing the method by which the work is performed — Method. 3. The workflow surrounding the Method Statement — development, review, submission, approval, communication, use and revision — involving multiple processes. 4. The functions that the Method Statement performs within the project. So, it seems that we do not have simply Artifact / Method / Process (or Hybrid Process), but rather Artifact / Method / Workflow / Function. The most important part for me regarding the Hybrid Process is your definition: “Spanning multiple Performance Domains establishes functional reach; it does not, by itself, establish taxonomic identity.” This means that although a Method Statement may relate to multiple Performance Domains, that does not make it a Hybrid Process. It is rather a matter of its functional reach — its interaction with multiple areas. This brings us back to the question of whether the Method Statement is an Artifact or a Method. In other words, it can be both, depending on the perspective from which it is being observed. I am not familiar with PMI-CP, so I would not comment on that part. Saving Changes...
PMI Team Member
