962025154305

AM804001: Project Management

Assessment 1: Case Study

Study block Date issued Due date Time Delivery: Submit to Turnitin via Moodle before deadline

Weighting 30%

Marks out of 20

Instructions Complete this cover sheet and attach to you your assignment.

This assignment must be your own work.

Collusion, copying or plagiarism may result in disciplinary action.

We advise that you keep a copy of this assignment.

Word limit is 2000

Refer to following website for reference related resources: http://www.cite.auckland.ac.nz/index.php?p=quickciteWe confirm that:

This is an original assessment and is entirely my own work.

Where ideas, tables, diagrams etc. of other writers have been used, we have acknowledged the source in every case.

This assignment has not been, nor will be, submitted as assessed work for any other academic course.

Student’s Name ID No Signature

Date Cohort Number 1

1.Introduction PAGEREF _Toc96447850 h 32.Project Management Methodologies32.1 WATERFALL32.2 EXTREME PROGRAMMING METHODOLOGY (XP)42.3 RAPID APPLICATION DEVELOPMENT (RAD)53.Critical evaluation of Waterfall64. MAORI INCLUSION IN THE PROJECT74.References9

IntroductionFor the purpose of this report, the case study chosen is the planned OPAIC management retreat for the management staff from the three campuses in Queens town. This project requires a run sheet for the three days and a high-quality conference to facilitate the meeting. These are essential to enable all management areas to discuss a strategic plan for the next 5 years, hold sessional talks, and incorporate best practice in Iwi/Maori. In the current COVID-19 situation, meetings and discussions will have to adhere to the strict health and safety protocols, ensuring safe distancing, hand washing centers, and continuous monitoring of the whole process. In order to carry out this project, three methodologies have been suggested including the waterfall, the extreme programming methodology, and the rapid application development. Out of these, Waterfall’s EMBOK is considered the most appropriate methodology to undertake the project because it is regarded as being considerate of all areas of an event.

Project Management Methodologies2.1 WATERFALLFor the development of a retreat for management employees at OPAIC, a waterfall approach would offer critical insight. In managing projects, the Waterfall approach divides a project into separate, sequential steps, with every new chapter starting only after the preceding one has been finished (McCormick, 2012). The Waterfall approach is the most common method for project management. It requires that members of a team work in a linear fashion towards a common objective. None of the stages or objectives are supposed to change, and every contributor has a well-defined function. When using the waterfall system, careful planning is essential. The criteria for a project must be clearly defined up front, and everyone working in the project must be fully informed of those needs (Chari & Agrawal, 2018). Every member of a team should also be aware of their specific position throughout the project and the responsibilities that come with that job.

The Waterfall technique is a sequential model that, among other things, operates on the basis of predefined dates, set requirements and objectives, and deliverables in order to finish a project. It is also known as the waterfall model. The nature of this method is that separate execution groups are not necessary to keep regular communication with each other and are typically self-contained, until specific integrations are required (Mitchell & Seaman, 2009). The rest of the time, team members are often free to work on their own initiative and are not required to report on their progress. Therefore, the sequential system of the waterfall approach is an advantage for the management at OPAIC.

The Waterfall technique is predicated on the premise that all project needs can be identified and comprehended ahead of starting the project. The project manager goes to great lengths to completely know the requirements of the project sponsor and his or her team (Kisling, 2019). In order to describe each phase of the project, written requirements are employed. Written requirements often consist of a single document that contains information on expenditures, hypotheses, risks, relationships, key milestones, and delivery timelines (Andrei et al. 2019). It is during the design phase that a technological solution is developed to answer the difficulties generated by the product specifications. This includes scenarios, structures, and statistical models, among other things. It is necessary to first define the project’s aim and range, as well as the general traffic flow for every element and its connectivity points. After that, a logical structure may be created. Following that, the design is transformed into a physical model (Peterson, Wohlin, & Baca, 2009). Immediately following completion of the design phase, the technical execution phase begins. The current project by OPAIC will be time consuming. It will require research and a lot of design to ensure that the project is a success. This phase entails programmers designing applications that are tailored to the needs and specifications of the project, as well as testing and implementing the applications. Depending on whether considerable alterations are needed during this phase, it may be essential to revert to the design stage for further consideration. Before it is handed over to the organization for implementation, the project is thoroughly examined for errors. After that, it’s time to set it up and start monitoring it.

In addition to the above, a combination of the Waterfall approach and the EMBOK methodology would best fit the event. EMBOK is a three-dimensional representation of the skills and knowledge required to plan, produce, and execute a function. Conferences, exhibits, celebrations, special events, public events, sporting events, and other similar activities are all included under the word “event”.  Event planners may utilize the EMBOK as a planning tool to identify activities for inclusion in a work breakdown structure (WBS), and also the documentation for continual development. Geambasu et al. (2011) calls for a thorough review of all possible problems before choosing the approach to use in the development of a project. Combining these two would greatly benefit OPAIC as it will create a hybrid structure that includes a planning tool (EMBOK) and a framework that identifies objectives and the plans towards accomplishing them.

2.2 EXTREME PROGRAMMING METHODOLOGY (XP)Being an agile methodology, the extreme programming approach primarily works for software development. Project management and software development are among the key elements covered, as well as how to increase developer productivity and the most effective manner of working together using extreme programming (Erickson, Lyytinen, & Siau, 2005). Extreme Programming (XP) is an agile development methodology that fosters quick releases, iterative development, and a high level of customer input and involvement. The Extreme Programming project lifecycle is built on the developers’ frequent iteration while executing user stories (Hazzan & Dubinsky, 2003; Salo & Abrahamsson, (2008). Customer user stories are brief, informal statements made by consumers regarding the qualities they require in order to complete a purchase. A user narrative is a standard description of a feature of a necessary system provided by the user themselves (Layman et al., 2006). More specific aspects of the subject matter are not covered, such as the numerous circumstances that may arise. The Metaphors are provided by the project team and are based on User stories. In the case of metaphors, Newkirk and Martin (2000) see them as common views of how a system may work. A spike may be created by the development team for the purpose of implementing a certain feature (Lindstrom & Jeffries, 2004). A Spike is a very simple piece of software that is designed to evaluate the feasibility of a particular solution before implementing it. A few aspects of the design are reminiscent of a prototype.

The purpose of XP is to enable small to mid-sized groups to generate high-quality software while adapting to changing and developing demands. According to Hazzan & Dubinsky (2003), XP is based on principles, philosophies, and methods. XP distinguishes itself from other agile approaches by emphasizing the technical components of software development. The six phases of the Extreme Programming project lifecycle are exploration, planning, iterations to release, production, maintenance, and death. In the exploration, the client has a critical role of writing the user story cards (Newkirk and Martin, 2000). These cards are then used in the second phase, planning, to prioritize the user stories and then schedule first release in the third phase. In production, testing and validation of a system are conducted. More ideas and useful suggestions are performed in the fifth phase, maintenance. In the last phase, the final product is transitioned where no additional stories are taken from the end user (Erickson, Lyytinen, & Siau, 2005). This approach could help the IPAC project in creating a timeline and including user stories for better brainstorming and creation of solutions.

2.3 RAPID APPLICATION DEVELOPMENT (RAD)Rapid application development (RAD) is a project management strategy that is commonly employed in the software development business today (Agarwal et al., 2000). It is also known as agile project management. The key advantage of using a RAD technique, according to Berger and Beynon-Davies (2009), is the ability to complete projects rapidly, which makes it an enticing solution for professionals that operate in a fast-paced environment such as software development or other similar industries. Further, Beynon-Davies et al. (1999) found that this rapid pace is made possible by RAD’s emphasis on shortening the planning phase and increasing the amount of time spent generating prototypes during the development process. The rapid iteration of prototypes (RAD) technique assists project managers and stakeholders in accurately monitoring progress and communicating in real time about developing challenges or adjustments. This is because planning time is decreased and prototype iterations are prioritized (Coleman & Verbruggen, 1998). As a result of this, efficiency is boosted, development is accelerated, and communication is more effective. RAD allows the breaking down of the process in four main phases: requirements planning, user design, rapid construction, and cutover.

Throughout the requirement planning phase, developers, customers (system users), and team members will be able to communicate to establish the project’s objectives and aspirations, as well as any current or projected challenges that will need to be addressed during development. A scoping meeting for a project is the inverse of this process (Hirschberg, 1998). While the planning phase is quick in compared to other project management techniques, it is critical to the project’s final success. The research phase comprises identifying the current issue, creating the project’s requirements, and finalizing them with the approval of all stakeholders. Throughout the user design phase, clients and developers work to ensure that their needs are met at every level of the design process. It’s like bespoke software development in that users may assess every prototype design at each stage to ensure that it meets their requirements. This method enables developers to iteratively modify the model until they arrive at a design they like. Rapid construction is the third step, in which mockups and beta structures are transformed from the design stage into a functioning model (Berger and Beynon-Davies, 2009). Because the majority of issues and modifications were addressed throughout the stringent iterative design phase, developers may complete the final operating model quicker than they would with a conventional project management method. Finally, the cutover phase is the launching phase, during which the completed product is made available. Conversion of data, validation, and handover to the new regime are all covered, as is user training. While engineers and consumers continue to look for system issues, all final upgrades have been completed.

In the present OPAIC project, the RAD approach would significantly influence positive communication among key stakeholders in every step of the planning process. Throughout the project, developers, customers (system users), and team members will be able to communicate to establish the project’s objectives and aspirations, as well as any current or projected challenges that will need to be addressed during development.

Critical evaluation of WaterfallThe most suitable methodology for the five-year management planning project will consider the advantages and disadvantages for each of the three approaches (RAD, XP, and Waterfall). Farrell (2008) suggested that project managers must first check how well an approach aligns to the goals and objectives of a project and the overall advantages and disadvantages created. A combined hybrid approach between Waterfall and EMBOK best fits the event for OPAIC’s management employees and their objectives.

Waterfall approach works by having teams work through a sequence of phases, each one based on the success and demands of the previous. This structure works well for smaller projects with well-defined objectives from the start, for example the proposed 3-day event to focus on management planning for OPAIC. In terms of cost, schedule, and scope, a Waterfall strategy can actually result in a more predictable final product than alternative methods. When compared to other techniques, the Waterfall methodology demonstrates the importance of a well-defined set of stages. Each project is managed according to a defined framework, including phases such as requirement gathering and documentation, systems formulation and construction, validation, dispatch, and support. Each phase must be completed before proceeding to the next, which implies that any impediments to completion must be identified as soon as feasible. Half-completed initiatives are less likely to be abandoned, resulting in a more polished end product. One of Waterfall’s unique traits is that it needs teams to commit from the start to an end result, a target, or a delivery. Teams should avoid deviating from this commitment. This stage is critical for small projects with well-defined objectives because it ensures that your team understands the overarching aim from the start, minimizing the risk of being mired down in minutiae as the project progresses. Given Waterfall’s systematic nature, it’s unsurprising that it promotes explicit communication at each level of the project’s growth. Human resource transitions are complicated by the meticulous documenting of each step of development, which enables new management to quickly obtain all relevant information upon taking over. By merging the EMBOK and Waterfall techniques, a hybrid methodology is formed that enables exact design of the project development structure, resulting in a reduction in the number of troublesome issues. A well-defined reporting structure would enable the proposed solution to provide simple administration and transparency to all stakeholders engaged in the event or project. The emergent hybrid design will work in favor of the project by ensuring that the benefits of EMBOK and Waterfall are merged in order to provide an edge in the entire project and ensure efficiency and overall success.

4. MAORI INCLUSION IN THE PROJECTMaori practice refers to the manner under which the Maori institutions like as whānau, hapū and iwi were controlled by the Maori people themselves. The heart of planning is establishing objectives and determining how to accomplish them. It lays the groundwork for the subsequent development of all other aspects of management. Future generations’ demands, the pursuit of several objectives, and the incorporation of ancestral legacies, identities, and values throughout daily operations are just a few of the imperatives that guide Maori management’ planning. Maori culture is prevalent in New Zealand’s Aotearoa region. As a result, the Maori have long been considered to be part of Aotearoa’s tangata whenua, or indigenous peoples. Manaakitanga is all about making people feel welcome and giving great service, both of which are highly valued by New Zealanders. Individuals can take part in guided tours that connect the past, present, and future. This practice will be used in the project in line with the traditions of the land.

Practice use of Māori means using Māori procedures, practices, beliefs, and structures in event management, ensuring traditional plans and practices are adhered to in line with the wishes of the people. For this specific event, the Pōwhiri practice is highly recommended. From the first karanga (calling) from the tangata whenua (the hosts) through the giving of kai, a pōwhiri incorporates the official welcome ritual out on to the marae (Maori, 1994). This technique also takes the tapu (sanctity) from the manuhiri (guests), who are known as waewae tapu (the sacred feet) if it is their first visit to that marae (Robb, Harmsworth, & Awatere, 2015). This will be relevant in ensuring that the event is recognized vis-à-vis the welcoming of all guests, the recognition of past, current, and future generations, and ensuring that utmost respect is paid to the land and its owners. The protocols include how people can manage projects. Here, Kaupapa is recommended. Prepare for an engagement process by first ensuring that there is clear identification of the intended purpose of the engagement and what is required to be achieved as a consequence of the participation. Specifically, the term “kaupapa” refers to the policy, objective, or subject matter that the organization intends to pursue in this context (Robb, Harmsworth, & Awatere, 2015). Making the incorporation of kaupapa into the overall goals of the event and project will inspire the event and project management to analyze the whole spectrum of interests and intersections in order to ensure that all significant interests are taken into consideration.

With deep roots in Mori cultural history, there is a great emphasis on the values-based belief that connections between individuals grow and depend on kanohi-ki-te kanohi exchanges in both significant and everyday circumstances (Robb, Harmsworth, & Awatere, 2015). Communication between people in person, often known as face-to-face communication, is an aspect of human behavior. It is, in fact, a fundamental premise of becoming and acting as the Māori. It enables one to not only see who or what one is interacting with, but also to hear, feel, and smell the other person or thing with whom one is communicating. When living in an era of rapidly evolving digital technology, increasing detachment, and immediate reconnection, it is critical that people discover new and creative methods to reconnect with the concept of communication and oneness created and envisioned through the kanohi ki te kanohi.

ReferencesAgarwal, R., Prasad, J., Tanniru, M., & Lynch, J. (2000). Risks of rapid application development. Communications of the ACM.Andrei, B. A., Casu-Pop, A. C., Gheorghe, S. C., & Boiangiu, C. A. (2019). A study on using waterfall and agile methods in software project management. Journal Of Information Systems & Operations Management, 125-135.

Berger, H., & Beynon-Davies, P. (2009). The utility of rapid application development in large-scale, complex projects. Information Systems Journal, 19(6), 549-570.

Beynon-Davies, P., Canre, C., Mackay, H., & Tudhope, D. (1999). Rapid application development (RAD): an empirical review. European Journal of Information Systems, 8(3), 211-223.

Chari, K., & Agrawal, M. (2018). Impact of incorrect and new requirements on waterfall software project outcomes. Empirical Software Engineering, 23(1), 165-185.

Coleman, G., & Verbruggen, R. (1998). A quality software process for rapid application development. Software Quality Journal, 7(2), 107-122.

EMBOK. The EMBOK Model. https://www.embok.org/index.php/embok-model

Erickson, J., Lyytinen, K., & Siau, K. (2005). Agile modeling, agile software development, and extreme programming: the state of research. Journal of Database Management (JDM), 16(4), 88-100.

Farrell, A. (2008). Selecting a software development methodology based on organizational characteristics.

Geambasu, C. V., Jianu, I., Jianu, I., & Gavrila, A. (2011). Influence factors for the choice of a software development methodology. Accounting and Management Information Systems, 10(4), 479-494.

Hazzan, O., & Dubinsky, Y. (2003). Teaching a software development methodology: the case of extreme programming. In Proceedings 16th Conference on Software Engineering Education and Training, (pp. 176-184).

Hirschberg, M. A. (1998). Rapid application development (rad): a brief overview. Software Tech News, 2(1), 1-7.

Kisling, E. (2019). Transitioning from Waterfall to Agile: Shifting Student Thinking and Doing from Milestones to Sprints. Proceedings of Southern Association for Information Systems, 14, 1-2.

Layman, L., Williams, L., Damian, D., & Bures, H. (2006). Essential communication practices for Extreme Programming in a global software development team. Information and software technology, 48(9), 781-794.

Lindstrom, L., & Jeffries, R. (2004). Extreme programming and agile software development methodologies. Information systems management, 21(3), 41-52.

Maori, D. M. (1994). Maori health perspectives. Social science & medicine (1982), 20(5), 483–486. https://doi.org/10.1016/0277-9536(85)90363-6.

McCormick, M. (2012). Waterfall vs. Agile methodology. http://mccormickpcs.com/images/Waterfall_vs_Agile_Methodology.pdf

Mitchell, S. M., & Seaman, C. B. (2009). A comparison of software cost, duration, and quality for waterfall vs. iterative and incremental development: A systematic review. In 2009 3rd International Symposium on Empirical Software Engineering and Measurement, (pp. 511-515).

Newkirk, J., & Martin, R. C. (2000). Extreme programming in practice. In Addendum to the 2000 proceedings of the conference on Object-oriented programming, systems, languages, and applications (Addendum), (pp. 25-26).

Peterson, K., Wohlin, C., & Baca, D. (2009). The waterfall model in large-scale development. In International Conference on Product-Focused Software Process Improvement, (pp. 386-400). Berlin.

Robb, M., Harmsworth, G. R., & Awatere, S. (2015). Māori values and perspectives to inform collaborative processes and planning for freshwater management. Landcare Research.

Salo, O., & Abrahamsson, P. (2008). Agile methods in European embedded software development organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum. IET software, 2(1), 58-64.