‘’What is measured well, can be planned well’’
With reference to the experiences shared by my colleagues and mentors (Names mentioned below), this article tries to summarize the project management methodologies and the preferences as the projects in different sectors can be executed. It will be a long read but I’m sure it will give you the insight as this topic is critically analyzed by real-life experiences.
This could be the most discussed topic among project managers when it comes to agreeing on which methodologies should we use in the project life cycle, be it waterfall approach or agile approach. I wanted to share some of my insights on how I decided which methodology should be used. I have executed a number of Infrastructure and software development projects; the difference in these projects is the key to decide which methodologies can be used.
Waterfall approach is preferred when there is extensive planning involved in the initial phases of the projects and the execution is something that works like clockwork. More generic predictive tasks are a part of such projects also the involvement of clients is nominal until the project is in its final stages of completion. From my experience, the service based Infrastructure projects are considered to fall under this category. As the scope of these projects is seldom prone to change and there is no new product that is going to get delivered, however, what is going to get delivered is service or the entire project that in turn transferred to set up operations.
‘’Fail fast and recover faster ’’ or ‘’Fail early but recover faster’’ or ‘’Not to Fail at all’’
From a QA preference, agility is better as the change requests are easily manageable, there is a flat operational hierarchy in the team means there is no boss, and every person on the team is equally responsible for the tasks. The daily status updates make it easy to have clear visibility of work done and work pending. As the QA role is more focused on inspection there is flexibility in adopting the changes post inspection, which is swift in an agile atmosphere. The major emphasis is done on capacity planning as its sprints are driven instead of planning the entire project till the end unlike in waterfall approach.
I remember working on an Infrastructure upgrade project for a client where we had to plan the project with respect to the types of equipment that we needed to procure from a vendor in China. My project team was actively involved in the initiation and planning phase and all the tasks were planned as per the requirements are given by the client, as contingency measures the number of pieces of equipment that were prone to operational damage were taken into consideration and were ordered extra with the concern to the budget and the client. The project was executed once the equipment was procured and the whole process worked as planned with successful completion of the project. Thus waterfall approach worked for me in this case. From my experience, a waterfall approach is best suited when we are dealing with clients that raise frequent changes to projects still adhering to the tight deadlines. Waterfall approach results in few change requests as there is no ripple effect throughout the project. Scenarios like this can be supported by most of the infrastructure professionals.
Large scale implementation project that is on high risk is seldom prone to change but when these projects are delivered, not in the waterfall but with an agile approach, the overall client satisfaction is increased. As I see it, every project is a waterfall in approach but splitting it into more doable pieces would make it sure that the project is delivered successfully in the end rather than having our contingency reserves depleted if the project goes out of schedule or goes into scope creep.
From the perspective of a fellow Business Analyst, the methodology depends on the complexity and deliverables of the project. Although the waterfall approach can be used for any project, when it comes to dynamic requirement gathering a more agile approach is used to accommodate the changes that are required by the stakeholders.
There was a distinct observation by one of my colleague who is an IT consultant, the waterfall approach is preferred by project managers where similar projects are executed by them previously. According to his experience, where he was implementing a project in an agile workflow for the first time. In first time projects there are a number of known unknowns, thus the methodology that should be used should accommodate the changes, as per the clients and the stakeholder, that are involved in the project.
There is one approach as explained to me by a fellow Infrastructure PM that is based on the time and nature of the project. The approach is to go with agile where the project has tight deadlines and are comparatively complex. Usually, complex projects are high budget projects and the stakeholders have a very low tolerance for risk as the success of this project is of vital importance to the organization.
I recently attended a session on agile methodology. The topic revolved around the agile manifesto, a potentially ship able product by the end of a sprint is the sole objective. Instead of waiting for a product till the end of the project small products are delivered with iterations towards improvement till the time a final desired product is offered to the client. In agile projects, clients’ involvement is crucial and the whole process gets a product delivered that is made keeping continuous improvements in mind. However, in waterfall projects, there is very less liberty for clients involved in the project unless the start or the end.
In conclusion, the agile approach is preferred by most of the professionals in the IT sector; however, a waterfall will always be a part of the Agility but as a version 2.0 or in other words more accommodative. The Kanban terminology is getting widely used in this context as it combines the rigid planning in the waterfall approach along with the change accommodating perks of an agile framework. Every project, in software development or in infrastructure, starts as a waterfall in the initial phases and it unfolds towards completion on agile terms.
It is truly fascinating how organizations are structured today all over the world, IT or Non-IT. The team involvement is paramount and always favoured as it helps to build a sense of value in the team; it gives a feeling of doing actual contribution to the organization and not just working for a paycheck. We also cannot ignore the success factor of projects that goes high when we are agile as all the stakeholders are actively involved in the project from start to end.
I invite all to share their views on the same.
- Parag Phalak, MBA, PM.
With special thanks to the responses and feedbacks given by Daniel Girma, Pritish Vaity, Krutika Dhatavkar, Hector Sandoval, Monwar Hossain, Vipul Tillo, Jay Perry and Huw Williams
#itinfrastructuremanagement #agilepm
https://www.linkedin.com/pulse/its-all-preferences-waterfall-agile-parag-p-/
