By Ella Ponsford- Gullacci, MBA., PMP, and Dr. Sarah Dyson
Information Technology governance covers a broad spectrum of topics, which is to ensure that an organization is effectively and efficiently using IT resources while protecting the organization from nefarious entities seeking to steal data (Almgren & Skobelev, 2020). Several systems help IT organizations govern the technology and provide project planning. The article presents the system development life cycle (SDLC) for the Waterfall and Agile/Scrum development methodologies and discusses the associated project planning.
System Development and Project Planning in a Changing Environment
System development methods and project planning have continuously evolved to reach levels of maturity designed to lead to success (Dadhich & Chauhan, 2012). Early systems development was predictive; each step was carried out, one after the other. Following the Agile Manifesto, both system development and project planning adopted iterative methods. The agile methods had the advantage of breaking long systems development cycles into smaller pieces and delivering usable products to customers much sooner. While agile methods have become popular, research suggests that Waterfall has not been abandoned altogether (Dadhich & Chauhan, 2012).
Systems Development Life Cycle (SDLC) and Development Methodologies
The SDLC is a set of steps that organizations follow to bring systems from inception to disposal (Valacich & George, 2016). It covers the necessary business rationales and budget allocations, including designing and building the system. Finally, the SDLC stipulates maintenance and end of functional life tasks (Valacich & George, 2016). On the other hand, system development methodologies (SDM) define the processes employed to define, design, and develop a system. For example, Waterfall and Agile/Scrum are two widely different methodologies at first inspection. However, both methodologies fundamentally perform the same processes leading some organizations to create a hybrid.
Waterfall
The waterfall methodology acquired the name because each step follows the other, much like a waterfall that collects water, fills up, and passes to the next level. For example, a typical waterfall model begins with a requirements definition stage, designing a solution, software development and unit testing, stakeholder testing, and implementation (Valakati & George, 2016). Each step in the Waterfall equated with a milestone; the next phase would begin when the milestone was complete. The drawback to Waterfall is that all projects flow from one step to the next without incident. However, this is an unrealistic situation for most system development work.
| Strengths | Weaknesses |
| Works well for small projects with known requirements | Customers have little input following the requirements definition phase |
| Freezing requirements avoid delays and overruns | Customers do not interact with the system until testing, which may be too late to correct misunderstood requirements |
| Provides structure | Integration is often a big-bang approach |
| Opportunities | Threats |
| Ideal for updating existing systems | Requirements are set, and changes are postponed to another phase or not completed. |
| No technology surprises; technology is known. | Customer involvement is minimal |
| Requirements are known and frozen. | Integrating with existing systems can introduce risks |
| Table 1 – Waterfall SWOT Analysis |
The primary strength of Waterfall is that it is best suited to projects where the requirements are unlikely to change. Conversely, the primary weakness, and threat, is that Waterfall projects have limited customer involvement, often leading to rework, delays, and cost overruns.
Agile/Scrum
The agile methodology was created by a group of 13 software engineers that wanted to establish values and principles leading to delivering higher-quality software faster (Gheorghe et al., 2020). Agile’s goal is to involve the customer from the beginning of the development cycle. Then, the customer, or product owner, works with the team to establish a product backlog. The backlog is worked through in sprints – short bursts of development that lead to incremental deliverables (Gheorghe et al., 2020). On the other hand, Waterfall delivers one complete product at the end of development and testing.
| Strengths | Weaknesses |
| Works well for projects where requirements are not fully known. | The iterative nature of Scrum leads to difficulties in defining budgets and timelines. |
| The customer is involved throughout the process. | Agile is not suitable for all projects. |
| Scrum standup meetings mean that the team is always aware of progress and that risks can be identified and dealt with early. | Some organizations do not fully implement Scrum as designed, leading to product issues. |
| Opportunities | Threats |
| Agile is ideal for pushing out working software and relationship building with stakeholders. | Constantly changing requirements can cause projects to be perceived as endless. |
| Problems are identified and resolved early. | The organization may not be ready to embrace Agile. |
| Change is encouraged, not forbidden. | Risk management needs careful attention. |
Agile has become synonymous with the rapid delivery of working software (Gheorghe et al., 2020). The progressive elaboration of features and functionality improves the likelihood of systems acceptance. Additionally, customer involvement helps with system acceptance. Unlike Waterfall, systems are not left unused. However, there is the possibility of long, drawn-out projects due to constant changes in requirements.
In conclusion, the differences between Waterfall and Agile SDLCs found in the latter’s predictive and iterative flow (Gheorghe et al., 2020; Sasankar & Chavan, 2011). IT architects need to know the service capabilities and what it expects to gain by implementing a structured governance framework for project planning. Waterfall progresses steadily from one step to another throughout the life of the systems project. On the other hand, while some upfront planning is done to establish a backlog for agile development, its primary strength is the iterative flow and change acceptance. Therefore, a best-fit SDLC would depend on the organization’s maturity and readiness to adopt agile.
How much planning is dependent upon the SLDC
Before planning occurs, however, organizations decide which projects will further the organization’s strategic plan (Kalumbilo & Finkelstein, 2014). First, organizations identify goals and objectives. The goals and objectives lead to tactical steps. Some tactical steps, not operational, are represented by projects. System projects have become increasingly complex due to the interdependencies between technologies in an organization’s portfolio (Kalumbilo & Finkelstein, 2014). Some projects require specialized technology, while others may incorporate existing hardware. Aligning the project with everyday purchases requires planning for both to coordinate.
Strategic planning is usually done at the senior executive level, while systems acquisition is the purview of information technology (IT) management. The senior-most IT executive needs to be involved in the strategy to ensure IT aligns with the strategic planning. Strategy and acquisition require stakeholder management and constant communication (PMI, 2017).
Systems planning requires a cross-functional team to ensure that the organizational needs align with the systems strategy (Valacich & George, 2016). Key stakeholders, including those from the business and IT, should be involved from the start of planning. Keeping communications open and continuous is beneficial. When an IT team is planning for refreshing, expansion, or project-related systems acquisitions, the right people with the right skills need to be involved early and often.
The system development team should consist of professionals with the needed development skills. However, communications and infrastructure representatives are needed to ensure that new software is compatible with existing systems and infrastructure. A critical task for the project manager is to schedule tasks that consider resource availability (PMI, 2017). Existing budget constraints and scope requirements often lead to a make-or-buy decision.
Architects may ask whether developing or purchasing is decided based upon established criteria, such as the availability of commercial off-the-shelf (COTS) software that meets organizational requirements. Budget and available financing contribute to the decision process, as do the post-implementation costs of maintenance and upkeep (Valacich & George, 2016). While purchasing a fully developed system is convenient, costs are often high. On the other hand, developing a system from the bottom-up house is not inexpensive.
- In-house development raises several questions: are the needed skills in-house?
- Will the organization have to hire or train new employees?
- Is there a location available to seat an onsite group of developers hired for the project?
The final decision is usually made on costs and payback. If the project takes longer to pay for itself, it may not be prudent to develop.
In summary, the relationship between strategic planning and systems planning is critical. IT has become a key element in supporting the business strategy (Kalumbilo & Finkelstein, 2014). IT development projects are crucial to supporting the strategy; however, the main risk to success is aligning strategy and IT support. Involving all the key team members from the initiation of planning and throughout the project and ensuring clear communications are positive steps toward aligning IT and strategy (Kalumbilo & Finkelstein, 2014).
Professor Ponsford-Gullacci and Dr. Dyson are part of the capstone team in the Project Management Program at Harrisburg University Science and Technology.
References
Almgren, R., & Skobelev, D. (2020). Evolution of technology and technology governance. Journal of Open Innovation: Technology, Market, and Complexity, 6(2), 22. https://doi.org/10.3390/joitmc6020022
Dadhich, R., & Chauhan, U. (2012). integrating cmmi maturity level-3 in traditional software development process. International Journal of Software Engineering & Applications, 3(1), 17. http://www.demix.org/images/3112ijsea02.pdf
Gheorghe, A. M., Gheorghe, I. D., & Iatan, I. L. (2020). Agile software development. Informatica Economica, 24(2), 90-100. http://www.revistaie.ase.ro/content/94/08%20-%20gheorghe,%20gheorghe,%20iatan,.pdf
Hoffer, J. A., George, J. F., & Valacich, J. S. (2014). Modern systems analysis and design. Boston, Mass: Pearson.
Kalumbilo, M., & Finkelstein, A. (2014, June). Linking strategy, governance, and performance in software engineering. In Proceedings of the 7th International Workshop on Cooperative and Human Aspects of Software Engineering (pp. 107-110). https://doi.org/10.1145/2593702.2593722
Sasankar, A. B., & Chavan, V. (2011). SWOT analysis of software development process models. International Journal of Computer Science Issues (IJCSI), 8(5), 390. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.642.2509&rep=rep1&type=pdf#page=400