[post] Foundations of Project Management - Part 2

data/diagrams/0072-triple-constraint-agile.drawio

@@ -0,0 +1,52 @@
+<mxfile host="app.diagrams.net" agent="Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36" version="26.0.1">
+  <diagram name="Page-1" id="xB2KGPDMb64g68ENrzL8">
+    <mxGraphModel dx="1277" dy="895" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0">
+      <root>
+        <mxCell id="0" />
+        <mxCell id="1" parent="0" />
+        <mxCell id="FsNgGGdD4rKOkY8G807n-1" value=" " style="rounded=1;whiteSpace=wrap;html=1;fillColor=#EDEDED;" vertex="1" parent="1">
+          <mxGeometry x="50" y="250" width="750" height="130" as="geometry" />
+        </mxCell>
+        <mxCell id="FsNgGGdD4rKOkY8G807n-2" value="" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#EDEDED;" vertex="1" parent="1">
+          <mxGeometry x="50" y="390" width="750" height="130" as="geometry" />
+        </mxCell>
+        <mxCell id="FsNgGGdD4rKOkY8G807n-3" value="&lt;b&gt;&lt;font style=&quot;font-size: 14px;&quot;&gt;Fixed&lt;/font&gt;&lt;/b&gt;" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" vertex="1" parent="1">
+          <mxGeometry x="60" y="300" width="60" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="FsNgGGdD4rKOkY8G807n-4" value="Flexible" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontStyle=1;fontSize=14;" vertex="1" parent="1">
+          <mxGeometry x="60" y="440" width="60" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="FsNgGGdD4rKOkY8G807n-5" value="" style="triangle;whiteSpace=wrap;html=1;rotation=-90;" vertex="1" parent="1">
+          <mxGeometry x="240" y="270" width="170" height="220" as="geometry" />
+        </mxCell>
+        <mxCell id="FsNgGGdD4rKOkY8G807n-6" value="" style="triangle;whiteSpace=wrap;html=1;rotation=90;" vertex="1" parent="1">
+          <mxGeometry x="530" y="270" width="170" height="220" as="geometry" />
+        </mxCell>
+        <mxCell id="FsNgGGdD4rKOkY8G807n-7" value="Cost" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontStyle=1" vertex="1" parent="1">
+          <mxGeometry x="180" y="470" width="60" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="FsNgGGdD4rKOkY8G807n-8" value="Schedule" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontStyle=1" vertex="1" parent="1">
+          <mxGeometry x="400" y="470" width="60" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="FsNgGGdD4rKOkY8G807n-9" value="Scope&lt;br&gt;(well defined)" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontStyle=1" vertex="1" parent="1">
+          <mxGeometry x="277.5" y="260" width="95" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="FsNgGGdD4rKOkY8G807n-10" value="Scope&lt;br&gt;(definition evolves)" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontStyle=1" vertex="1" parent="1">
+          <mxGeometry x="558.75" y="470" width="112.5" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="FsNgGGdD4rKOkY8G807n-11" value="Cost &lt;br&gt;(for sprint)" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontStyle=1" vertex="1" parent="1">
+          <mxGeometry x="470" y="260" width="70" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="FsNgGGdD4rKOkY8G807n-12" value="Schedule&lt;br&gt;(for sprint)" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontStyle=1" vertex="1" parent="1">
+          <mxGeometry x="690" y="260" width="70" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="FsNgGGdD4rKOkY8G807n-13" value="Traditional Plan-driven" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontStyle=1" vertex="1" parent="1">
+          <mxGeometry x="290" y="400" width="70" height="30" as="geometry" />
+        </mxCell>
+        <mxCell id="FsNgGGdD4rKOkY8G807n-14" value="Agile &lt;br&gt;(evolving requirements &amp;amp; planning on the fly)" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontStyle=1" vertex="1" parent="1">
+          <mxGeometry x="558.75" y="320" width="120" height="30" as="geometry" />
+        </mxCell>
+      </root>
+    </mxGraphModel>
+  </diagram>
+</mxfile>

data/posts/0071-foundations-of-project-management-part1.md

@@ -1,5 +1,5 @@
 !! title: Foundations of Project Management - Part 1
-!! slug: Foundations-of-project-management-part1
+!! slug: foundations-of-project-management-part1
 !! published: 2024-12-15
 !! description: Part one of the Foundations of Project Management series: a class summary and the lessons learned applied to the software industry
 

data/posts/0072-foundations-of-project-management-part2.md

@@ -0,0 +1,121 @@
+!! title: Foundations of Project Management - Part 2
+!! slug: foundations-of-project-management-part2
+!! published: 2024-12-30
+!! description: Part two of the Foundations of Project Management series: a class summary and the lessons learned applied to the software industry
+
+---
+
+Project management can be a very sensitive topic in the software industry. From my personal
+experience, discussions between frameworks and approaches can quickly turn into lines being drawn
+and choosing hills to die on. Often there is a split between the engineering function and the
+business function where Agile is the champion of the engineers and a traditional plan-driven
+approach is the champion for the business functions. 
+
+Sales and marketing teams function need specific dates and deadlines in order to collaborate with
+external partners for press release go-to-market launches. Engineers are hesitant to commit to
+specific deadlines because product development work is often filled with ambiguity where a timeline
+for completion may not be known. Ambiguity may be higher in the case where the product or technology
+is a new-to-the-world innovation.
+
+Even inside the software industry there are some software teams that have found that plan-driven
+project management is more successful than an agile-based framework. I recently had a conversation
+with a software engineer that works on the user interfaces for aircraft flight decks in the
+aerospace industry. They mentioned that "Agile" is a taboo idea in the industry: one where software
+cannot be iterated as frequently and failures can be catastrophic and must be avoided at all costs.
+
+
+## Foundations of Project Management and Agile
+
+There is a large amount of literature on the success of both plan-driven project management and
+Agile project management. As such, I can hear the question being asked: "If there are examples of
+both succeeding, which is correct?"
+
+I think this is wrong question to be asking. It was certainly the wrong question to be asking going
+into a course on the _Foundations of Project Management_. The PMBOK provides the _standard_ of
+project management: what needs to be done regardless of the _framework_ that is chosen for the
+project (Schwable p.79). As an example, the PMBOK states that a communication management plan is
+important for the success of any project. Such a plan answers the questions: How will the team
+communicate on a daily basis? What communication channels should be used in the event of an urgent
+task? How should stakeholders be kept up-to-date? Who owns the project status reports? These
+questions are important to the success of any project, no matter if a plan-driven framework or an
+Agile framework is chosen for management. 
+
+As we discussed in [Part 5](/post/engineering-portfolio-management-part5) of the _Engineering
+Portfolio Management_ series, some project characteristics lend themselves better to one framework
+over another (Cooper p.188). Every project is unique and will require a unique approach to deliver
+successfully. No two projects will have the same scope, schedule, budget, stakeholders, project
+team, etc. Some projects will require a lot of upfront planning, while others will require more
+flexibility in requirements. As a quick review of the characteristics we discussed in 
+[Part 5](/post/engineering-portfolio-management-part5): 
+
+| Characteristics of<br/>Project or Setting | Agile Strengths | Plan-driven Strengths |
+| ----------------------------------------- | --------------- | --------------------- |
+| Criticality of project | Low | High |
+| Developers' Experience | Senior (experienced) | More junior |
+| Product Requirements | Change often during Development | Stable with specifications |
+| Project Team Size | Small | Large |
+| Company Culture | Culture that responds to change | Culture that demands order |
+
+Agile has shown to be extremely resilient in project settings where there is a lot of ambiguity,
+where requirements are not fully known and plans have a high risk of changing. New product or
+feature development is an excellent example of where Agile shines. The underlying implementation of
+a feature may not be fully known before the team starts work on project.
+
+On the other hand, managing a infrastructure migration project will require a lot more planning to
+minimize downtime. A plan-driven framework may be more beneficial. However, such a project may also
+benefit from an iterative approach where independent portions of the infrastructure are migrated one
+at a time. Depending on the migration project, maybe a hybrid approach would work best.
+
+
+## Frameworks and the Triple Constraint
+
+The triple constraint is a good place to start to understand the fundamental differences between a
+plan-based framework and an Agile framework in the context of the PMBOK. Remember from 
+[Part 1](/posts/Foundations-of-project-management-part1), the triple constraint is often defined as
+the constrained relationship between scope, schedule, and cost. 
+
+![Triple Constraint: Agile vs Plan-driven (Cooper p.190)](/posts/0072/triple-constraint-agile.png)
+
+Each framework takes a different approach to managing the triple constraint. Traditional plan-driven
+project management makes sure that the scope is well defined before moving into the Development
+stage of the project, committing to the major resource investment. The overall cost of the project
+is relatively low until the Development stage. Once in the Development stage, the cost of a failed
+project is significantly higher.
+
+In a plan-driven framework, the definition of completion is tied to the scope. The project is
+finished when the well-defined scope has been delivered. As an example, a utility company needs to
+build a dam to increase their ability to produce electricity. The scope of the dam is pre-defined
+ahead of construction. The project is not finished until a functioning dam has been completed and
+has been delivered to the utility company's operations team. In this case, the cost and schedule are
+relatively flexible. The success of the project may be tied the cost and schedule constraints, but
+the completion of the project is defined by the scope being delivered. The dam may be delivered over
+budget and ahead of schedule, but the project is not considered completed until the dam has been
+delivered.
+
+In Agile project management, a project is often broken up into iterative fixed-time cycles (the
+Scrum flavor of Agile calls these sprints). The budget of each of these cycles is often fixed: the
+salaries and material costs of the end-of-the-cycle deliverable. However, the scope of the
+deliverable is flexible as it is more important to iteratively deliver something rather than to try
+to maximize all three constraints and deliver a fixed scope by the end of a fixed cycle with a fixed
+cost. Constraining a team with all three is setting up the team for failure and will create
+increasing tension on the team.
+
+
+## Conclusion
+
+While there is a difference between a plan-driven project management framework and an Agile project
+management framework, they are both built on top the foundations of project management described in
+the PMBOK. No matter what framework a project dictates or is chosen for the project, there are a set
+of deliverables that correlate to the success of projects. The 5 process groups and 10 knowledge
+areas in the PMBOK can be organized in a traditionally serial timeline or an iterative Agile
+approach. Both have the benefits and their drawbacks. The framework that fits the needs of the given
+project should be chosen rather than have an organizational default that is forced upon every
+project. Adaptively choosing the most beneficial framework guarantees the best chance of project
+success.
+
+---
+
+## Resources
+
+1. Schwalbe, Kathy. Introduction to Project Management: With a Brief Guide to Microsoft Project Professional 2016. Sixth edition, Schwalbe Publishing, 2017.
+2. Cooper, Robert G. Winning at New Products: Creating Value through Innovation - 5th Edition. Fifth edition, Revised and Updated, Basic Books, 2017.