PLEASE SEE ATTACHED FILES FOR ASSIGNMENT DETAIL AND INFORMATION!!!
Project Management Methodologies
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
PM670 Individual Project 2
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
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).
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).
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.
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.
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.
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
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.
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.
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
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.
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).
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
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
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).
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.
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
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).
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.
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–
Baham, C. W. (2016). Understanding Agile Software Development Assimilation Beyond
Acceptance (Doctoral dissertation). Retrieved from https://digitalcommons.lsu.edu/grad
L'Ecuyer, A., & Ahmed, S. A. (2016). Controlling change in agile software development
projects. Universal Journal of Management, 4(1), 42–49.
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
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