Using what you have learned from PMGT 510, PMGT 540, PMGT 572 or any other courses in the program, compareand contrasttraditional waterfall projects andwhat you have done during this semester's...




Using what you have learned from PMGT 510, PMGT 540, PMGT 572 or any other courses in the program, compareand contrasttraditional waterfall projects andwhat you have done during this semester's project.




Please use PMBOK processes and knowledge areas for the comparison.







PMBOK processes:








  • Initiating.



  • Planning.



  • Executing.



  • Monitoring and controlling.



  • Closing.









PMBOK knowledge areas:








  • Project integration.



  • Project scope management.



  • Project time management.



  • Project cost management.



  • Project quality management.



  • Project Human Resource Management.



  • Project Communication Management.



  • Project Risk Management



  • Project Stakeholder Management



  • Project Quality Management






You must include examples and screenshots from PMGT 572 Scrum framework project and PMGT 510 or PMGT 540 traditional waterfall project to show the similarities and/or differences.










This cannot be a generic difference between the two project management frameworks.








Submit PowerPoint presentation of at least 20 slides.


Introduction and closing





slides will not be counted as part of the required twenty slides.




PowerPoint Presentation Template Do not Copy Waterfall vs. Agile Individual Assignment 11/06/2018 | PMGT 572 Template Do not Copy 2 Agenda 1. Introduction 2. Processes & Definitions 3. Initiating 4. Planning 5. Executing 6. Monitoring & Controlling 7. Closing 8. Conclusion Template Do not Copy 3 Introduction This presentation aims to highlight the similarities and differences between the traditional waterfall product development project that I worked on during the PMGT510 class and the website development of Chefville using Scrum from the PMGT572 class. This comparison will be based on the project management process groups from the PMBOK. PMGT510 Waterfall approach to develop a crankshaft PMGT572 Scrum approach to develop a website Template Do not Copy 4 Agenda 1. Introduction 2. Processes & Definitions 3. Initiating 4. Planning 5. Executing 6. Monitoring & Controlling 7. Closing 8. Conclusion Template Do not Copy 5 Processes & Definitions PMBOK Purpose Meet (or exceed) the needs and expectations of stakeholders for a project Definition Application of knowledge, skills, tools and techniques to project activities to meet project requirements Methodologies Traditional Waterfall Agile practices (i.e.: Scrum) Framework Project management provides a framework for working amidst persistent change. Project Management Definition Template Do not Copy 6 Traditional project management follows a Waterfall approach and consists of the application and integration of the five process groups: 1. Initiating 2. Planning 3. Executing 4. Monitoring & Controlling 5. Closing Processes & Definitions Traditional Approach to PM Template Do not Copy 7 Processes & Definitions Agile uses an “adaptive style of project management”, which is based on a less defined planning phase and which recognizes that “requirements and plan for the project” will change “as the project progresses”. This approach offers the company more room for adaptability and makes late changes less expensive. Scrum is an Agile methodology, which uses an iterative and incremental approach to developing products and managing work. Agile Approach to PM Sources: The Project Manager’s Guide to Mastering Agile , Scrum Essential Template Do not Copy 8 Agenda 1. Introduction 2. Processes & Definitions 3. Initiating 4. Planning 5. Executing 6. Monitoring & Controlling 7. Closing 8. Conclusion Template Do not Copy 9 Initiating Product Vision Initiating a project using a traditional approach requires to clearly define the scope and goals of the project and to quantify its success criteria and risks. This takes time and will be the basis for all other documents of the project planning phase. On the other hand, the initiation phase of a project using Scrum only requires the product vision. The product vision of Chefville is shown in the next 2 slides. As we can see, the product vision provides just enough information to be able to start the project, without loosing time and still allowing room for changes. Finally, the product vision is more comprehensive and easy to read. Template Do not Copy 10 We aim to increase the visibility of our French restaurant downtown Cedar Rapids (Iowa) thanks to our Website “Bistrot du Coin”. Unlike our competitors (other restaurants in the city), we offer traditional French cuisine, made by a French chef, who studied at the Bocuse Institute. Chefville Product Vision Statement Template Do not Copy 11 Chefville Product Vision Board Target Group Young professional people from Cedar Rapids and surrounding areas. Needs Increase the visibility, popularity of our new restaurant in Cedar Rapids. Introduce French cuisine to the Cedar Rapids area. Product & Features ✓ Gallery including pictures of food and of the environment ✓ Menus with pictures ✓ Reservations ✓ Comments & Reviews ✓ Discounts & Special events Value ✓ Profitable Company ✓ Business Model based on the revenue of the restaurant and advertisements of the website. ✓ Goals: Reach $1million of revenue in 2 years. Increase awareness and popularity of the restaurant of 30% within 2 years. Template Do not Copy 12 Agenda 1. Introduction 2. Processes & Definitions 3. Initiating 4. Planning 5. Executing 6. Monitoring & Controlling 7. Closing 8. Conclusion Template Do not Copy 13 Planning Overview Knowledge Areas Traditional Tasks Agile Tasks Scope WBS User stories Time Gantt Chart Prioritization, Estimation, Release Planning Cost Budget Quality Requirements Acceptance Criteria HR Resources: Role, MS Project Roles, Impediments, Agile Coach, JIRA, WIX Com Doc Diary, WhatsApp Risk& Procurement Risk register Iterative approach Stakeholder Stakeholder register Continuous interaction with stakeholders In this section, the comparison of the 2 projects using different PM methodologies will be based on each of the knowledge areas of the planning phase. Template Do not Copy 14 Planning – Scope The work breakdown structure and the user stories backlog are both used to get a better idea of what work will be required to reach the goals of the project. Both of them will be further broken down into subtasks when required in the planning phase. The main difference is that, once defined in MS Project, the WBS cannot be updated that easily, while the user stories in JIRA are meant to be updated as the project goes, which was very useful during the creation of our Restaurant website. Template Do not Copy 15 Planning – Time & Cost Estimating the time and resources required to complete each task, as well as the dependencies between the tasks and the overall cost of the project took me at least 5 full days. The result is presented by the Gantt Chart of this page. On the other hand, estimating and prioritization the backlog was much faster and much easier to handle. Indeed, instead of trying to define strict hours, costs or resources, we only had to estimate story points. In addition to this, we made sure that all our user stories were independent from each other. This gave us the opportunity to move stories from one sprint to another, during the release planning, without having to worry about dependencies. Template Do not Copy 16 Planning – Quality While quality management planning required to be very specific and technical, the acceptance criteria of our website were quite straight forward and understandable by all stakeholders. In addition to this, we checked the quality of our work at the end of every user story, which helped building a working product after only few days. The traditional approach to quality is not done as frequently, and correcting mistakes takes more time and is costly. Template Do not Copy 17 Planning – Resources Agile Coach Using a traditional approach in the PMGT510, as the Project Manager, I was responsible for an entire team, with strict roles and responsibilities, as shown in the organizational chart. I also had to assign tasks to each of the team member, according to their field of expertise and according to the time they had available for the project. When working on the restaurant website project as the Product Owner, I enjoyed having a team fully dedicated to this project. In addition to this, in theory, the Scrum team is committed and self-organized. Nonetheless, for this class, we realized that assigning tasks to team members was much more efficient than just waiting for people to volunteer. In regards to other resources, the main tool used in traditional project management was MS Project, while for the website we used JIRA. Finally, having an agile coach to support the team was very useful, which we had through this PMGT572 class. Tasks Assignment Template Do not Copy 18 Planning – Resources As the Project Manager for the crankshaft product development project from the PMGT510 class, I was responsible and accountable for managing all aspects of the project. In other words, I was responsible for understanding and managing how each functional team is going to get the work done. Going into more details, as a Project Manager, I collaborated with the team and the stakeholders to define the scope of work, plans and allocates the tasks, manages the budget, prioritizes features and coordinates with other dependent teams. The Project Manager Template Do not Copy 19 Planning – Resources I became the Product Owner of the team Chefville because I had the idea of the restaurant and took responsibility for maximizing the value of the product and the work of the team. I was the one responsible for the project, in regards to decision making and user stories prioritization in the backlog. In other words, as the Product Owner, I was the one able to accept or reject the work, according to the definition of “done” and based on our acceptance criteria. The Scrum Master of Chefville on the other hand was accountable for facilitating the Scrum process and acted as a Servant Leader. Our Scrum Master was using our WhatsApp group to remind everybody to update the story in JIRA and to make sure that there was no impediment preventing the team to do the work. When issues where identified, the Scrum Master was present and reactive to work on fixing them with the team. The Chefville team was responsible for delivering working products at the end of each sprint, based on the backlog prioritization. Chefville was cross- functional, composed of 4 generalizing specialists, but could have been more self- organizing. As mentioned before, the team members are supposed to choose the tasks they will work on during the sprint, within their field of expertise. However, this can only happen when the team is fully committed, focused on customer and build- in quality and located in the same work place. Product Owner, Scrum Master & Scrum Team Template Do not Copy 20 Planning – Communication As we can see in this slide about communication, I created in PMGT510 a communication plan defining which document will be done, when, and who it should be sent to. One of the main communication tools which was used, was the Status Report shown in this slide. This was meant to be used to clearly see what was on-going, done, to do and where were the issues. I personally think that the communication tools used in PMGT572 with the Chefville team were much more efficient because more visual. Indeed, we used a Kanban board in JIRA to check the status of the project, we communicated on a daily basis with WhatsApp and through our Daily Scrum Diary. Finally, our review and retrospective meeting were excellent communication tools to avoid any misunderstanding and to further improve the productivity of the team. Communication Plan Status Report Daily Scrum Diary 4Ls Retrospective Template Do not Copy 21 Planning – Risk, Procurement & Stakeholders During my work as Project Manager for the crankshaft product development project, I developed very detailed risk, procurement and stakeholders management plan. In regards to risk management, I built the risk register shown in this slide. To do so, I had to identify each risk, prioritize them, define a way to mitigate them and define a response strategy in case a risk actually occurs. In regards to procurement management, I ran a Make or Buy analysis, to define if it was more interesting for thyssenkrupp to buy steel from a third party, or to make its own steel for this product. In regards to stakeholders management, I worked on a stakeholder register in order to define how to communicate and approach each stakeholder, depending on their original concerns or preferences towards the project. This being said, during our website development project, the Chefville team didn’t have to worry much about risks or procurement. Indeed, we had nothing to purchase and the risks were identify and addressed throughout the project and during the sprint. However, I found that the Scrum approach to project management handles very well the stakeholder relationship, as it is all about continuous communication with all of them, which makes it much more effective than just having a stakeholder analysis. Risk Register Stakeholder Register Template Do not Copy 22 Agenda 1. Introduction 2. Processes & Definitions 3. Initiating 4. Planning 5. Executing 6. Monitoring & Controlling 7. Closing 8. Conclusion Template Do not Copy 23 Executing The main difference between the crankshaft product development project and the Bistrot du Coin website project was about the way to execute the work: waterfall vs. iterative. For my project in PMGT510, it took me 4 whole months to complete the planning phase of the project. The next step was the executing phase, which takes about 6 month before the customer can actually start seeing the first crankshaft. In other words, from the project kick off, it takes 10 months to deliver value to the customer. On the other hand, for the Bistrot du Coin website project, the iterative approach to project management enabled the Chefville team to have a working product, tested and validated, after only 2 weeks. Even though a crankshaft and a WIX website are two completely different products, both of them are relatively simple product and should not require 10 months before value can be delivered. The following slides show how the work was being done, story after story, using the Scrum methodology to build the Bistrot du Coin website. Template Do not Copy 24 Completed Stories in Sprint 2 Stories related to the Opening Hours & Reservations: First of all, we looked for the opening hours and reservation applications in WIX. We then inserted them in their respective page of our website. Finally, we edited these applications them with our information. Template Do not Copy 25 Completed Stories in Sprint 2 Stories related to Events: We first
Apr 22, 2023
SOLUTION.PDF

Get Answer To This Question

Related Questions & Answers

More Questions »

Submit New Assignment

Copy and Paste Your Assignment Here