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 have now received a response from the PMI Standards Team regarding my question about Method Statements and the PMBOK Guide.
The response confirmed that neither PMBOK 7 nor PMBOK 8 explicitly includes guidance on Method Statements. However, the Standards Team took my question and ran it through PMI Infinity, PMI’s generative-AI tool for Project management, and shared the output with me for additional context. They noted that this output is not a formal summary or response from the development team. The PMI Infinity analysis frames a construction Method Statement most naturally as a “tailored project artifact” — a domain-specific project document that explains how a defined work package or activity will be performed, controlled and verified. It places the Method Statement at the work package/activity execution level, below the project management plan and its subsidiary plans. In practice, it may bring together elements such as sequence of work, resources, methods, constraints, inspections, acceptance criteria, and safety or environmental controls. The analysis also explains why Method Statements are not explicitly named in PMBOK. PMBOK is a cross-industry framework based on principles, rather than a catalogue of every industry’s operational documents. Construction uses Method Statements; other industries may use different documents for comparable execution purposes. A practical way to place it in a PMBOK hierarchy is: project management plan and subsidiary plans → baselines and control documents → work package/activity-level execution artifacts such as Method Statements. So, from the PMI perspective provided by this analysis, the question is not simply “Where is the Method Statement in PMBOK as a named document?” but rather “Which PMBOK functions does it serve?” The answer provided is that it serves as a tailored execution artifact that connects planning to field delivery in a construction context. At the same time, PMI’s response makes clear that this should not be interpreted as a formal PMI classification of Method Statements. It is, however, a useful practical way of understanding where this very construction-specific document fits within a broader project management framework.
I received a response from the PMI Serbia Chapter to my question. I am publishing it below as an integral text, without any modifications.
Method Statement is primarily an artifact, not a method. The reason is simple: in the PMI sense, a method denotes a way, technique, or approach by which something is achieved, whereas an artifact is a documented output, template, record, or other work product. If you have a document that describes the sequence of execution, resources, quality controls, risks, safety measures, responsibilities, and acceptance criteria, then that document itself is an artifact; the methods are what is described within it.
In other words, the most precise PMI interpretation would be: Method Statement = an artifact that documents one or more methods/procedures. That is why I would not classify it under "methods" as the primary category, unless you are referring to the execution technique itself rather than to the document.
As for PMBOK logic, the creation and use of such a document is not treated as an isolated activity of a single domain, but rather as the implementation of multiple performance domains simultaneously. In construction and industrial practice, it typically intersects at least the following: Scope, because it operationalizes how a specific portion of the work will be carried out; Schedule, because it affects the sequence and time frame of the works; Resources, because it defines people, equipment, and materials; Quality — or more broadly in PMBOK 8, through the corresponding governance/process mechanisms — because it establishes controls and criteria; Risk, because it introduces preventive measures and risk responses; and often Stakeholders and Governance as well, when it requires approvals, coordination of contractors, supervision, the investor, or the HSE function.
Therefore, I would formulate the recommended PMI model as follows: do not look for a single explicit PMBOK term that corresponds 1:1 to a Method Statement; instead, treat it as a tailored project artifact specific to the industry, which serves as a bridge between plans and execution. In other words, this is not a "gap" in your reading of the PMBOK, but rather a consequence of the fact that PMI deliberately leaves room for tailoring and for industry-specific documents that are not universally named in the standard.
The shortest conclusion is as follows: in PMI logic, a Method Statement most closely corresponds to an artifact, while the methods are contained within it; and its creation and application belong to multiple performance domains simultaneously, not to just one.
...
1 reply by Aleksandar Loncar
Oct 12, 2026 2:31 AM
Aleksandar Loncar
...
Luis,
I'm going back to your unit of analysis and 4 types of analysis. Now I'd like to try adding one more type of analysis.
RELATIONAL ANALYSIS
What is the relationship between the Method Statement and other documents in the project? The Method Statement is not an isolated document — it is part of the project documentation system.
HORIZONTAL PLANE (parallel relationship) On the same level, the Method Statement is connected and aligned with: Risk Assessment ITP — Inspection and Test Plan Their inclusion depends on the risk profile of the activity — low-risk works (e.g. Knauf partitions walls) do not require a Risk Assessment, while high-risk works (e.g. main truss erection) do. Not only are they connected, but they must be mutually aligned in both directions — a change in one requires review and update of the other.
VERTICAL PLANE (hierarchical relationship) The Method Statement is connected with: Contract Technical Specifications Project Documentation (detailed design for construction ) Standards Project Management Plan
For example, the Method Statement must comply with the requirements of the project (design) and the technical specifications.
I received a response from the PMI Serbia Chapter to my question. I am publishing it below as an integral text, without any modifications.
Method Statement is primarily an artifact, not a method. The reason is simple: in the PMI sense, a method denotes a way, technique, or approach by which something is achieved, whereas an artifact is a documented output, template, record, or other work product. If you have a document that describes the sequence of execution, resources, quality controls, risks, safety measures, responsibilities, and acceptance criteria, then that document itself is an artifact; the methods are what is described within it.
In other words, the most precise PMI interpretation would be: Method Statement = an artifact that documents one or more methods/procedures. That is why I would not classify it under "methods" as the primary category, unless you are referring to the execution technique itself rather than to the document.
As for PMBOK logic, the creation and use of such a document is not treated as an isolated activity of a single domain, but rather as the implementation of multiple performance domains simultaneously. In construction and industrial practice, it typically intersects at least the following: Scope, because it operationalizes how a specific portion of the work will be carried out; Schedule, because it affects the sequence and time frame of the works; Resources, because it defines people, equipment, and materials; Quality — or more broadly in PMBOK 8, through the corresponding governance/process mechanisms — because it establishes controls and criteria; Risk, because it introduces preventive measures and risk responses; and often Stakeholders and Governance as well, when it requires approvals, coordination of contractors, supervision, the investor, or the HSE function.
Therefore, I would formulate the recommended PMI model as follows: do not look for a single explicit PMBOK term that corresponds 1:1 to a Method Statement; instead, treat it as a tailored project artifact specific to the industry, which serves as a bridge between plans and execution. In other words, this is not a "gap" in your reading of the PMBOK, but rather a consequence of the fact that PMI deliberately leaves room for tailoring and for industry-specific documents that are not universally named in the standard.
The shortest conclusion is as follows: in PMI logic, a Method Statement most closely corresponds to an artifact, while the methods are contained within it; and its creation and application belong to multiple performance domains simultaneously, not to just one.
Luis,
I'm going back to your unit of analysis and 4 types of analysis. Now I'd like to try adding one more type of analysis.
RELATIONAL ANALYSIS
What is the relationship between the Method Statement and other documents in the project? The Method Statement is not an isolated document — it is part of the project documentation system.
HORIZONTAL PLANE (parallel relationship) On the same level, the Method Statement is connected and aligned with: Risk Assessment ITP — Inspection and Test Plan Their inclusion depends on the risk profile of the activity — low-risk works (e.g. Knauf partitions walls) do not require a Risk Assessment, while high-risk works (e.g. main truss erection) do. Not only are they connected, but they must be mutually aligned in both directions — a change in one requires review and update of the other.
VERTICAL PLANE (hierarchical relationship) The Method Statement is connected with: Contract Technical Specifications Project Documentation (detailed design for construction ) Standards Project Management Plan
For example, the Method Statement must comply with the requirements of the project (design) and the technical specifications.
Could this be considered a new type of analysis?
...
1 reply by Aleksandar Loncar
Oct 23, 2026 1:54 AM
Aleksandar Loncar
...
I have come across the concept of diagonal relationships between documents within a project documentation system. Which project documents have diagonal relationships with a Method Statement? Are these the Project Schedule, Bill of Quantities (BoQ), or other documents?
I'm going back to your unit of analysis and 4 types of analysis. Now I'd like to try adding one more type of analysis.
RELATIONAL ANALYSIS
What is the relationship between the Method Statement and other documents in the project? The Method Statement is not an isolated document — it is part of the project documentation system.
HORIZONTAL PLANE (parallel relationship) On the same level, the Method Statement is connected and aligned with: Risk Assessment ITP — Inspection and Test Plan Their inclusion depends on the risk profile of the activity — low-risk works (e.g. Knauf partitions walls) do not require a Risk Assessment, while high-risk works (e.g. main truss erection) do. Not only are they connected, but they must be mutually aligned in both directions — a change in one requires review and update of the other.
VERTICAL PLANE (hierarchical relationship) The Method Statement is connected with: Contract Technical Specifications Project Documentation (detailed design for construction ) Standards Project Management Plan
For example, the Method Statement must comply with the requirements of the project (design) and the technical specifications.
Could this be considered a new type of analysis?
I have come across the concept of diagonal relationships between documents within a project documentation system. Which project documents have diagonal relationships with a Method Statement? Are these the Project Schedule, Bill of Quantities (BoQ), or other documents? Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Thank you, Aleksandar. Your proposal for Relational Analysis raises an important question about how we examine Method Statements within the wider project system.
A Method Statement does not exist in isolation. Its relationships with other documents, requirements, activities, decisions and authorities can be essential to understanding how work is planned, coordinated and executed.
The four perspectives we previously distinguished examine different aspects: the Method Statement as a documented artifact, the method of performing the work that it describes, the workflows associated with its development and use, and the functions it performs within the project.
Relational Analysis brings another question into focus: what can we learn by examining the relationships and interdependencies themselves, rather than considering the connected elements individually?
Consider a change in the lifting equipment specified in a Method Statement. It may affect the lifting plan, risk assessment, inspection arrangements, schedule or existing authorizations. Not every related document necessarily requires revision, but the relevant dependencies, requirements and consequences need to be assessed.
This illustrates why explicit relational analysis matters. What remains open is its place within the analytical framework.
It could constitute a fifth perspective with a distinct unit of analysis. It could operate across the existing four perspectives, or its contribution might be incorporated into them. Each possibility deserves consideration based on what it allows us to distinguish, explain and assess.
I would also distinguish the nature of a relationship from how it is represented. Horizontal, vertical and diagonal arrangements may be useful in a particular document map, but their geometry does not, by itself, establish distinct relationship types. A Method Statement's connection with a Project Schedule or Bill of Quantities needs to be understood through the actual dependencies, requirements and coordination mechanisms involved.
For me, the strongest contribution of your proposal is the recognition that examining project elements individually may not be sufficient to understand the consequences of their interactions.
The next question is therefore not simply whether we should add another category, but what difference each analytical approach makes to our understanding of the project.
What would Relational Analysis reveal, explain or help us assess that might otherwise remain overlooked, and under what conditions would treating it as a separate perspective make a meaningful difference?
...
1 reply by Aleksandar Loncar
Oct 27, 2026 3:24 AM
Aleksandar Loncar
...
Luis,
Thank you for your detailed comments. I am preparing a reply to your questions on the Relational Analysis, which I will post in about a week. In the meantime, I want to continue with the development of the analysis. I will publish my next dimension — the Phase Analysis — in my upcoming post. I look forward to your thoughts on it.
Thank you, Aleksandar. Your proposal for Relational Analysis raises an important question about how we examine Method Statements within the wider project system.
A Method Statement does not exist in isolation. Its relationships with other documents, requirements, activities, decisions and authorities can be essential to understanding how work is planned, coordinated and executed.
The four perspectives we previously distinguished examine different aspects: the Method Statement as a documented artifact, the method of performing the work that it describes, the workflows associated with its development and use, and the functions it performs within the project.
Relational Analysis brings another question into focus: what can we learn by examining the relationships and interdependencies themselves, rather than considering the connected elements individually?
Consider a change in the lifting equipment specified in a Method Statement. It may affect the lifting plan, risk assessment, inspection arrangements, schedule or existing authorizations. Not every related document necessarily requires revision, but the relevant dependencies, requirements and consequences need to be assessed.
This illustrates why explicit relational analysis matters. What remains open is its place within the analytical framework.
It could constitute a fifth perspective with a distinct unit of analysis. It could operate across the existing four perspectives, or its contribution might be incorporated into them. Each possibility deserves consideration based on what it allows us to distinguish, explain and assess.
I would also distinguish the nature of a relationship from how it is represented. Horizontal, vertical and diagonal arrangements may be useful in a particular document map, but their geometry does not, by itself, establish distinct relationship types. A Method Statement's connection with a Project Schedule or Bill of Quantities needs to be understood through the actual dependencies, requirements and coordination mechanisms involved.
For me, the strongest contribution of your proposal is the recognition that examining project elements individually may not be sufficient to understand the consequences of their interactions.
The next question is therefore not simply whether we should add another category, but what difference each analytical approach makes to our understanding of the project.
What would Relational Analysis reveal, explain or help us assess that might otherwise remain overlooked, and under what conditions would treating it as a separate perspective make a meaningful difference?
Luis,
Thank you for your detailed comments. I am preparing a reply to your questions on the Relational Analysis, which I will post in about a week. In the meantime, I want to continue with the development of the analysis. I will publish my next dimension — the Phase Analysis — in my upcoming post. I look forward to your thoughts on it.
...
1 reply by Aleksandar Loncar
Oct 27, 2026 3:53 AM
Aleksandar Loncar
...
I have not adapted this text specifically for the comments section. Instead, I am sharing the full section of my paper dealing with the phase analysis of the Method Statement.
PHASE ANALYSIS
Where and when does the Method Statement appear?
Although the theoretical framework of this paper primarily relies on PMBOK 7, a reference to the PMBOK Guide – Eighth Edition is necessary for the purposes of phase analysis. While the seventh edition eliminated the traditional process-based structure, PMBOK 8 reintegrates the process approach through its domains.
If we examine the PMBOK Guide – Eighth Edition and the processes within the Governance Performance Domain, the dynamic nature of this document becomes most apparent. We can observe that the Method Statement changes its position depending on the project phase. This is most clearly illustrated through the ITTO models (Inputs, Tools & Techniques, Outputs).
ITTO Models and the Position of the Method Statement:
In the Integrate and Align Project Plans process — the Method Statement would be an output. Planning phase. In this phase, the Method Statement is the intended outcome. It is developed during this process.
In the Manage Project Execution process — the Method Statement would be an input. It could be included as an item under Project Documents. Execution phase. Once construction works begin, the Method Statement becomes an operational document. It serves as an instruction and a guide defining how the work must be carried out, that is, how the construction activities are to be executed.
In the Manage Quality Assurance process — the Method Statement would also be an input. Control phase. It becomes the benchmark and the officially approved reference standard against which supervision and quality control managers verify whether the works on site are being carried out exactly as agreed and approved.
Therefore, the Method Statement changes its position depending on the process.
During the execution of works, the Method Statement serves as a control document or an operational document.
At the end of the project, it can also be regarded as and serve as evidence that the works were executed in accordance with it.
If changes to the execution of works are planned, it is good practice to revise the Method Statement — so that the execution of works is once again in accordance with it. This is consistent with the Assess and Implement Changes process. The revision ensures that the document is once again fully aligned with the actual conditions on site. The Method Statement evolves along with the project.
This means that the document is not static but adapts to changing circumstances.
In this way, at the completion of the works, the Method Statement can still serve as evidence (Archive) — because it has been revised and aligned with the actual execution of works. It constitutes documentary evidence that the works were carried out safely, in accordance with established procedures and contractual requirements, thereby protecting the contractor against subsequent claims or legal disputes. In the event of litigation, arbitration, or investigations into site incidents, the approved Method Statement is among the first documents requested. It establishes the exact procedures and safety measures that the contractor was required to follow when executing the works.
I am aware that the primary documentary evidence on a project consists of site records confirming the actual execution and quality of the works — such as RFIs (Requests for Inspection), MARs (Material Approval Forms), Construction Diaries, Laboratory Reports, Monthly Reports, Checklists, and ITP Forms. Nevertheless, I believe that the Method Statement can also serve as evidence.
When compared with RFI forms and checklists, the approved Method Statement demonstrates that the project was not carried out based on guesswork, but according to a verified, safe, and documented method. This is important because what is not documented "did not happen".
Thank you for your detailed comments. I am preparing a reply to your questions on the Relational Analysis, which I will post in about a week. In the meantime, I want to continue with the development of the analysis. I will publish my next dimension — the Phase Analysis — in my upcoming post. I look forward to your thoughts on it.
I have not adapted this text specifically for the comments section. Instead, I am sharing the full section of my paper dealing with the phase analysis of the Method Statement.
PHASE ANALYSIS
Where and when does the Method Statement appear?
Although the theoretical framework of this paper primarily relies on PMBOK 7, a reference to the PMBOK Guide – Eighth Edition is necessary for the purposes of phase analysis. While the seventh edition eliminated the traditional process-based structure, PMBOK 8 reintegrates the process approach through its domains.
If we examine the PMBOK Guide – Eighth Edition and the processes within the Governance Performance Domain, the dynamic nature of this document becomes most apparent. We can observe that the Method Statement changes its position depending on the project phase. This is most clearly illustrated through the ITTO models (Inputs, Tools & Techniques, Outputs).
ITTO Models and the Position of the Method Statement:
In the Integrate and Align Project Plans process — the Method Statement would be an output. Planning phase. In this phase, the Method Statement is the intended outcome. It is developed during this process.
In the Manage Project Execution process — the Method Statement would be an input. It could be included as an item under Project Documents. Execution phase. Once construction works begin, the Method Statement becomes an operational document. It serves as an instruction and a guide defining how the work must be carried out, that is, how the construction activities are to be executed.
In the Manage Quality Assurance process — the Method Statement would also be an input. Control phase. It becomes the benchmark and the officially approved reference standard against which supervision and quality control managers verify whether the works on site are being carried out exactly as agreed and approved.
Therefore, the Method Statement changes its position depending on the process.
During the execution of works, the Method Statement serves as a control document or an operational document.
At the end of the project, it can also be regarded as and serve as evidence that the works were executed in accordance with it.
If changes to the execution of works are planned, it is good practice to revise the Method Statement — so that the execution of works is once again in accordance with it. This is consistent with the Assess and Implement Changes process. The revision ensures that the document is once again fully aligned with the actual conditions on site. The Method Statement evolves along with the project.
This means that the document is not static but adapts to changing circumstances.
In this way, at the completion of the works, the Method Statement can still serve as evidence (Archive) — because it has been revised and aligned with the actual execution of works. It constitutes documentary evidence that the works were carried out safely, in accordance with established procedures and contractual requirements, thereby protecting the contractor against subsequent claims or legal disputes. In the event of litigation, arbitration, or investigations into site incidents, the approved Method Statement is among the first documents requested. It establishes the exact procedures and safety measures that the contractor was required to follow when executing the works.
I am aware that the primary documentary evidence on a project consists of site records confirming the actual execution and quality of the works — such as RFIs (Requests for Inspection), MARs (Material Approval Forms), Construction Diaries, Laboratory Reports, Monthly Reports, Checklists, and ITP Forms. Nevertheless, I believe that the Method Statement can also serve as evidence.
When compared with RFI forms and checklists, the approved Method Statement demonstrates that the project was not carried out based on guesswork, but according to a verified, safe, and documented method. This is important because what is not documented "did not happen".
...
1 reply by Luis Branco
Oct 27, 2026 12:13 PM
Luis Branco
...
Thank you, Aleksandar. I appreciate how you are continuing to develop this analysis, and I look forward to your further reflections on Relational Analysis.
Your Phase Analysis introduces an important consideration: a Method Statement may serve different purposes as the project progresses. It can be developed and approved, used to guide execution, reviewed when conditions change, and retained as part of the project records.
I would, however, distinguish a change in the document's role within a process from a change in its classification. Being an output of one process and an input to another does not necessarily change its identity as an artifact.
There is also an important distinction concerning evidence. An approved Method Statement can establish what was planned, specified or authorized. It does not, by itself, establish that the work was actually performed in accordance with those requirements. That requires evidence of execution, inspection and verification, assessed in its proper context.
Similarly, revising a Method Statement can help maintain alignment with changing site conditions, but revision alone does not demonstrate that the revised method was implemented or that earlier work was compliant.
This is where I see particular value in your temporal perspective: examining not only which role the document performs, but also when requirements were approved, when changes occurred, which version was applicable and what evidence supports the execution that followed.
Whether Phase Analysis warrants a separate analytical dimension, or operates across the perspectives we have already discussed, remains an open question. Its value should depend on what it helps us understand or assess that might otherwise be overlooked.
Perhaps the most useful question is: how can Phase Analysis help us distinguish what was intended and approved, what was actually executed, and what the available evidence allows us to conclude?
Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Oct 27, 2026 3:53 AM
Replying to Aleksandar Loncar
...
I have not adapted this text specifically for the comments section. Instead, I am sharing the full section of my paper dealing with the phase analysis of the Method Statement.
PHASE ANALYSIS
Where and when does the Method Statement appear?
Although the theoretical framework of this paper primarily relies on PMBOK 7, a reference to the PMBOK Guide – Eighth Edition is necessary for the purposes of phase analysis. While the seventh edition eliminated the traditional process-based structure, PMBOK 8 reintegrates the process approach through its domains.
If we examine the PMBOK Guide – Eighth Edition and the processes within the Governance Performance Domain, the dynamic nature of this document becomes most apparent. We can observe that the Method Statement changes its position depending on the project phase. This is most clearly illustrated through the ITTO models (Inputs, Tools & Techniques, Outputs).
ITTO Models and the Position of the Method Statement:
In the Integrate and Align Project Plans process — the Method Statement would be an output. Planning phase. In this phase, the Method Statement is the intended outcome. It is developed during this process.
In the Manage Project Execution process — the Method Statement would be an input. It could be included as an item under Project Documents. Execution phase. Once construction works begin, the Method Statement becomes an operational document. It serves as an instruction and a guide defining how the work must be carried out, that is, how the construction activities are to be executed.
In the Manage Quality Assurance process — the Method Statement would also be an input. Control phase. It becomes the benchmark and the officially approved reference standard against which supervision and quality control managers verify whether the works on site are being carried out exactly as agreed and approved.
Therefore, the Method Statement changes its position depending on the process.
During the execution of works, the Method Statement serves as a control document or an operational document.
At the end of the project, it can also be regarded as and serve as evidence that the works were executed in accordance with it.
If changes to the execution of works are planned, it is good practice to revise the Method Statement — so that the execution of works is once again in accordance with it. This is consistent with the Assess and Implement Changes process. The revision ensures that the document is once again fully aligned with the actual conditions on site. The Method Statement evolves along with the project.
This means that the document is not static but adapts to changing circumstances.
In this way, at the completion of the works, the Method Statement can still serve as evidence (Archive) — because it has been revised and aligned with the actual execution of works. It constitutes documentary evidence that the works were carried out safely, in accordance with established procedures and contractual requirements, thereby protecting the contractor against subsequent claims or legal disputes. In the event of litigation, arbitration, or investigations into site incidents, the approved Method Statement is among the first documents requested. It establishes the exact procedures and safety measures that the contractor was required to follow when executing the works.
I am aware that the primary documentary evidence on a project consists of site records confirming the actual execution and quality of the works — such as RFIs (Requests for Inspection), MARs (Material Approval Forms), Construction Diaries, Laboratory Reports, Monthly Reports, Checklists, and ITP Forms. Nevertheless, I believe that the Method Statement can also serve as evidence.
When compared with RFI forms and checklists, the approved Method Statement demonstrates that the project was not carried out based on guesswork, but according to a verified, safe, and documented method. This is important because what is not documented "did not happen".
Thank you, Aleksandar. I appreciate how you are continuing to develop this analysis, and I look forward to your further reflections on Relational Analysis.
Your Phase Analysis introduces an important consideration: a Method Statement may serve different purposes as the project progresses. It can be developed and approved, used to guide execution, reviewed when conditions change, and retained as part of the project records.
I would, however, distinguish a change in the document's role within a process from a change in its classification. Being an output of one process and an input to another does not necessarily change its identity as an artifact.
There is also an important distinction concerning evidence. An approved Method Statement can establish what was planned, specified or authorized. It does not, by itself, establish that the work was actually performed in accordance with those requirements. That requires evidence of execution, inspection and verification, assessed in its proper context.
Similarly, revising a Method Statement can help maintain alignment with changing site conditions, but revision alone does not demonstrate that the revised method was implemented or that earlier work was compliant.
This is where I see particular value in your temporal perspective: examining not only which role the document performs, but also when requirements were approved, when changes occurred, which version was applicable and what evidence supports the execution that followed.
Whether Phase Analysis warrants a separate analytical dimension, or operates across the perspectives we have already discussed, remains an open question. Its value should depend on what it helps us understand or assess that might otherwise be overlooked.
Perhaps the most useful question is: how can Phase Analysis help us distinguish what was intended and approved, what was actually executed, and what the available evidence allows us to conclude?
...
1 reply by Aleksandar Loncar
Oct 28, 2026 10:49 AM
Aleksandar Loncar
...
Luis,
My Phase Analysis addresses the question: How does the Method Statement develop, change, and function throughout the project life cycle? It examines not only its position as an input or output, but also its operational, control and evidentiary functions over time. This demonstrates the dynamic nature of the document. When I stated that the Method Statement changes its position, serving as an input in some processes and an output in others, I was not suggesting that it ceases to be an artifact. I was referring to changes in its position and function across different processes. I agree that an approved or revised Method Statement does not, by itself, prove that the works were executed in accordance with it. This requires appropriate execution and inspection records. However, linking different versions of the document to these records over time further demonstrates the value of Phase Analysis. For example, if the construction methodology is changed before a particular activity begins and Method Statement Rev. 01 is approved, Phase Analysis makes it possible to establish when the new version became effective and to link the relevant RFIs, ITP forms, and Construction Diary entries to the works carried out after its approval. In this way, it is possible to verify whether the works were actually executed in accordance with the applicable methodology. If the Method Statement remains an artifact throughout the project, does its classification as an artifact sufficiently explain its operational, control, and evidentiary functions over time?
Thank you, Aleksandar. I appreciate how you are continuing to develop this analysis, and I look forward to your further reflections on Relational Analysis.
Your Phase Analysis introduces an important consideration: a Method Statement may serve different purposes as the project progresses. It can be developed and approved, used to guide execution, reviewed when conditions change, and retained as part of the project records.
I would, however, distinguish a change in the document's role within a process from a change in its classification. Being an output of one process and an input to another does not necessarily change its identity as an artifact.
There is also an important distinction concerning evidence. An approved Method Statement can establish what was planned, specified or authorized. It does not, by itself, establish that the work was actually performed in accordance with those requirements. That requires evidence of execution, inspection and verification, assessed in its proper context.
Similarly, revising a Method Statement can help maintain alignment with changing site conditions, but revision alone does not demonstrate that the revised method was implemented or that earlier work was compliant.
This is where I see particular value in your temporal perspective: examining not only which role the document performs, but also when requirements were approved, when changes occurred, which version was applicable and what evidence supports the execution that followed.
Whether Phase Analysis warrants a separate analytical dimension, or operates across the perspectives we have already discussed, remains an open question. Its value should depend on what it helps us understand or assess that might otherwise be overlooked.
Perhaps the most useful question is: how can Phase Analysis help us distinguish what was intended and approved, what was actually executed, and what the available evidence allows us to conclude?
Luis,
My Phase Analysis addresses the question: How does the Method Statement develop, change, and function throughout the project life cycle? It examines not only its position as an input or output, but also its operational, control and evidentiary functions over time. This demonstrates the dynamic nature of the document. When I stated that the Method Statement changes its position, serving as an input in some processes and an output in others, I was not suggesting that it ceases to be an artifact. I was referring to changes in its position and function across different processes. I agree that an approved or revised Method Statement does not, by itself, prove that the works were executed in accordance with it. This requires appropriate execution and inspection records. However, linking different versions of the document to these records over time further demonstrates the value of Phase Analysis. For example, if the construction methodology is changed before a particular activity begins and Method Statement Rev. 01 is approved, Phase Analysis makes it possible to establish when the new version became effective and to link the relevant RFIs, ITP forms, and Construction Diary entries to the works carried out after its approval. In this way, it is possible to verify whether the works were actually executed in accordance with the applicable methodology. If the Method Statement remains an artifact throughout the project, does its classification as an artifact sufficiently explain its operational, control, and evidentiary functions over time?
...
2 replies by Aleksandar Loncar and Luis Branco
Oct 28, 2026 10:56 AM
Aleksandar Loncar
...
Addition Dynamic nature of the document — 1. Development of Method Statements 2. Application 3. Revisions 4. Alignment with actual execution 5. Archival value
Oct 28, 2026 11:22 AM
Luis Branco
...
Thank you, Aleksandar. Your clarification and the Rev. 01 example make the practical contribution of Phase Analysis much clearer.
I agree that classifying a Method Statement as an artifact does not, by itself, explain its operational, control and evidentiary functions over time. Nor should it be expected to. The classification identifies the nature of the documented output, while the other perspectives help us understand how it is developed, used and connected to project execution.
Your example adds an important temporal dimension: establishing which version was applicable at a particular point, when it was approved and how it relates to the corresponding execution and inspection records.
I would add one distinction. Approval, applicability, communication, actual use and demonstrated compliance are related, but they are not necessarily equivalent. Even when a revised Method Statement is approved before an activity begins, we still need to establish whether the applicable requirements reached those performing the work and whether the available evidence supports the conclusion that they were followed.
This also relates to your five elements of the document's dynamic nature. Development, application, revision, alignment with execution and archival value provide a useful basis for examining its evolution. Importantly, alignment with actual execution needs to be assessed throughout the work, rather than assumed to result from revision.
For me, this strengthens the practical value of a temporal perspective. Whether Phase Analysis is best understood as a separate dimension or as an approach operating across Workflow, Function and Relational Analysis remains open. Its usefulness does not depend on resolving that question immediately.
Perhaps the most productive test is whether Phase Analysis helps us identify and explain gaps between the applicable methodology, the decisions and communications surrounding it, and the execution that the available evidence allows us to establish, particularly when these elements evolve at different times.
I look forward to seeing how you develop this perspective further.
My Phase Analysis addresses the question: How does the Method Statement develop, change, and function throughout the project life cycle? It examines not only its position as an input or output, but also its operational, control and evidentiary functions over time. This demonstrates the dynamic nature of the document. When I stated that the Method Statement changes its position, serving as an input in some processes and an output in others, I was not suggesting that it ceases to be an artifact. I was referring to changes in its position and function across different processes. I agree that an approved or revised Method Statement does not, by itself, prove that the works were executed in accordance with it. This requires appropriate execution and inspection records. However, linking different versions of the document to these records over time further demonstrates the value of Phase Analysis. For example, if the construction methodology is changed before a particular activity begins and Method Statement Rev. 01 is approved, Phase Analysis makes it possible to establish when the new version became effective and to link the relevant RFIs, ITP forms, and Construction Diary entries to the works carried out after its approval. In this way, it is possible to verify whether the works were actually executed in accordance with the applicable methodology. If the Method Statement remains an artifact throughout the project, does its classification as an artifact sufficiently explain its operational, control, and evidentiary functions over time?
Addition Dynamic nature of the document — 1. Development of Method Statements 2. Application 3. Revisions 4. Alignment with actual execution 5. Archival value Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Oct 28, 2026 10:49 AM
Replying to Aleksandar Loncar
...
Luis,
My Phase Analysis addresses the question: How does the Method Statement develop, change, and function throughout the project life cycle? It examines not only its position as an input or output, but also its operational, control and evidentiary functions over time. This demonstrates the dynamic nature of the document. When I stated that the Method Statement changes its position, serving as an input in some processes and an output in others, I was not suggesting that it ceases to be an artifact. I was referring to changes in its position and function across different processes. I agree that an approved or revised Method Statement does not, by itself, prove that the works were executed in accordance with it. This requires appropriate execution and inspection records. However, linking different versions of the document to these records over time further demonstrates the value of Phase Analysis. For example, if the construction methodology is changed before a particular activity begins and Method Statement Rev. 01 is approved, Phase Analysis makes it possible to establish when the new version became effective and to link the relevant RFIs, ITP forms, and Construction Diary entries to the works carried out after its approval. In this way, it is possible to verify whether the works were actually executed in accordance with the applicable methodology. If the Method Statement remains an artifact throughout the project, does its classification as an artifact sufficiently explain its operational, control, and evidentiary functions over time?
Thank you, Aleksandar. Your clarification and the Rev. 01 example make the practical contribution of Phase Analysis much clearer.
I agree that classifying a Method Statement as an artifact does not, by itself, explain its operational, control and evidentiary functions over time. Nor should it be expected to. The classification identifies the nature of the documented output, while the other perspectives help us understand how it is developed, used and connected to project execution.
Your example adds an important temporal dimension: establishing which version was applicable at a particular point, when it was approved and how it relates to the corresponding execution and inspection records.
I would add one distinction. Approval, applicability, communication, actual use and demonstrated compliance are related, but they are not necessarily equivalent. Even when a revised Method Statement is approved before an activity begins, we still need to establish whether the applicable requirements reached those performing the work and whether the available evidence supports the conclusion that they were followed.
This also relates to your five elements of the document's dynamic nature. Development, application, revision, alignment with execution and archival value provide a useful basis for examining its evolution. Importantly, alignment with actual execution needs to be assessed throughout the work, rather than assumed to result from revision.
For me, this strengthens the practical value of a temporal perspective. Whether Phase Analysis is best understood as a separate dimension or as an approach operating across Workflow, Function and Relational Analysis remains open. Its usefulness does not depend on resolving that question immediately.
Perhaps the most productive test is whether Phase Analysis helps us identify and explain gaps between the applicable methodology, the decisions and communications surrounding it, and the execution that the available evidence allows us to establish, particularly when these elements evolve at different times.
I look forward to seeing how you develop this perspective further. Saving Changes...
