There are two person’s opinion about the discussion board questions. i have to reply them separately.
just give your opinion.
reply for person 1 post……
reply for person 2 post….
Person 1Post: Michael
Topic: Project Management Process Groups
The project management processes are described by their purposes, interactions, and integrations (Project Management Body of Knowledge [PMBOK] Guide, 2017, p. 553). A process is a succession of tasks, activities, and performances for the creation of products or services. Everything in project management is achieved through processes. Just as an atom is the fundamental unit of matter, processes are the smallest functional units of project management. Said another way, processes are the bread and butter of project management.
The project management process group or process group (pmpg) divides management functions into project initiating, planning, executing, monitoring and controlling, and closing (PMBOK Guide, 2017, p. 23; Panos, 2008). The process group is a reasonable assembly of processes into the five groups and without being too specific, it provides guidance to someone that wishes to apply the processes for prescriptive or adaptive project management (PMBOK Guide, 2017, p. 716). For instance, using the five PMI process groups in an organization implementation of the information system, A project manager carries out tasks such as stakeholder identification, plan development, performing installation, controlling scope, and obtaining customer acceptance.
The project management process groups represent the arc of a project from start to finish. Each project management process group is characterized by certain tasks that must be completed. Project-management process groups are linked through the outputs each produces. The output of one process becomes an input to another process. For instance, the planning process group provides the executing process group with the project’s plan documentation.
PMI emphasized that pmpg are functions of project management and very different from project phases. The process groups do not direct the phases of the project, are independent of application areas, or industry focus (PMBOK Guide, 2017, p. 553). Project phases are a logical collection of project activities resulting in deliverables, whereas process in each process groups are repeated in each phase until the completion criteria set up for the phase are met (PMBOK Guide, 2017, p. 667). Individual processes in a pmpg are used once, periodically, or repeatedly and continuously throughout the project or during the completion of a phase.
The PMI note that there is an incursion of performance overheads when highly adaptive projects perform all the pmpg repeatedly (PMBOK Guide, 2017, p. 667). For projects in which teams cannot clearly express scope early in the product life cycle, Schwalbe (2012) observed that the PMI pmpg can be used in an agile approach, by accepting that plan and requirements will change. When pmpg is employed for continuous and adaptive planning, time available for execution is favored more than the time available for management.
Agile adaption of project management process groups favors value delivery over the following of processes, leading to a drastic reduction in overheads of managing pmpg repeatedly (PMBOK Guide, 2017, pp. 668-671). The process is adapted to pulling tasks from a prioritized backlog or limiting work in progress in a prioritized board. Work on iterative, adaptive, and agile projects is prioritized to undertake the highest business value items first.
Panos, F. (2008). Comparing PMBOK and Agile Project Management software development processes. In S. Tmmmmm (Ed.), Advances in Computer and Information Sciences and Engineering (pp. 378-383). Dordrecht: Springer. doi:10.1007/978-1-4020-8741-7_68
PMBOK Guide. (2017). A guide to the project management body of knowledge (PMBOK guide) (6th ed.). Newtown Square, PA, USA: Project Management Institute.
Schwalbe, K. (2012). Managing a Project Using an Agile Approach and the PMBOK ® Guide. Cengage Learning. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/summary?doi=1…
Person 2 Post ; (subash)
Topic : Project life cycle”
For a project to exist, it has to start and end regardless of how small the project is. Though not all project ends well, there should be expected termination date. There are different approaches and steps that go through during this period of time in the project, which contributes to the lifecycle of a project. A project life cycle is a series of phases that a project passes through from its start to its completion (Project Management Institute, 2017, 19).
There is not one single lifecycle that can fit all types of projects. Based on the requirements, time and resources availability, budget, complexity, risk factors, etc, a lifecycle has to be determined. So it usually is the project manager’s decision on which lifecycle to follow for a particular project.
In a software project, regardless of what lifecycle we follow, it always builds around requirement gatherings, design and development, testing, and going live (production). Though the order may change based on the teams’ preferences and project lifecycle methodology, the project revolves around these phases. The project I am working on is currently in the migration phases to new technology stacks which are following agile methodology. However, the development of this project which took 7 years was done under the hybrid waterfall method. In short, the waterfall lifecycle in regards to a software project is where all the requirements are defined near the start of the project and then may be subject to change control through all the following phases (Lonergran, 2016). After this phase is completed, then only design starts. Once the design completes, then the development starts. When development completes, then the project goes live if all user acceptance tests and other user acceptance criteria are fulfilled. In this kind of lifecycle, there would be major disadvantages if the requirement changes at the end of the project lifecycle. If requirement changes at the end of the project, we have to go back to update requirements, update the already completed design, and implement the changes. The changes impact will be very costly. Also, the only product that the client or any stakeholder sees is the final product at the end of the project lifecycle. There are no phases where a complete working product can be observed. However, the client’s human resources like business experts are required only during the start of the project ( during requirement gathering). The reason this project was implemented with a hybrid lifecycle is with consideration of the facts mentioned above. The client did not want their resources to be available throughout the project on each phase, so scrum ( agile process) was out of the picture. This software was being built for states, which is driven by both federal and state laws. Though there are very few changes that come through federal laws/policies, the state law keeps changing very often. So, instead of building everything in 1 cycle, the management and client agreed to develop it in multiple iterations where each iteration will push a part of the software to production. In this way, the disadvantage of the waterfall where the user can see if progress only at the end of the project was eliminated with 5 iterations. Stakeholders can start using the product immediately after release in each iteration. Also, if any changes come during development, the changes could be added in the next iterations.
Lonergran, K. (2016, May 02). PMIS Consulting Limited. Retrieved September 21, 2020, from https://www.pmis-consulting.com/agile-versus-water…
Project Management Institute. (2017). A Guide to the Project Management Body of Knowledge (PMBOK Guide), 6th Ed. Newtown Square, PA: Project Management Institute.