Picking the Right Methodology for Project Management (PM) as an IT Professional
Oof. What a mouthful title eh? All in all, let’s look at the kinds of methodology commonly used when it comes to systems or software development.
When it comes to creating and implementing new strategies for developing information systems and software, there are two kinds of methodology that project managers take, waterfall (traditional) and agile (that new ‘ish). But first, let’s get some context before we dive into discussing these methodologies. Overall, I think we should just clear up what project management means. For me, I like to think of it as a mindset or a characteristic, the mind set of achieving all project goals and objects while being constrained by certain factors. In most cases, the primary constraits are scope and quality, time, effort/resources, and budget. Here’s an image that might actually better depict this though, although there are a few different interpretations, this is the one that I was taught and agree with the most.
Here, the general constraints are whether or not the projects and milestones are being meant on time, within the budget, and without exceeding resource availability. Hopefully, time and cost make sense as to why they are considered constraints, but resource availability is a bit more broad of a term. Resource availability can be from tangible resources such as manpower and physical space to work, to the nontangible such as morale and effort from the manpower. All three of these combined will result in the scope and the expected quality. In other words, the scope is the outcome or the goal of the project, and well quality… is the quality of the project. ¯\_(ツ)_/¯ An equilateral triangle is ideal, but with most projects, there’s always going to be a hitch along the way and that’ll affect the length of the legs on the triangle, as a result, in order to maintain the same scope and quality, the other legs often have to compensate for any changes. If the budget goes down, maybe you’ll have to increase the length of the project or maybe try and bring in more people or raise morale (but the next question is what is the best way to raise morale without upsetting the scope triangle even more). Project management is so much more, but that was just a quick primer… if I have the time though, I would love to discuss this topic more because the concepts are very translational with management in medicine.
Now, onto the methodology. When it comes to large projects, there are two “factions” on the best one to choose, however I don’t see it as a battle for supremacy, I see it more as recognizing which methodology is best suited for its primary purpose. Instead of a debate on using Waterfall or Agile, it’s more important to analyze and understand the depth of this project first and then matching its outcomes with what each methodology can provide.
The traditional methodology for design and implementation. It’s much more of a formal, step by step approach to solving these kinds of problems. Because of a seemingly “rigorous” process, there is a clearly defined goal in mind and thus can help increase the probability of success. The positive thing about this method, even though it is time consuming, is that if the bugs are found early on it saves a lot of time and money later.
- Requirements Analysis – Investigate and understand what kind of system/software this is being developed to solve or facilitate? Here is where you go all “project manager” like and identify the objective, constraints and scope of the project. This is also where preliminary analyses are conducted on cost-benefit, feasibilities, implementation difficulties and other.
- Design comes in two forms, the logical design, which can be the first and driving factor of business need. Design is to help determine the infrastructure and architecture the solution needs to provide as well as design of the technologies needed. Next is the physical design in understanding the actual specific technologies needed, however it is also selected alongside possible alternatives.
- Development, I would consider this alongside physical design as well because the technologies are evaluated. Needed software is created or purchased, components are acquire, and users are trained and supporting documentation is created. This is where a feasibility analysis is prepared. If anything, this is where the “skeleton” is created and then fleshed out a little bit more.
- Testing is a quick followup for development in that the components and software are tested. Ensures that the goals and objectives are met, and any bugs are addressed and fixes rolled out.
- Maintenance is the longest and most expensive phase. It’s literally never ending until the system or software is obfuscated and obsolete. It’s important to support and modify the system as needed, thus requires a cycle of testing, adapting, and retesting. This method requires intensive documentation in each phase and in that way the process is not dependent on any individual on the team. If a component of the team needs to be replaced, the new person can understand where the project is currently, easily.
Another methodology, but instead of a formal and step-by-step process, it is more effective in flexible and frequently changing projects. Seen as a “hybrid” methodology, agile comprises of features of the “Iterative” and “Incremental” methodologies, where the former iterates in “plan, develop, test, and feedback”, whereas the latter is more “let’s just get to this goal first”.
In large projects, this might seem ideal because of the flexibility, but I would advise against that. The reason is large projects might have a longer time constraint, but that also means greater possibility of “creep” and in order to prevent that, there needs to be a strict formal process. Because it works in “iterations” or “sprints” or “scrums”, it has more capability to be flexible, thus allowing for more client interaction and testing effort. Because it is a lot less rigorous with many more incremental iterations, the phases and processes, I described above are commonly revisited again. Small “prototypes” and modules of the final product are constantly being churned out and reviewed, allowing for changes. Because there is a continuous visibility with the stakeholders, the agile methodology has truly risen in popularity among project managers lately. Many tasks can be done separately in various teams, thus delivering a compilation of work. Agile methods seem best for developmental and non-sequential projects; as such they are ineffectual in some types of projects and is not taken seriously by a lot of companies.
Unlike the waterfall methodology, transition of key individuals can prove to be disastrous, especially if these individuals were crucial to their areas, thus leading to a lack of knowledge and resource. The waterfall method also calls for robust documentation, further lessening the dependence on individuals. Because each stage must finish before the next one begins, requirements are often reviewed and approved before the next stage continues on. Usually seen as the better method in new situations, inexperienced teams, and want a strict formal process to follow. Good if you are concerned about quality and fulfilling the scope.
However, the disadvantages are the inflexibility and rigidity. Just as water that flows down a waterfall cannot come back, it is not possible to alter a completed stage or even the project design in any way. Requirements gathering upfront therefore become critical. Unfortunately, because of the distinct stages, the stakeholders may be dissatisfied with the final product. Unlike agile’s iterative concept, the development and finalization of the product is at the end and often does not require that much stakeholder interaction, and by then, if changes are needed, they can be difficult and costly to implement.
The logic is that the time spent upfront to ensure comprehensive requirements gathering and design saves considerable time and effort later.
With the agile method, testing and customer feedback can occur in multiple iterations simultaneously leading to quick development and changes. This gives priority to collaboration over design, and interaction with stakeholders is prioritized over processes and tools. Thought the agile methodology was developed to cover up the limitations of the waterfall method, the waterfall method still retains its relevance as a better method in situations where stability and formal processes are required. Agile methodology shines in smaller work areas with less overhead and project costs are not as much of a concern. Agile allows for frequent changes and testing, thus situations that require key stakeholder interaction, will thrive with agile. This is great for small to medium sized organization to ensure tight collaboration and disciplined teams. Larger organizations can work, but require strict project management, training, dedication, and awareness. Scrum is meant for agility and a continuous feature, through quick communication and cooperation, scrum and the agile methodology can be met with ease.
But one of the most difficult things about agile development is the stakeholder interaction, if the customers and stakeholders are often busy or do not have the time or interest, this essentially takes away the strength of this methodology because it’s essentially running blind without guidance, unlike what the waterfall method provides. Because of these “time-based” sprints, the products may not be achieved and thus may increase total time as well as potential project costs.
A sub methodology in the “agile” category is the “Spiral Methodology”. Although it can be considered similar in terms of agility, it is not too well-known due to potential high costs and inflexibility. It is a risk-driven model where each iteration ensures risk mitigation, but this also relies heavily on the risk analysis providing accurate and specific expertise for each iteration. There is a Planning, Risk Analysis, Development, and Evaluation phrase, but these phases are iterated and incremented, similar to what you would see on a snail shell. This is great for large projects, because each “spiral” is reviewed and analyzed, but it also allows the project to be split up into multiple parts. However, the risk monitoring can also require additional resources which will end up creating many intermediate stages that can be time-wasting.
Big Bang, another methodology is where each component is built to completion, for the full scope. Everything is integrated at the end. Incremental, ensures that each increment/milestone is completed before moving on. Iterative builds everything together and increases everything slowly but together until completion.