# Gemini ## Introduction to SWEN90016: Software Process and Management This document provides an exhaustive explanation of the introductory lecture for the subject SWEN90016, titled Software Process and Management. The lecture serves as a foundational orientation for students, establishing the subject's context, objectives, administrative structure, and pedagogical philosophy. The initial part of the lecture is dedicated to administrative and contextual matters, setting the stage for the subsequent technical content. The primary speaker, Andrew, begins by welcoming the students to this first lecture of a two-hour session. He outlines the immediate agenda: the first portion, lasting between thirty minutes to an hour, will be dedicated to a comprehensive overview of the subject itself. This overview is designed to manage student expectations by clearly defining the course structure, the required deliverables (such as assignments and projects), and to provide an open forum for any initial questions. Following this administrative introduction, the lecture will transition to its first formal academic topic, which will be delivered by a colleague named Philip. The speaker's immediate plan is to first introduce the teaching staff, thereby personalizing the learning experience, and then to delve into the specifics of the subject's content and the expectations placed upon the students. The subject, identified by the code SWEN90016, is a significant offering within the university's curriculum, running in both academic semesters of the year. The current semester's enrollment is substantial, with approximately 400 students. This large class size is composed of a specific mix of postgraduate students: roughly 60% are enrolled in the Master of Information Technology (IT), while the remaining 40% are pursuing a Master of Software Engineering. This distinction is important because these two master's programs, while related, often have different focuses. A Master of IT typically provides a broad education across various technology domains, including systems, networking, and data, while a Master of Software Engineering concentrates more deeply on the rigorous, systematic, and disciplined processes for designing, developing, and maintaining large-scale software systems. This demographic information directly leads to a crucial characteristic of the student body, or "cohort": its diversity. Many students entering this subject already possess significant professional experience from working in the technology industry. Furthermore, their undergraduate academic backgrounds are varied, ranging from traditional Bachelor's degrees in IT, software engineering, or data science to degrees in entirely different fields. The latter group often enters the master's program through a "conversion" pathway, which is designed to equip individuals from non-technical backgrounds with the necessary skills to transition into the IT sector. Consequently, the cohort is a heterogeneous mix of individuals with different levels of prior knowledge, practical experience, and cultural backgrounds. The teaching staff explicitly acknowledges this diversity and states that it is a factor they actively consider and aim to reflect in their teaching methodology. This acknowledgment is a precursor to explaining a series of significant changes made to the subject for the current semester. These changes, which will be detailed later, have been implemented with the specific goal of making the subject's content and requirements clearer and more accessible to this diverse student population, ensuring that every student understands precisely what is expected of them. ## Subject Logistics and Delivery Before delving into the subject's content, the speaker addresses the practicalities of subject delivery, a necessary step given the varied experiences of the students. It is recognized that while some students may have been at the University of Melbourne for one or two semesters, for others, this might be their very first week. This is often the case for students who have been granted "advanced standing," a term that refers to the academic credit given for prior learning or work experience, allowing them to bypass certain introductory subjects and start their degree at a more advanced stage. To ensure everyone is on the same page, a critical point is made about the mode of delivery: all learning activities will take place on campus, with the sole exception of the lectures, which are delivered online. This "blended learning" model means that all tutorials, which are smaller, interactive workshop-style classes, and the final examination will require physical attendance on campus. This information is highlighted as particularly important for students to note, as it has direct implications for personal planning. Any plans for travel during the semester must be made in consideration of these mandatory on-campus commitments. This logistical point is emphasized to prevent any misunderstandings or scheduling conflicts later in the semester. Having clarified the delivery mode, the speaker outlines the structure of the upcoming introduction. The plan is to first introduce the three main members of the teaching staff, followed by an introduction to the other teaching staff (the tutors), and only then to proceed to the detailed discussion of the subject's content. The reason for starting with an introduction of the teaching team and emphasizing the cohort's diversity is directly tied to the subject's nature. SWEN90016 is a compulsory, or core, subject for many different postgraduate degrees within the School of Computing and Information Systems (CIS). Because it is a mandatory requirement for a wide range of students, it is inevitable that some will have already encountered parts of the subject matter in their previous studies or professional work. For students with industry experience, some topics might seem introductory or reflective of practices they have already performed. This wide spectrum of prior knowledge presents a significant teaching challenge: how to deliver a fundamental subject that is engaging and valuable for everyone, from the novice to the experienced practitioner. The teaching team has consciously restructured the subject to address this challenge. This restructuring is also vital because the subject heavily incorporates group work. The success of these group projects depends on effective collaboration, and it is highly likely that teammates will have different backgrounds and experience levels. Understanding and navigating this diversity is, in itself, a key learning outcome of the subject. ## The Teaching Team and Their Perspectives The lecture then proceeds with the formal introductions of the three principal instructors present, who will be the primary lecturers for the course. The speaker, Andrew, facilitates this process, handing over first to his colleague, Rajesh. Rajesh Shitoor Sundaram, who invites students to call him by his initials "CS" for simplicity, introduces himself as a recent PhD graduate from the University of Melbourne. His doctoral research specialized in "spatial databases," which are databases optimized to store and query data related to objects in space, such as geographic locations or geometric shapes. He explains that his academic research was directly motivated by his extensive 16-year career in the industry at Oracle Corporation in San Francisco. Oracle is a major multinational technology company known for its database software and enterprise systems. During his time there, Rajesh worked in technology consulting, a field that involves advising large companies on how to use technology to solve their business problems. His clients were "Fortune 100" companies, meaning they were among the largest and most influential corporations in the United States. His specific domain of expertise was in helping these clients resolve business process issues within their "supply chain," which is the entire network of organizations, people, activities, information, and resources involved in moving a product or service from supplier to customer. This background gives him deep, practical experience in the very subject areas that will be taught over the semester. He also mentions his involvement in another subject, SWEN30006 Software Design and Modelling, indicating his broader teaching role within the department. He concludes with an open invitation for students to seek help during his consultation hours, emphasizing a collaborative approach to learning where the staff is there to help students succeed. Next, Phillip Dart introduces himself. He describes a long and varied career that has seen him move between the university sector and private industry, including roles in government. His professional journey has encompassed a wide range of responsibilities, starting from technical roles like a software developer and progressing to leadership positions such as team lead, project manager, operations manager, research and development manager, and product manager. Phillip shares a personal insight into his career path, noting that he never intended to move away from the technical side of software development but was effectively "pushed" into management. He explains a common phenomenon in the industry: as a senior developer becomes more experienced and thus more expensive to employ, organizations often seek to leverage their expertise in higher-level, strategic roles rather than pure coding. This transition, while initially reluctant, proved to be a valuable and enjoyable learning experience for him. He uses his story to encourage students not to be afraid of the management side of software engineering, even if their passion lies in the technical details. He highlights that there are significant opportunities for "synergy," meaning the combined effect is greater than the sum of the parts, between the technical and management domains. He expresses his enthusiasm for contributing his wealth of experience to the subject's content. Finally, the initial speaker, Andrew, re-introduces himself. He positions himself as a lecturer in software engineering, acknowledging that his colleagues possess more extensive industry experience. He mentions his teaching involvement in another subject, SWEN20003, and notes that some postgraduate students might also be taking it. The explicit purpose of these detailed introductions, as Andrew explains, is for students to understand the diverse backgrounds and points of view of the teaching staff. This collective experience—spanning deep industry consulting, corporate management, and academic research—directly influences the subject's delivery, the selection of content, and the overall understanding of what is fundamentally important for students to learn. The core of the subject is about software processes and management, areas where many students may already have some experience from undergraduate studies or work. However, this subject aims to build upon and expand that existing knowledge in a structured, postgraduate-level context. In addition to the three main lecturers, the subject is supported by a team of five tutors. These tutors will lead the weekly tutorial sessions, which begin in the second week of the semester. A logistical note is made for students with tutorials scheduled on a Monday, which may be a public holiday; these sessions have been rescheduled, and students should have received information about the changes. To find contact details for all staff, including their specific tutor, students are directed to the university's online learning management system, Canvas. Within Canvas, under the "Modules" section, there is a "Staff and Tutorial Class List" that provides this information. Andrew provides a crucial piece of administrative advice: if students have administrative questions about their tutorial class, such as enrollment issues, they should direct these questions to one of the three main lecturers (Rajesh, Andrew, or Philip). While tutors should be kept informed, they typically do not have the authority to make administrative decisions. This clarification helps streamline communication. It is also mentioned that many of the tutors also have valuable industry experience, which is another resource the subject draws upon when making decisions about its content and direction. ## Subject Overview and Learning Outcomes The lecture now transitions to the formal introduction of the subject's academic content. The speaker begins by presenting the key learning outcomes and skills that students are expected to acquire. While not reading the list verbatim, he emphasizes their importance as a clear guide for students. The fundamental purpose of SWEN90016 is to introduce students to the software engineering principles, tools, and techniques that are essential for managing large-scale software projects. To make this more concrete, the speaker gauges the audience's familiarity with a key industry methodology by asking for a show of hands from those who know what "Agile" is. Agile is a modern approach to project management and software development that emphasizes iterative development, collaboration between self-organizing cross-functional teams, and adaptive planning. The fact that some, but not all, students are familiar with it reinforces the point about the cohort's diverse background. A significant portion of the subject's practical work, particularly the group project, will focus on understanding and correctly implementing these Agile techniques. This practical application in the project work is contrasted with the final exam, which will cover other, sometimes more theoretical, concepts. The subject is thus structured with a dual focus: a very practical, hands-on component (the project) and a theoretical knowledge component (assessed in the exam). Topics covered in the later weeks of the semester (weeks 7 to 11) are highlighted as being particularly important general knowledge for any software developer, and these topics will be more heavily featured in the final exam. The slides containing these detailed learning outcomes are presented as a study resource, designed to be clear and comprehensive, even if they contain a lot of text. A list of lecture topics is presented, providing a week-by-week overview of the semester's curriculum. The speaker acknowledges that for students with undergraduate degrees in computer science or software engineering, many of these topics—such as requirements engineering, software design, testing, and project management—may seem familiar. However, he assures them that there will likely be new topics or that familiar topics will be presented with a different perspective or depth. These topics are formally covered in the lectures. To provide an even more detailed roadmap, students are directed again to the Canvas learning management system. In the "Modules" section, under "Subject Information," they can find a document called the "Semester Plan." The speaker notes that this plan, along with the lecture slides for this first session, has been recently updated. He advises students to download the latest version if they had previously accessed an older one. The Semester Plan is a comprehensive guide that lays out the weekly lecture topics, the corresponding tutorial activities, and, crucially, the due dates for all assessments. A key date is highlighted: the first assignment is due in week 4. The detailed specification for this assignment will be released at the end of the following week (week 2). This plan provides a clear, structured timeline for the entire semester, allowing students to plan their work effectively. The lecture topics cover a broad range, with Phillip primarily covering the first half of the semester and Andrew covering the second half. A unique feature of the later lectures is also introduced: part of the scheduled lecture time will be dedicated to "consultation time" for the group projects. This means that in the later weeks, after the formal lecture on a specific topic, the remaining time will be an open session where student groups can work on their project and receive direct help and guidance from the teaching staff present. The rationale for this dedicated consultation time will be explained shortly. ## Expectations, Communication, and Academic Integrity The lecture then outlines the general expectations for student participation. There is one tutorial class per week, and attendance is expected. The purpose of tutorials is to take the theoretical concepts introduced in the lectures and apply them to practical scenarios, such as case studies and real-world examples. Crucially, the tutorials are designed to directly equip students with the skills needed to complete the assignments. Everything covered in the tutorials is examinable, meaning it can appear in the individual assignment, the group project, or the final exam. Therefore, the tutorials serve as a direct guide for studying and for understanding how to approach assessment tasks. A mandatory and serious topic, academic integrity, is then addressed. The speaker reiterates the diversity of the student cohort's educational origins: based on a survey from the previous year, approximately one-third of the students completed their undergraduate studies at the University of Melbourne, one-third at another Australian university, and one-third at a university outside of Australia. This diversity means that students may be accustomed to different academic conventions and standards. For those new to the University of Melbourne, it is imperative that they familiarize themselves with the university's specific policies on academic integrity. The speaker urges students to read these policies and to ask for clarification if anything is unclear. When the assignment specifications are released, they will include additional, explicit guidance on what constitutes acceptable and unacceptable collaboration, as well as rules regarding the use of Generative AI tools. This proactive guidance is intended to prevent academic misconduct by setting clear boundaries. Regarding communication, the subject will use several standard channels. The primary platform for most questions is the "Ed Discussion" board, an online forum where students can post questions and staff can provide answers visible to everyone. The staff commits to answering questions on Ed Discussion within one business day, but they will not be responding to emails or forum posts after work hours, on weekends, or during public holidays. Students are encouraged to check if their question has already been asked and answered to avoid duplicates. The teaching team is actively revising the assignment specifications to be as clear as possible, with the hope of reducing the number of clarification questions needed. A significant change this semester is an increase in consultation opportunities. In addition to the dedicated lecture time and normal staff consultation hours, there will be more face-to-face access to teaching staff, especially for the group work. For the first assignment, which requires a degree of independent investigation and research, students are strongly warned not to leave it until the last minute. To encourage proactive work, the discussion board for a given assignment will generally be closed to new questions one day before the deadline. ## Assessment Structure and Rationale The lecture now provides a detailed overview of the assessment structure for the subject. There are three main components: an individual assignment, a group assignment, and a final exam. The first assessment is an individual assignment, with a word limit of approximately 1800 words (or 4 pages). The full details will be released by the close of business on Friday of week 2, giving students two full weeks to work on it before its due date in week 4. Following the individual assignment, the focus shifts to group work. The group assignment has deliverables due in week 5 and then several more due in week 11. The speaker clarifies a point from the slide, which mentions a week 12 presentation. This has been amended for the current semester. Instead of a live, in-person presentation in week 12, groups will submit a recorded presentation that will be assessed. The individual assignment is designed to introduce key concepts, and the group assignment will build directly upon the work done in that first task. Both assignments will revolve around a single, semester-long case study, which will be detailed in the assignment specifications. A "hurdle requirement" is mentioned. In university assessment, a hurdle is a component that must be passed in order to pass the overall subject, regardless of a student's total score. Students simply need to ensure they meet this minimum standard. The final component is the examination, which is typically a two-hour, computer-based exam held on campus under "invigilated" conditions, meaning it is supervised to prevent cheating. To help students prepare, they will be provided with practice exams and corresponding solutions or worked examples. This exam requires students to bring their own laptops, or they can request to borrow one from the university. ### The Individual Assignment (Assignment 1) Delving deeper into the first assessment, the individual assignment consists of two main parts. The first part requires students to conduct an investigation into a historical software engineering project that encountered significant setbacks or failed completely. Students will be asked to evaluate the project, identifying the causes and consequences of its problems. This "investigation" or "research" component involves finding and analyzing credible sources online, such as official reports, industry analyses, news articles, and academic papers. To ensure that sufficient information is available, students will be given a list of pre-approved historical projects to choose from. This task is designed to develop skills in investigation and research, which are core competencies expected of all master's-level students and are essential for future capstone or research projects within their degrees. The second part of the assignment involves a different case study, one that will be provided by the teaching staff. Students will need to analyze this new case study using the principles they have learned. The analysis performed in this part of the assignment will directly feed into the work required for the subsequent group project (Assignment 2). The overarching theme connecting these two parts is the "Software Development Life Cycle" (SDLC), which is a framework that defines the stages involved in creating a software system, from initial planning to final deployment and maintenance. In essence, the assignment asks students to first analyze how SDLC principles were or were not applied in a real-world historical example, and then to apply those same principles to a new, controlled case study that will form the basis of their group's implementation project. ### The Group Assignment (Assignment 2) The group assignment, also referred to as Project 2, builds directly on the individual assignment. The first logistical point concerns group formation. Groups will consist of five students, and it is a strict rule that all members of a group must be enrolled in the same tutorial class. No exceptions will be made to this rule. The reason for this is pedagogical and logistical: it allows tutors to interact with and support their assigned groups effectively within the tutorial structure. Group formation will take place during the tutorial in week 3 of the semester. The tutor will facilitate this process. Students who have already formed informal groups with friends can formalize them, provided they are all in the same tutorial. Students who do not have a pre-formed group should not worry, as they will be allocated to a group. If students wish to be in a group with friends from a different tutorial, their only option is to use the university's enrollment system to try and get on a waiting list for a spot in the desired tutorial. The tutorials are at maximum capacity (30 students each), so the teaching staff cannot manually move students between them. It is important to attend the week 3 tutorial to participate in this process, though students who are absent will still be allocated to a group. The core task of the group assignment is to implement an IT system, specifically a website. However, a critical point is emphasized: the technical development of the website is not the primary focus of the assessment. While the final implementation will be graded, the majority of the marks are awarded for the *process* of developing it. The project serves as a vehicle to evaluate whether the group can properly execute a structured project sequence based on a specific SDLC. The assessment focuses on the delivery and structure of the project, not the technical complexity of the final product. The project timeline is structured around the Agile methodology. After the individual assignment is due in week 4, groups will have one week to collaborate and produce a "Project Management Plan," which is due in week 5. Following this, the project work will be divided into what are known as "sprints." In Agile development, a sprint is a short, fixed-length period during which a specific amount of work is completed. For this project, students will work in three distinct sprints. As detailed in the Semester Plan, Sprint 1 will cover weeks 6-7, Sprint 2 will cover weeks 8-9, and Sprint 3 will cover weeks 10-11. The project concludes with a final submission at the end of week 11. Within each sprint, there are specific activities and tasks that groups are required to perform as part of the Agile framework that will be taught. The speaker acknowledges that students with industry experience might know that Agile methodologies often involve daily activities (like daily stand-up meetings). However, the subject adapts this professional framework to the academic context. The workload is based on the standard university expectation of 10 hours of study per week for a subject, which is roughly one-quarter of a full-time job. Therefore, the Agile process is scaled down and structured to be manageable within this time commitment. The goal is to take a real-world industry practice and adapt it into a learnable format for the university environment. ## The Pedagogical Rationale and Subject Linkages A key objective of this subject is to ensure that students understand how to correctly apply the Agile process. The lecture explains why this is so important by showing how SWEN90016 connects to other subjects in the curriculum. This subject is a core prerequisite for several subsequent courses. For instance, Master of IT students will likely take a "Software Project" subject, which assumes students already know and can apply Agile methodologies. Similarly, Master of Software Engineering students will take a sequence of advanced project-based subjects (SWEN90017, SWEN90018) where they will also use Agile. The critical difference in these later subjects is that students will be working with real industry clients on real-world projects. In those high-stakes environments, the ability to work effectively in a structured team is paramount. Therefore, SWEN90016 provides a highly "scaffolded" and organized introduction to Agile. Scaffolding is an educational term for providing temporary support to help a student master a task or concept they could not initially do on their own. Here, the process is deliberately structured and simplified to ensure that students learn the fundamentals correctly. The aim is to prevent a situation that has occurred historically, where some students move on to advanced subjects without a solid grasp of these foundational processes. By graduating from this subject with a correct and practical understanding of Agile, students will be well-prepared for success in their future studies and, ultimately, in their professional careers. ## Semester-Specific Subject Enhancements The speaker then details the specific changes and improvements made to the subject for the current semester. While the fundamental concepts remain the same, the delivery has been significantly revised. 1. **Increased Staff Availability:** There will be substantially more consultation time available for students, particularly from week 5 to week 11, to support the group projects. This includes dedicated time within lectures, normal consultation hours, and additional drop-in sessions. These sessions can be used by groups to get help or even to conduct some of their required group activities under the guidance of staff. 2. **Revised Assignment 1:** The scope and complexity of the first individual assignment have been reduced. The goal is to make the assignments simpler and more focused. Some of the more complex decision-making elements that were previously in the assignments have been moved into the final exam questions. This change, along with the new component of analyzing a historical software project, is intended to make the assignment more straightforward while still providing a valuable learning experience about how SDLCs are used in industry. The content required for Assignment 1 will be covered entirely in the lectures of week 1 and week 2. 3. **Revised Assignment 2:** The scope of the group project has also been reduced. The speaker clarifies that "reduced scope" does not mean "easier," but rather that complexity has been removed to make the project more straightforward. For example, all student groups will now work in three sprints of a fixed two-week duration; they do not have to make decisions about sprint length. Certain decision-making aspects have been removed to simplify the process. Students will be explicitly told what functional requirements to implement in each of the three sprints. While this is contrary to a pure Agile approach where the team decides what to work on, it is a deliberate pedagogical choice. This structured approach ensures that students first learn the mechanics of the process correctly in a controlled environment before they are expected to apply it more flexibly in future subjects. 4. **Structured Sprints and Formative Feedback:** Each sprint will come with a checklist of required activities and deliverables. At the end of Sprint 1 (week 7) and Sprint 2 (week 9), tutors will evaluate the group's progress and provide an "indicative mark." This mark does not contribute to the final grade but serves as formative feedback. It tells the group how they are performing, whether they have completed the required activities correctly, and provides specific feedback for improvement. The final grade for the project is based on the cumulative submission at the end of week 11. This feedback loop is designed to help groups identify and correct issues early, so that by the time they complete the third sprint, they are performing the key activities correctly. 5. **Amended Final Submission:** The deliverables for the final week 11 submission have also been amended. The final submission will include items like a video demonstrating the implemented system and a recorded group presentation, and may also include a written group report. Finally, a call is made for two "class representatives." The role of these representatives is to act as a liaison between the student body and the teaching staff, relaying collective feedback or concerns. They also participate in a formal mid-semester survey process to gauge how the subject is progressing. This is part of a broader effort by the teaching staff to be responsive and to continuously improve the subject based on student feedback. ## The Commencement of Technical Content: Introduction to Software Process Following the administrative overview, the lecture transitions to the first technical module, delivered by Phillip Dart. He begins by reinforcing a key point made by Andrew regarding the group project. He uses the analogy of a complicated Lego kit: the subject could, in theory, have students build complex Lego models using an Agile process. The goal would not be to become expert Lego builders, but to learn the Agile process. The product (the Lego model) is merely a tool for learning the process. Similarly, in this subject, students will build websites using WordPress, a popular and widely-used content management system. While learning WordPress is a valuable skill in itself, the primary focus remains on learning and applying the software development process. The choice of WordPress is deliberate: it provides a controlled technical environment and lowers the barrier to entry, allowing students with diverse coding skills to participate fully and focus on the process, which is the main learning outcome. This approach ensures that technology does not become a barrier to achieving the subject's core objectives. The more complex technical challenges are reserved for future, more advanced subjects where students will work with real clients and have more freedom to choose technologies. After a brief administrative changeover, Phillip begins his formal lecture on software process. He notes that there will be a scheduled break in the middle of the two-hour lecture block. The topic for this first session is "understanding key elements of the project and why organisations use them." ### What is Process? The lecture starts by defining the fundamental term: "process." A process is defined as a systematic series of actions or steps taken to achieve a particular goal. This inherently involves activities like planning what to do, executing those plans, and monitoring and controlling the progress to ensure the goal is met. The result or output of a process is a "product." In the context of a software project, the "product" is not just the final, executable piece of software. It encompasses all the associated "artefacts" created during the project, such as user documentation, design documents, testing plans, and deployment schedules. A clear distinction is drawn between the *process* (the series of actions) and the *product* (the outcome of those actions). ^0cjuaa ### The "Irrational" Nature of Design Phillip introduces a concept from a classic 1986 academic paper titled "A Rational Design Process: How and Why to Fake It." The central argument of this paper is that it is impossible to conduct a perfectly rational, linear, step-by-step software development process. The idealized "waterfall model"—where one completes requirements analysis fully, then moves to design, then to implementation, and so on, without ever going back—is not how complex software is actually created. In reality, the creative process is messy. It involves hitting dead ends, having to backtrack, making changes, and iterating on ideas. However, the paper argues that even though the *journey* is irrational and messy, the final *destination*—the complete set of project artefacts—should look as if it were produced by a perfectly rational process. The final design documents, code, and user manuals should all be consistent and aligned, presenting a coherent and logical whole. The reason for this is that most stakeholders (like future developers who need to maintain the system or managers who need to understand it) are not interested in the messy history of its creation. They don't need to know about the mistakes and detours; they need a clear, consistent, and understandable final product. The only time the messy history is relevant is for specific purposes like process improvement analysis. This presents a paradox: if the creative process is inherently irrational, how can we reliably arrive at a rational-looking result? The answer, Phillip explains, is precisely the focus of this subject: process. History has shown that attempting to build complex systems in an "ad hoc" or unplanned way has a very low chance of success. To manage the inherent messiness and successfully reach the desired endpoint, we must apply tried and tested processes. A robust process, one that is appropriate for the type of product being built and the context in which the team is working, provides the foundation for success. This is what professionals do in industry. While the subject will teach specific processes like Agile, the reality in industry is that organizations often use hybrid or modified processes tailored to their specific needs. Phillip provides a personal example from his time as a product manager for a globally used product. His team used an Agile approach for development, but they could not use a traditional Agile approach for gathering requirements. Because their clients were spread across the world, they had to use a more formal process to consult with representative clients and get their approval on requirements before starting development. This resulted in a hybrid process developed specifically for that product and its unique context. The ultimate focus of the subject, therefore, is on developing the essential skills for managing and executing projects effectively, skills that are directly transferable to advanced courses and the professional world. ## Defining a Project The lecture then moves to define another key term: "project." A project is a temporary endeavor undertaken to create a unique product, service, or result. The key characteristics are that it is "temporary" and produces something "unique." In industry, a clear distinction is often made between a "project" and "business as usual" (BAU). A project is a temporary initiative that creates or changes something. Once the project is complete, the ongoing maintenance and operation of what was created becomes part of BAU. For example, a project might be established to build a new website; once the website is launched, the tasks of updating its content and fixing bugs become BAU activities. Because a project is temporary, it has a defined beginning and end. Another common characteristic of projects, especially in large organizations, is that they are "cross-functional." This means they require bringing together people from different departments or teams who would not normally work together. Phillip illustrates this with a current project he is involved in at the university, which aims to improve the university's websites for researchers. The university is a large, complex organization, and various departments have created their own web pages with information for researchers. The problem is that a researcher doesn't care about the university's internal structure; they just want to find the information or tool they need in one central place. The project's goal is to bring together people from all these different support departments to create a single, unified online resource for researchers. This project is a temporary, cross-functional endeavor. Once the new resource is built, a BAU process will need to be established to maintain it. Projects can vary enormously in scale, from small teams working for a few weeks to massive undertakings involving hundreds of people, large budgets, and years of work. Phillip notes that some of the most complex systems ever built by humanity are software systems, highlighting the vast range of complexity in the field. Organizations use projects as the primary mechanism for introducing change. This change might be forced upon them, such as when new tax laws require changes to accounting software and internal business processes. Or, the change might be an attempt to capitalize on a new opportunity, such as when a government issues a tender (a formal invitation to bid on a project), and a company forms a project team to prepare a response. In all these cases, setting up a project provides a structured way to manage the change. It involves thinking about resourcing (who will work on it), responsibility (who is in charge), and stakeholders (everyone who is affected by or has an interest in the project). It requires getting "buy-in" and support from senior people in the organization to ensure its success. ## The Discipline of Project Management Finally, the lecture defines "project management." Project management is the discipline of applying knowledge, skills, tools, and techniques to project activities to meet project requirements. It encompasses the entire project lifecycle, from the initial idea or "inception" through to completion and the transition to business as usual. Phillip clarifies that the term "project management" can be used in two ways. In its broad sense, it refers to this entire discipline. In a narrower sense, it can refer specifically to the monitoring and tracking part of a project. For example, some people with the title "Project Manager" may have a role that is primarily focused on maintaining a detailed project plan in a tool like Microsoft Project. He asks the audience if they have seen such a project plan, which can be a highly complex document. A project plan can consist of thousands of tasks with defined dependencies between them (e.g., Task B cannot start until Task A is finished). These plans are especially common and complex in fields like civil engineering. However, for the purposes of this subject, "project management" is understood in its broader sense, covering all the activities from planning to completion. This broad discipline involves many activities. It includes managing resources (people, budget, equipment), and critically, identifying and managing risks. Risk management is a key responsibility of any project manager. Phillip shares from his experience as an operations manager, where he would meet with all his project managers every week. A standing item in every meeting was to revisit the risks for every single project. While often the conclusion was that nothing had changed, it was crucial to regularly assess the situation so that when a risk did change, its impact could be understood and addressed immediately. Other key activities include tracking and resolving issues that arise during the project and ensuring clear communication among all stakeholders. The slide presented contains a great deal of detail, which is intended to give students a sense of the breadth and depth of what is involved in professional project management. The lecture pauses here for a scheduled break, with the intention of resuming with a simpler, more visual model of project management components.