PLEASE SEE ATTACHED FILES FOR ASSIGNMENT DETAIL AND INFORMATION!!! Project Management Methodologies Deliverable Length: Description: Building on your Week 1 IP, create detailed project plans by using MS Project for the waterfall method and the Agile scrum method, separately. Include the following: • The project plans should show the work breakdown structure (WBS), stakeholders, activity relationships, and key milestones for the different methods. Using the Word file from Week 2, add 2 MS Project files for both waterfall and Agile methods. Project Details: An information technology (IT) firm is working on a project to come up with a competing social medial product that provides all of the features provided by an existing social media platform and any other features requested by the marketing team, including specific features for certain user groups. The final product needs to be ready within 1 year. The deliverable this week is a Word document of 2–3 pages (about 1,000 words; can include some charts or graphs) to show the high-level time line for each method. The time line for each method should show the difference of functions or characteristics by using different methods. Project Management Methodologies Albert Arseneault PM670 Individual Project 2 4/17/2019 Introduction: Project management methodologies play a crucial role in determining the success of a software product. Before choosing one, it is essential to identify the nature of the end product and the viability of each process to achieve it. Some methods give those involves higher leaves of flexibility. New features can be added without interfering with the process or end product. Other methods offer users to perform exhaustive assessments earlier to ensure every requirement is determined before the creation process. A logical sequence of events and milestones is followed instead. This paper discusses Agile Scrum and Traditional Waterfall Methodology as software project management alternatives in the delivery of a social media product for an IT firm. Traditional Waterfall Method The scope of work: The Traditional Waterfall Project Methodology has been around for close to 50 years. It supports a logical flow of tasks from the start all through the project to the end (Merwe, 2017). In the Social Media Product project, the Traditional Waterfall method can be used to ensure a successful delivery within a year. Features need to be defined before the actual process of designing and creating the product. After that, an analysis of specifications, followed by the designing of the program, the actual coding, testing and operations after the product has been approved to have met requirements. This methodology assumes that every requirement needed in the product can be identified and gathered upfront (Casteren, 2017). Figure 1: The Waterfall Method (Casteren, 2017) High-level timelines and Milestones Requirements: All stakeholders, including users, assemble to determine features that shall be added to the Social Media Product. The marketing team and representatives from the unique user groups should assist in this specification identification process to ensure all system and software requirements have been determined. This process should take roughly one to two weeks (Lucidchart Content Team, 2017). Analysis: After the delivery of the requirements milestone, two weeks from the start of the project, analysis of the software and system requirements by designers, programmers, sponsors, and other stakeholders is done to ensure that the identified needed features are essential and deliverable. This part may also involve alignment of the requirements with the budget and timeline. Project scope and schedule is produced officially after this stage, which will claim the third week since the start. (Casteren, 2017). Program design: Software designers and developers will work on delivering the third milestone, which is producing a complete system design upon which programmers and coders will base their technical work. This design will focus on providing the features signed on as mandatory in the past milestones with a particular focus on efficiency, timeline, and budget restrictions (Lucidchart Content Team, 2017). Designing will take close to four weeks. Coding: Implementation takes place in the coding stage where programmers will create a functional social media product by using designs and requirements from the designing stage. Small patches of codes are produced then integrated to produce an end product that can be delivered to the next stage (Lucidchart Content Team, 2017). Coding will take about 30 weeks. Testing: After the delivery of the coding milestone, the product can be subjected to testing. So doing reveals any problems and issues that may compromise the use of the Social Media Platform (Lucidchart Content Team, 2017). Testing and debugging will take about ten weeks. Operations: At this stage, the product will be submitted to the owners as all deliverables are completed, after which it is deployed. From this point on, only periodic maintenance shall be subjected to it until additional features prompt another project. Agile Scrum Method The scope of work: Agile Scrum Methodology is an alternative to Traditional Waterfall Approach. Like other Agile Methodologies, it focuses on "interaction, communication, and the reduction of resource-intensive intermediate artifacts" (Casteren, 2017). Through daily iterative cycles, this methodology invests i planning and constantly changing prioritization. New specifications and features can be added easily in Agile than in Traditional Waterfall Methodology (Casteren, 2017). Scrum was explicitly developed to follow Agile principles. Unlike traditional approaches that use sequences, it brings the development team closer to each other in a definitive strategy that ensures the best product is created in the end. This methodology divides the group involved into the product owner or sponsor, who determines the requirements of the product and compile them into a Product Backlog, Scrum Master, who oversees and determines the scrum process, and the team, which involves other members working on implementing their respective backlog (Permana, 2015). Figure 2: Agile Scrum Method (Casteren, 2017) High-level timelines and Milestones Determination of features: The first milestone that shall be delivered shall involve a meeting of all stakeholders who will benefit from the Social Media Product. They include the user groups, project management team, programmers, designers, marketers, IT firm representatives and any other person involved with the software. All features that the new product shall need will be determined by the end of this milestone (Casteren, 2017). Stakeholders meeting and determining features could take about two weeks. Product backlog: After the stakeholders have delivered their input, the project owner or sponsor, in this case, the IT firm, shall determine specifications and register initial requirements that will be delivered by the team in the product backlog (Permana, 2015). Project owners could take one week to compile and approve requirements as a product backlog. Sprint backlog: This deliverable shall be fundamental to the success of the project in meeting deadlines and budget. It involves dealing with high priority tasks first, thereby creating a chance for other developments in the implementation of the product (Casteren, 2017). The sprint backlog of high priority items could take about five weeks. Weekly sprints and Daily Scrums: After delivering high priority tasks, other remaining deliverables are divided into sprints. A Sprint Planning Meeting of activities to be tackled within weekly sprints commence each and meetings called Scrums are held daily before starting work to evaluate progress and determines that day's work. This procedure increases flexibility and reduces mistakes (Permana, 2015). After the Typical weekly sprints will take about 40 weeks Review and Release: After finishing all sprints, testing, debugging and submission of the product for release it the next step. After that, only maintenance of the Social Media Product will be needed. Reviewing and releasing the product will take about six weeks. Stakeholders and Reporting Structures Waterfall Method: Traditional Waterfall Project Methodology follows a rigid logical sequence of task handling. Which means stakeholders are well-defined per their fundamental roles. Every phase of the traditional method, which includes determination of system and software requirements, analyses, designing, programming, testing, and operation have specified hierarchy of stakeholders according to their roles in achieving the milestone. Stakeholders: In the Traditional Waterfall Method, stakeholders are defined as a product owner, project manager, developers, designers, testers, and users. The product owner is the person or people who prompt the need for such a product, funds the project and signs off all decisions made by other stakeholders. They are at the top of the rigid waterfall stakeholder hierarchy. In this case, the project owner is the IT firm. The project manager, on the other hand, oversees the project managing all aspects of it. They are involved with the day to day activities and are the experts in strategies in project scheduling and delivery. Designers come up with designs that meet the requirements of the project owner and with features needed by users. They ensure their designs also are technical enough to be translated by developers and programmers. This latter group is tasked with the coding process of product development. They translate designs into actual products needed by other stakeholders. Testers come in after the programmers have completed their initial development phase. They conduct tests to ensure the product runs efficiently and correctly before handing it over for deployment. Users are the client for which the product is designed for. Their specifications and characteristics are essential in the design and development phases (Palmquist, Lapham, Garcia-Miller, Chick, & Ozkaya, 2013). Reporting structures: Waterfall reporting structures are usually heavily dependent on proper documentation of every process and procedure. As the method works to ensure that only by successful completion of one entire phase can the next to be initialized, reporting issues concerning deliverables and progress in a particular phase are extremely important with everything documented to indicate success (Baham, 2016). Agile Scrum Method: Unlike Waterfall method, Agile, especially Scrum, is un-bureaucratic. Minimal structures are defined because this method is reliant on constant change and easy allowance of it to deliver an exceptional product. Stakeholders: Stakeholders in Agile include product owner, scrum master, project manager, and the team. After the initial feature definition by all stakeholders, the project owner, who is the IT firm in this particular case, uses them to create a product backlog that defines deliverables initially agreed upon. Project or sprint managers delegate and coordinate teams during the sprints to ensure they achieve milestones within time. Scrum masters oversee scrums or daily meetings to establish daily goals, assess progress insofar, and determine if any change is needed. Teams include designers, developers, and debuggers. Users or clients are those who will be using the product after it has been developed (Madampe, 2017). Reporting structures: While not as heavily reliant on exceedingly "regimented and document-driven procedures of traditional waterfall approach" agile scrum methods are reliant on closer relationships within stakeholders and open, encouraging communication (Baham, 2016). With a methodology that is driven by a change of scope, Agile requires less structured reporting procedures that ease the communication process. Daily scrums and sprint evaluations assist in facilitating this interaction. Communication Strategies Waterfall Method: Traditional Waterfall method value communication management as a process that ensures the success of the project and the achievement of milestones as per the plan. Strategies used by Waterfall methods involve proper and extensive documentation. These reports are then handed over to the leading stakeholders in the next phase. Communication strategies in the Waterfall method are aligned to ensure there is no room of error and to avoid changes at all costs. They are designed to ensure the project sticks to the initial plan and the product to the initial designs. As such, communication is seen as essential in assisting with forecasting and risk assessments that help prevent changes and deviations from the plan (Salameh, 2014). Precision is, therefore, key in all communication done in Waterfall methodology (Montagne, 2012). Agile Scrum Method: Agile Scrum methodology has different priorities compared to the Traditional Waterfall approach regarding communication strategies. Instead of an emphasis on precision and extensive documentation, Agile Scrum method invests in increasing "communication bandwidth and frequency" (Salameh, 2014). All communication in the project is amplified in this sense. There are daily scrums and meetings after every sprint. Co-location among team members, clients and end-users are used to facilitate coordination and alignments with project objectives through constant communication. Agile's communication strategy taps on the evolutionary progress of continuous communication and invests on the refinement capability of exploiting different perspectives in enhancing the product (Salameh, 2014). Implementation of Change Requests Waterfall Method: Implementing change requests in the Traditional Waterfall approach is as methodical and structured as every other process in the methodology. Although initial requirement definition and design stages are structured to ensure the agreed on product design will not change, clients may request removal or addition of some requirements. Change requests in this approach are only accepted if there are no other alternatives placed in the contingency or predetermined risk to the issue at hand. Also, Traditional Waterfall method requires a change in the initial project plan and budget to accommodate such unforeseen changes. Meetings are, therefore, formally held between stakeholders to reprogram the project (Pawar & Mahajan, 2017). Agile Scrum Method: Agile Scrum Methodology is designed to be dynamic and to be flexible enough to accommodate numerous change requests. The only concern of Scrum project managers is ensuring change requests do not affect the timeline. Scrum encourages constant communication, but the client has to make Requirement Trade-offs. Significant changes are considered depending on whether it is a change to the Timebox or Release plan. Minor changes are accepted readily in Agile Scrum methodology especially if they work to customize and refine the product (Pawar & Mahajan, 2017). This methodology is mostly applicable in projects whose specifications are not definitive or those where changes are inevitable. This fact is mostly because it has a less structured and less costly reaction to change requests. Implementation of change requests is also more straightforward due to daily scrums and weekly sprints (L’Ecuyer & Ahmed, 2016). Conclusion: In conclusion, Agile Scrum and Traditional Waterfall Methodologies have been discussed as software development alternative processes in the delivery of a social media product. Their characteristics, both beneficial and not have been laid out as well as features of the steps, milestones and high-level timelines. For a software end product needing flexibility, we have discovered that Agile Scrum is the best project management methodology. References: Casteren, W. V. (2017). The Waterfall Model and the Agile Methodologies : A comparison by project characteristics - short. Unpublished. https://doi.org/10.13140/rg.2.2.10021.50403 Lucidchart Content Team. (2017, August 23). Complete Guide to Waterfall Project Management Methodology. Retrieved from https://www.lucidchart.com/blog/waterfall-project-managementmethodology Merwe, I. W. V. D. (2017). How relevant are waterfall project management methodologies in today’s modern project environment? Unpublished. https://doi.org/10.13140/rg.2.2.15971.66083 Permana, P. (2015). Scrum Method Implementation in a Software Development Project Management. International Journal of Advanced Computer Science and Applications, 6(9), 198– 204. Baham, C. W. (2016). Understanding Agile Software Development Assimilation Beyond Acceptance (Doctoral dissertation). Retrieved from https://digitalcommons.lsu.edu/grad school_dissertation/19 L'Ecuyer, A., & Ahmed, S. A. (2016). Controlling change in agile software development projects. Universal Journal of Management, 4(1), 42–49. https://doi.org/10.13189/ujm.2016.040106 Madampe, M. A. K. G. (2017). Successful Adoption of Agile Project Management in Software Development Industry. International Journal of Computer Science and Information Technology Research, 5(4), 27–33. Montagne, D. (2012). Speak Loud, Speak Proud - Effective Communication Strategies. Presented at the PMI® Global Congress 2012, Vancouver, British Columbia, Canada: Project Management Institute. Palmquist, S., Lapham, M. A., Garcia-Miller, S., Chick, T. A., & Ozkaya, I. (2013). Parallel Worlds: Agile and Waterfall Differences and Similarities (No. CMU/SEI-2013-TN-021). Carnegie Mellon University. Pawar, R. P., & Mahajan, K. N. (2017). Implementation of Change Management in Software Development by using Scrum Framework. International Journals of Advanced Research in Computer Science and Software Engineering, 7(7), 400–404. Salameh, H. (2014). What, When, Why, and How? A Comparison between Agile Project Management and Traditional Project Management Methods. International Journal of Business and Management Review, 2(5), 52–74.
Purchase answer to see full attachment