ICT Project Management

Discuss about the ICT Project Management.

 

 

Project methodology and its role in project management

A strategic level plan that is used for controlling the development of the software is termed as project methodology. Conforto et al. (2014) depicts that project methodology is utilized for the developing every stage of the project lifecycle- defining, planning, executing and final delivery of the project before closure which intends to accomplish a business goal in a flexible way.

Image 1: Project Life Cycle

(Source: Conforto et al. 2014)

An appropriate project methodology defines each phase of the project life cycle with accuracy. Serrador and Pinto (2015) illustrates that in the definition phase of the project development, the project methodology specifies the goals of the task for which the software is developed. Moreover, the responsibility of the software is also described in the definition phase. Conforto et al. (2014) also portrays that in the planning phase, the schedule, budget and required resources are defined with accuracy so that the software can be developed properly.

Waterfall and Agile project methodology

Compare and contrast

Mahadevan et al. (2015) depicts that both the waterfall and the agile project methodology is used for the development of software for a business purpose. However, the major problem is that the waterfall project methodology is rigid and inflexible division of each phase of the project and all the testing phase has to be done before the implementation so that the final product can be evaluated perfectly; however, an agile methodology is used to resolve the disadvantage the waterfall methodology. Balaji and Murugaiyan (2012) illustrates that waterfall model is not suitable if the requirement for developing software is not clear but in agile methodology the software can be developed even of the requirement is not clear.

Similarities and differences

Conforto et al. (2014) illustrates that in case of similarities, a project manager or test manager uses both the project methodology for developing software in a systematic manner. Each phase critically follows the project requirements- design of the requirements, designing the software, implementation of the code for formulating the software and then verification and maintenance of the software.

	Waterfall project methodology	Agile project methodology
Requirements	The requirements for developing the software have to be done before the initiation phase.	The requirements of the software development can be changed whenever necessary.
Test Planning	Software development project planning is done before testing phase.	The planning process is performed before the software development and during the project development (Balaji & Murugaiyan, 2012).
Testing Phase	Testing phase starts after the completion of each phase of the software modules	Testing phase can be incorporated into every phase of the software development
Change of requirements	The requirement of the software development cannot be changed at any stage	The requirement of the software can be changed at any phase of the software development.
Acceptance Testing	The testing of the final software is done by the customer for analyzing whether all the requirements was fulfilled or not (Mahadevan et al., 2015).	The testing of the completed software is performed by each team member for each iteration of the testing of the software

Table 1: Difference between waterfall and agile project methodology

(Source: Created by Author)

Relation with the project life cycle

In the project development cycle, the waterfall model develops the software in a sequential manner so that the progress of the formulation of software can be done in a steady manner.

Figure 2: Waterfall project methodology

(Source: Mahadevan et al. 2015)

In this phase, all the requirement of the software is noted from the customer so that the final software can be delivered to the customer (Mahadevan et al., 2015). The plan is then formulated and the test manager will initiate the designing process. The waterfall model is easy to manage due to its rigidness and the test manager possesses a special ability to depict the project objective at the beginning.

Figure 3: Agile project methodology

(Source: Bose & Thakur 2013)

However, in the agile project methodology, Serrador and Pinto (2015) portrays that the project can be delivered more quickly and there is a closer collaboration between developers and the business. Customer changes their requirements at any point of the process and test managers can improve the coding of each module for continuous improvement. Test Manager will test the feasibility of the project- financial, practically and technologically feasible. Bose and Thakur (2013) demonstrates that in both of the project methodology the responsibility does not end after the delivery of the final products, the software maintenance plays a crucial role in both the software development of the project development and update it according to the changing requirements of the customer and the business.

Reference List

Balaji, S., & Murugaiyan, M. S. (2012). Waterfall vs. V-Model vs. Agile: A comparative study on SDLC. International Journal of Information Technology and Business Management, 2(1), 26-30.

Bose, L., & Thakur, S. (2013). Introducing Agile into a Non Agile Project Analysis Of Agile Methodology With Its Issues And Challenges. International Journal of Advanced Research in Computer Science, 4(2).

Conforto, E. C., Salum, F., Amaral, D. C., da Silva, S. L., & de Almeida, L. F. M. (2014). Can agile project management be adopted by industries other than software development?. Project Management Journal, 45(3), 21-34.

Mahadevan, L., Kettinger, W. J., & Meservy, T. O. (2015). Running on Hybrid: Control Changes when Introducing an Agile Methodology in a Traditional “Waterfall” System Development Environment. Communications of the Association for Information Systems, 36(1), 5.

Serrador, P., & Pinto, J. K. (2015). Does Agile work?—A quantitative analysis of agile project success. International Journal of Project Management, 33(5), 1040-1051.