JUSTIFICATION OF THE NEED TO IMPLEMENT FLEXIBLE PROJECT MANAGEMENT
Melnychenko Olexandr,

Doctor of Sciences in Public Administration, Full Professor, Full Professor of public health and healthcare management, Kharkiv National Medical University, Ukraine

Melnychenko Vladyslav, Manica Ales
Student of the School of Management of the Technical University of Munich, Germany

To run a successful business, one has to organize their operations in a structured way. Tasks require to be identified, prioritised, and completed. There is also a need for resources to be allocated for various purposes as efficiently as possible. It is commonly accepted that the most important resource invested in any project is the human capital. This is mainly because it is the people who decide how to make the most optimal use of any given resource. Throughout decades if not centuries, various project management methodologies have been developed. These have been used to help team members of a certain project to make the most optimal short-term as well as long-term decisions over an extended period of time aimed to deliver the best possible outcome. Currently, there exist multiple project management approaches, such as, spiral, V-Model, rapid prototyping, incremental, as well as synchronize and stabilize. However, for decades Waterfall has been a go-to method. It is linear and sequential in nature and is based on the idea of a step-by-step completion of pre-set stages [1]. It is somewhat challenging to define what a true classical Waterfall version is and what are its stages since there exist multiple opinions on this matter. «Traditional SDLC Vs Scrum Methodology – A Comparative Study» paper suggests a five-step model comprised of the following stages: Requirements, Design, Implementation, Verification, and Maintenance [4].
At the same time, «Waterfall Vs V-Model Vs Agile: A Comparative Study On SDLC» paper presents a rather different sequence with six stages: Analysis, Design, Development, Testing, Implementation, and Maintenance [1]. Despite the evident differences in the composition of phases of different Waterfall versions, there is a clear consensus on the general approach. Each stage is lengthy, consists of multiple sub-stages, and does not overlap with any other stage. Once a team has completed all tasks from one stage and moved to the next one, the team does not go back [4]. This is where the method gets its name from since the whole process looks like a non-stop stream of water which runs forward through a consecutive chain of waterfalls. Another prominent feature of the method is its heavy reliance on defined goals and deadlines [1]. The methodology aims at agreeing on the requirements beforehand by assessing opportunities and risks to avoid costly last-minute iterations and modifications [1; 5]. The advantage of the Waterfall methodology is its ability to enable a solid managerial control and departmentalization. Theoretically, this should ensure more timely and reliable delivery of the product, guided by rigid deadlines and processes. As such, the methodology seems to be particularly suitable for large hardware companies with highly complicated and convoluted projects requiring coordination of vast human and other resources [5]. On the flip side, Waterfall suffers from certain shortcomings, in particular its evident rigidity regarding the workflow. The methodology does not allow for much iteration or flexibility in conducting revisions which makes it challenging to adapt to the external changes if those occur [1].
Companies develop models to better understand the world around us and employ this information in an attempt to make informed business decisions. This approach often proves to be of great value to its users, however, one should not disregard a prominent underlying bias – unlike theoretical projections, the real environment is rarely static and certain. Our world is comprised of numerous individual components where each single one of them is an unknown variable in a massive equation. Predicting what will happen in one month, let alone in a year or a decade, might be an incredibly difficult task. Moreover, there seems to be a persistent trend of continuous acceleration of technological innovation, which even further elevates the issue of high uncertainty. 

With this in mind, it becomes clearer why traditional project management approaches such as Waterfall might be relatively suboptimal tools for certain cases. In contrast, a much newer methodology called Agile was specifically designed to tackle the problem of the ever-changing environment. The method is based on four core beliefs: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. These further break down into twelve main principles and can be implemented in a number of ways. The method embraces the change as an integral part of the developmental process [2]. To be able to more quickly adjust the course of action, Agile aims at shortening the product delivery cycle which enables its users to test their assumptions as early as possible.3 In contrast to Waterfall, Agile is based on the cross-functional collaborative bursts of work with the incremental output being produced cyclically [1; 2]. The general paradigm shift hinges on the transition from attempting to predict what the customer wants to actually rapidly testing the assumptions with the customer.

The clear advantage of the methodology is the fact that since the trajectory corrections are done routinely, the sunk costs involved with these adjustments are considerably lower than with Waterfall. In other words, vital resources, such as money and time, get to be utilized more frugally and efficiently. This is perhaps one of the main reasons why Agile got adopted by numerous start-ups in a relatively short time span: young small ventures normally have access to very limited resources and are in need to find ways to make every unit count. It is worth mentioning, however, that Agile does not come without flaws. There are certain challenges of implementing the methodology in hardware companies where regular incremental product deliveries are not as commonplace as in software firms. Moreover, big companies might also be less suited for Agile with its high focus on flexibility and autonomy [3]. This most likely derives from the fact that mature companies operate on a significantly larger scale than start-ups which requires an increased amount of coordination and control that is better provided by more traditional project management methods [5].

Agile is not about a collection of new tools that will suddenly increase productivity tenfold. Instead, it is about a different mindset, where individual variables are not set in place but rather are very adaptive and interactive. This can be achieved by drastically improving the transparency of the processes on each level and in each step, namely, clarifying tasks and responsibilities as well as establishing clearer and more effortless communication channels. This, however, would not be enough, since active participation of each team member would be required to build a foundation of a self-managing, fluid, and cohesive team. To make such a leap possible, all team members have to be both motivated and empowered. Consequently, the following recommendations are important: highlight what each person can gain from a full-scale Agile adoption and also negotiate with the team manager more freedom for the team.
Further research will focus on the development of a theoretical rationale and practical recommendations for the implementation of flexible project management.
References:
1. Balaji S., Sundararajan Murugaiyan D. Waterfall Vs V-Model Vs Agile: a Comparative Study on SDLC. 2012. URL: https://mafiadoc.com/wateerfallvs-v-model-vs-agile-a-comparative-study-on-sdlc_599278c91723ddd069fb2765.html (Accessed: 12 April 2020)
2. Beck K., Beedle M. Manifesto For Agile Software Development. 2001. URL: https://agilemanifesto.org (Accessed: 12 April 2020)
3. Livermore J. Factors That Significantly Impact The Implementation Of An Agile Software Development Methodology. 2008. URL: https://pdfs.semanticscholar.org/d517/2f869445e3d2989 d1d8acba6fcee38bd2eec.pdf?_ga=2.186678894.759086983.1586688056-292372219.1586688056 (Accessed: 12 April 2020)
4. Mahalakshmi M., Sundararajan D., Traditional SDLC Vs Scrum Methodology – A Comparative Study. 2013. URL: http://citeseerx.ist.psu.edu/viewdoc/download?doi= 10.1.1.413.2992&rep=rep1&type=pdf (Accessed: 12 April 2020)
5. McCormick M. Waterfall Vs. Agile Methodology. 2012. URL: http://www.mccormickpcs. com/images/Waterfall_vs_Agile_Methodology.pdf (Accessed: 12 April 2020)