According to Kerzner (2010), “Success measures for projects are determined during the first steps in the engagement by the client and the project team. It is done by designing the proposal/scope – of – work (SOW) document.” This process is carried out by a Project Manager. In other words, this person plans, explains to the project team their individual contribution and how their active input, contributes to project success (Kemp, 2006, p. 21).
This essay will focus on Information Technology Project Management. That is the application of the skills, knowledge and methods of project management to deliver a project that is on time, according to budget and specification (APM 2006, p. 2).
There are two main methods of managing a project. A general summary of the agile approach, as well as the Scrum process, will be explained. In addition, the Waterfall method along with the spiral model, will be discussed respectively. As this essay progresses, a critical analysis considering the edge, shortcomings and major variance of the Agile and Waterfall Methodologies, will be considered in terms of project success.
risk management that is the well-organized process of identifying, analysing and monitoring Project risk (PMBOK, 2004, p. 111) will be explained. Furthermore, the practice of stipulating requirements by analysing stakeholder needs and the method of systematically studying and fine-tuning those specifications known as Requirement engineering will also be explained, in terms of its relevance to project success. A conclusion will get documented at the end of all these findings and recommendations about best practices will be delivered. “The highest priority is to satisfy the customer through early and continuous delivery of valuable software” (Hass, 2007, p. 4).
The Term Paper on Project success: success factor and success criteria
... project success. He states that the existence of an effective benefits delivery and management process that involves the mutual co-operation of project management and line management ... A detailed breakdown of the Square Root is explained in table 1. Iron Information Benefits Benefits Triangle ... the earned value method. The Earned value method in a project can demonstrate it the project is on track, ...
This is a statement from the agile manifesto that was compiled by a group of seventeen people called the Agile Alliance. They set up the basic structure of agile in February, 2001 in Utah, USA. It is a project management method that is flexible and allows an iterative and incremental development to managing a project. This means that it ensures the client works closely with the software developers, to make sure the desired outcome gets archived (Hass, 2007, p.3).
In addition, it releases small parts of the application to reduce risk (Dawson, 2009, p. 128).
According to the agile manifesto (Agilemanifesto, 2014) there are some principles associated with the agile approach. These principles stress the prominent status of developers and how they collaborate with customers. They also emphasize on early and continuous release of the project, and they have a very high tolerance to change in requirements. The various agile methodologies are Scrum, Extreme Programming, Lean, Dynamic Systems Development Method, Crystal, and Feature-Driven Development (Wysocki, 2014, p. 51).
They share many of the same values, characteristics, and practices but a different standpoint when it comes to implementation (ibid.).
Scrum is a project management model suitable for projects with complicated requirements (Wysocki, 2009, p. 331).
The name Scrum is a Rugby strategy that uses teamwork to return a ball that has gone out of play, back into the game. (Wysocki, 2009, p. 451).
In Scrum, projects pass through a set of iterations called sprints. The length of a sprint can be as short as one to two weeks or could stretch up to one month. However, the software development team is in total control of deciding how long it lasts. Everybody in the project team works mutually to achieve the set of tasks they have collectively pledged to develop during a sprint. A concise gathering named The Daily Scrum is held every day during the sprint, and it aids in establishing the view of the day’s job (Schwaber, 2004, p. 28).
The Essay on Task dependencies in developing project network diagram
In assessing the impact of constraints on determining task dependencies for development of a project network diagram, it is pertinent to understand the terms as used in relation to project life cycle. Project Diagram: ‘A pictorial representation of the sequence in which project work can be done’ (Wysocki, 2012). Verillon Advisory noted that the visual presentation (graphically) of all tasks in the ...
When a sprint ends, the small part of the application that got developed is tested, and if it works correctly, it is considered as shippable. The shippable software gets deployed to get feedback from the client (Wiegers and Beatty, 2013).
The three major roles, when implementing Scrum, are scrum master, product owner, and the team (Schwaber, 2004, p. 55).
The Scrum Master helps the project team and the product owner overcome obstacles. While, the product owner ensures the business rules are followed, makes plans and sets the priorities in terms of the product backlog. The team converts these backlogs into shippable products during the sprint (ibid.).
The waterfall project process follows a sequential pattern i.e. from top to bottom thus, the term waterfall (Dalcher and Brodie 2007, p. 12).
It is a rigid and sequential method to project management. In addition, it follows a command and control management style (Wysocki, 2012, p. 42).
With this approach, each stage of the whole project has been given a deadline and planned before the project commences. For this reason, starting any project needs a clear plan and vision Emphasis is laid on project planning and documentation (Wysocki, 2012, p. 42).
With this, timetables and budgets are more accurate, which leads to customer satisfaction. The main stages of a Waterfall approach are requirement analysis, design, implementation, testing/verification and maintenance (Dalcher and Brodie 2007, p. 12).
Application of a waterfall model can be either incremental or linear Wysocki (2012, p. 42).
The spiral model is comparable to the incremental waterfall approach, with extra stress on risk analysis. The four stages of this method are Planning, Risk Analysis, Engineering, and Evaluation (Dalcher and Brodie 2007, p. 17).
During the planning stage of this model, requirement specifications are collected and documented. In addition, a procedure is carried out to know the risk involved in the project and prepare an alternative solution. At the end of this stage, a prototype is created, and if there is any risk found while analysing, a different solution is suggested and implemented. The actual project gets developed in the engineering stage of the spiral model and testing is done at the end of this stage. The evaluation stage is the time when customers can appraise output of part of the project that is ready before the next spiral commences (Westfall, 2009, p. 133).
The Essay on Cost-Benefit Analysis and Project Budget
... Project Waterfall development has distinct goals for each stage of development. The key features of Waterfall (Traditional Methodology) are: * The Waterfall ... and is a well known project methodology approach. Overall we believe these two ... It involves defining the hardware and software architecture, specifying performance and security ... after installation, and involves making changes to the system or an ...
An example of the linear waterfall project management approach is the structured system analysis and design model (SSADM).
Project success or failure is often defined by the ability of a project to react to change (Robert and Micah, 2006).
For this purpose, a project manager needs to make a plan that is flexible and ready to fine-tune to changes in the business environment. The agile approach allows customers to work closely with the developers, to ensure the desired outcome is reached (Hass, 2007).
It gives a fabulously flexible design pattern, encouraging a change in plan during development. A small part of the software gets developed during a sprint, and feedback is obtained from the client concurrently (Highsmith, 2002, p. 245).
This process allows the customer to spot the features they do not like and add new features to make the software more up to date with new trends in their field. On the other hand, a waterfall approach does not consider the changing needs of the customer. Just like water flows over the edge of a waterfall and does not flow backward, this approach has a pattern related to the real waterfall.
Requirements agreed upon at the beginning of the project are almost impossible to restructure (Wysocki, 2012, p. 42).
Changing the design at any stage of the software development can be chaotic. It is extremely uncompromising and rigid. The rigid structure refers to the fact that, if a fault is in the initial requirement of the project, the entire process has to start all over (ibid.).
Although the waterfall model is intolerant to change, this helps focus on delivering the project at the agreed time (Wysocki, 2012, p. 39).
It is a success factor, considering a plan that has a fixed requirement and delivery date. It will be easier to make an adequate plan to deliver the software, on the agreed date and time. However, because of tolerance to change in an agile project management approach, it is hard to stick to a final release date because of the requirement changes (Blankenship et al., 2011).
The Essay on Project Risk Management Plan 2
First of all we identify our project risks, which are let us know what to expect in the future and how to act during the problem. 1) Risks identification – We highlighted couple categories of risks, which are most important to be ready against them. Procedural and technical failures – from failures of internal systems and control errors, organization, fraud, technical failures. Such as non- ...
Imagine a scenario, whereby the software application is essential to a particular event, and the client makes several significant changes to the initial requirements.
It will lead to an extension of the release date and eventually when the project is ready it will be useless to the client. So using the waterfall model will be a key factor for project success in this scenario. Wysocki (2014, p. 46) explains that testing runs in one of the last stages of a Waterfall project management approach. It means that if a bug exists in a part of the software written at the beginning of the project, the chances that this bug will affect the future areas of the software is very high. It makes fixing this bug time-consuming and very expensive. On the contrary, when an agile sprint is complete, the unit of the application undergoes testing, and if it works correctly, it is then deployed to get feedback from the client. If the feedback is negative, an iteration begins to effect the changes (Wiegers and Beatty, 2013).
It is easier to identify bugs earlier with this approach.
According to Stepanek (2005, p. 38) documentation is a significant part of software development. It is a secure storage for the team’s knowledge about the project. The waterfall documentation process is more reliable than agile because it is plan oriented (Wysocki, 2012, p. 42).
An example would be the case whereby a developer leaves a project. In this case, it is easier for a new software developer to take his position, following the documentation without issues because this approach necessitates thorough documentation and planning. In the case of Agile, communication between customers and developers is favoured over excessive documentation (Agilemanifesto, 2014). Developers need to be committed for the duration of the project, for this approach to work effectively. If one person leaves the development team, it could become a disaster as it will be difficult for a new developer to step into the shoes of the one who quit. Neither the Agile nor the Waterfall approach is fundamentally better than the other.
The Research paper on Project Risk Management – Fluidity in Risk Planning Case Study
Professor Hurst Fluidity in Risk Planning – A Case Study One of the most important steps within a project is risk management because it plans for and responds to risks that impact the overall project deliverables including budget and timeframe. Risk management is used to mitigate risk in ways that align with each individual risk and its potential impact. During the risk management process risks ...
Each approach has its uses for instance; Waterfall inclines to be best for static projects, where many changes will not occur throughout the process. In contrast, Agile is better when the end goal of the project is not clear, the requirements are hazy and the business environment is ambiguous. Agile requires a team of skilled developers who have excellent communication skills and a solid principle of teamwork. Nevertheless, with the extent of customer participation and tolerance to change, Agile has a higher success tendency over the waterfall model in the ever-changing business environment. In order to boost the possibilities of project success, it is essential for a project manager to understand prospective risks (Mobey and Parker 2002).
Then systematically and quantitatively evaluate these risks, predict possible causes, effects, and select a suitable approach to managing these risks (ibid.).
Risk is an unlikely occurrence that holds a positive or negative impact on a project’s goals (Wysocki, 2009, p. 40).
When negative events are planned for in advance, it will lead to project success because a line of action would be in place for the event. PMBOK, (2004, p. 111) defines risk management as the well-organized process of identifying, analysing, responding and monitoring Project risk. It means that, the process takes account of exploiting the possibility and costs that definite risks have, reduces the likelihood and costs that negative risks attract. Risk management processes need to be clearly built into decision-making so as to ensure that the potential risks get managed efficiently (Lam et al., 2007,).
This process is used to examine, regulate, reduce loss, mitigate risks by proper planning, avoid dissatisfactory projects and improve profit margins (ibid.).
It is an essential tool for determining project viability. The principles of risk management promote quality development and budget estimation by identifying and mitigating possible risks before the project starts (Kouns and Minoli, 2010).
The Term Paper on Risk Management Plan 4
Introduction: Information security continuous monitoring (ISCM) is defined as maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions. This publication specifically addresses assessment and analysis of security control effectiveness and of organizational security status in accordance with organizational risk tolerance. ...
To ensure a project is successful, it sets processes that give stakeholders the correlated risk notice early, so as to take remedial actions that will allow a realistic time and budget estimates (ibid.).
These principles develop team participation, by implementing a tool for reporting possible problems and increasing the team’s involvement in the overall project success (Hodge, 2002, p. 18 – 22).
Recording risk is a lasting process that ensures that these unlikely events get considered in decisions making process (ibid.).
The purpose of recording these risks is to trace the actions taken to reduce risks. It presents backup strategies that should get summoned, if a risk occurs and has details of cost involved in mitigation of risks. The record can also be used to prove that risk management has taken place (Wysocki, 2009).
Elkington and Smallman (2002), have acknowledged that there is an obvious link, connecting the measure of managing risk practiced during a project and the height of success in a project.
They also discovered that when risk management got implemented early in a project, the chances of project success is very high. Also, it is important for risk to get estimated at the project brief stage because it helps the generation of the necessary project outcome and raises the chances of the overall success. It will become a real problem in the life cycle of a project if a significant risk is not identified and mitigated (ibid.).
A software project that gets accomplished within the anticipated time frame and cost, apparently shows that the requirements were understood and documented correctly in the early stage of the project. Requirement is a software competence desired by the user, to resolve a problem or accomplish a goal (Leffingwell and Widrig, 2000).
Owing to this, all software consists of several requirements. If one of the requirements gets omitted, the project cannot be considered as successful.
Requirement engineering represents both the practice of stipulating requirements by analysing stakeholder needs and the method of systematically studying and fine-tuning those specifications (Hofmann, 2000).
The principal outcome of requirement engineering is a specification. A specification is a brief account of the requirements that software must gratify. That is, the condition and capabilities a system must have, to conform to a standard (ibid.).
Preferably, a specification allows stakeholders to swiftly study about the software, and developers to comprehend what needs to get implemented. Requirement Engineering comprises of four distinct but connected activities namely, elicitation and analysis, modelling, validation and verification (Hull et al., 2005).
These activities will most likely contrast in timing and intensity for different projects.
Typically, the first process would be to elicit requirements from whatever sources available (repositories, current software, or experts).
The process of eliciting and modelling requirements are interconnected (ibid).
Modelling illustrates a supposed way out in the perspective of an application domain using formal, informal, or semi-formal notations (ibid.).
The continuing normalisation of such ideals in terms of the requirements clues to an acceptable candidate specification, which must be validated and verified (Grady, 1998).
This process helps stakeholder’s correct misinterpretations as early as possible, by giving them the analysis of their requirements (ibid.).
Requirement elicitation is a matter of talking to customers or evaluating documents, but there are more than one elicitation techniques offered (Hossenlopp and Hass, 2008).
Some lay emphasis on group sessions in terms of focus groups or workshops; there are others that are engaged mainly to elicit requirements for precise kinds of systems(ibid.).
For instance, developers regularly use sorts, laddering methods, and repertory grids in stating knowledge –based systems. It also contains those actions that search how software can meet organisational objectives, what substitutes exist, and how they impact stakeholders (Sommerville, 2011, p. 100).
Modelling Specialists have recommended many modelling techniques and specification languages for precise and consistent requirements (ibid.).
By tradition, these procedures have divided the functional, behavioural, and data aspects of requirements and stated software by making one or more different models. Prototypes strive to produce a working model that stakeholders can experience right away (Pohl and Rupp, 2011).
According to Young (2004), the idea of validating requirements is to guarantee that they meet the stakeholders’ purposes. In other words, validation makes sure these requirements conform to stakeholder business rules. On the other hand, Verification defines if specification conforms to the allocated requirements (Hull et al., 2005).
It means that, it examines a specification for inner consistency by mathematical proofs or inspection techniques. Prioritising requirement is an important point in validating and verifying requirements. Taking care of high -priority needs before considering low-priority once, can reduce the cost and duration of a project (ibid.).
In conclusion, project management is necessary and choosing an approach that best suits a project is essential to project success. Although there are different methodologies for the project management, Agile and waterfall are the two primary methods. It is clear that a Waterfall approach supports a sequential structure. In addition, it goes through the requirement engineering, design, implementation, testing and deployment phases respectively. Once a phase is concluded it is almost impossible to revert to the previous stage. Agile is a flexible approach and supports an incremental and iterative approach to project management. It encourages collaboration between the customer and the development team.
The team observes the principles of the agile manifesto throughout the lifecycle of the project. It is clear in this essay that, both approaches have their edge and shortcomings. Determining a methodology to accomplish a project is entirely dependent on the type of project. The liberty agile presents, to change, is paramount to project success. So if there is a plan that all the requirements are vague and the result is hazy, it is recommended to use an agile approach. On the other hand, a Waterfall model can be used when there are not ambiguous requirements. In other words, all requirements are known and fixed. Risk management and Requirement Engineering are paramount in the lifecycle of a project. Proper risk management helps in predicting the outcome of the project while Requirement Engineering contributes to communicating and identifying the purpose of a project, and the circumstances in which it will get used. So efficient project planning, correct requirement engineering, appropriate use of a project management methodology and effective risk management will lead to project success.
References
Agilemanifesto.org, (2014).
Manifesto for Agile Software Development. [Online] Available at: http://www.agilemanifesto.org/ [Accessed 23 Nov. 2014]. APM. (2006).
Association for Project Management 5th ed. Buckinghamshire: British Library Cataloguing. Blankenship, J., Bussa, M., Millett, S., Lewis, R. and Foggon, D. (2011).
Pro Agile .NET development with Scrum. [New York]: Apress. Dalcher, D. and Brodie, L. (2007).
Successful IT projects. London: Thomson Learning. Dawson, C. (2009).
Projects in computing and information systems.2nd ed. Harlow, England: Addison-Wesley. Elkington, P and Smallman, C (2002).
Managing project risks: a case study from the utilities sector. International Journal of Project
Management, 20(1), pp. 49 – 57.
Grady, J. (1998).
System validation and verification. Boca Raton: CRC Press.
Hass, K. (2007).
The Blending of Traditional and Agile Project Management. PM World Today, Vol. IX (Issue V).
Highsmith, J. (2002).
Agile software development ecosystems. Boston: Addison-Wesley. Hodge, N (2002) Power to the people. Internal Auditing and Business Risk. Hofmann, H. (2000).
Requirements engineering. Wiesbaden: Deutscher Universitäts-Verlag. Hossenlopp, R. and Hass, K. (2008).
Unearthing business requirements. Vienna, VA: Management Concepts. Hull, E., Jackson, K. and Dick, J. (2005).
Requirements engineering. London: Springer. Kemp, S. (2006).
Project management made easy. [Irvine, CA]: Entrepreneur Press. Kerzner, H. (2010).
Project management best practices. Hoboken, N.J.: John Wiley & Sons. Kouns, J. and Minoli, D. (2010).
Information technology risk management in enterprise environments. Hoboken, N.J.: Wiley. Lam, K C, WANG, D, Lee, P T K and Tsang, Y T (2007) Modelling risk allocation decision in construction contracts. International Journal of Project Management, 25(5), pp. 485 – 493.
Leffingwell, D. and Widrig, D. (2000).
Managing software requirements. Reading, MA: Addison-Wesley. Marchewka, J. (2003).
Information technology project management. Hoboken, NJ: Wiley. Mobey, A and Parker, D (2002) Risk Evaluation and its Importance to Project Implementation. Work Study, 51(4), pp. 202- 206.
PMBOK, (2004).
A Guide to Project Management Body of Knowledge. 3rd ed. Pennsylvania: Project Management Institute. Pohl, K. and Rupp, C. (2011).
Requirements Engineering Fundamentals. Sebastopol: Rocky Nook. Robert C, M. & Micah, M., 2006. Agile Principles, Patterns, and Practices in C#. 1st ed. s.l.:Prentice Hall. Rosenau, M. and Githens, G. (2005).
Successful project management. Hoboken, N.J.:J. Wiley. Schwaber, K. (2004).
Agile Project Management with Scrum. Redmond, Washington: Microsoft Press. Sommerville, I. (2011).
Software engineering. Boston: Pearson. Stepanek, G. (2005).
Software project secrets. Berkeley: Apress. Wiegers, K. and Beatty, J. (2013).
Software requirements: Best practices. 3rd ed. Redmond, Washington:
Microsoft Press. Wysocki, R. (2009).
Effective project management… 5th ed. Indianapolis, IN: Wiley Pub. Wysocki, R. (2012).
Effective Project Management: Traditional, Agile, Extreme… 6th ed. Indianapolis, IN: John Wiley & Sons, Inc., Pub Wysocki, R. (2014).
Effective Project Management: Traditional, Agile, Extreme… 7th ed. Indianapolis, IN: John Wiley & Sons, Inc., Pub. Young, R. (2004).
The requirements engineering handbook. Boston: Artech House.
