Standardize frameworks adopted by the development team
Development has always been a key essence to meeting the needs of society. Every field has dedicated teams that work on developing products and services to meet the demands. To ensure the successful development of these projects, different frameworks have been introduced for different scenarios. These frameworks mainly referred to as project management models, outline certain guidelines which should be followed to carry out a project.
These standardized models help the team and the client to communicate how the process will be carried out and minimize the risks of strategy clashes. Waterfall, scrum, kanban, rapid action development, and critical path are some of the prominent project management models that are widely used to ensure an organized development process.
It is a traditional approach, being applied for a long time, to project management. As suggested by the name it follows a sequential and linear development process where one step has to end for the other to begin. The 6 stages of this method include requirements gathering, analysis, design, implementation, testing and deployment, and maintenance in the respective order. Since one thing depends on the other, the quality of work and measurements for accuracy are very important. It won’t be wrong to say that it requires the “measure twice, cut once” approach.
Since it requires a predefined and well-documented scope, as well as estimations, it is better to use it when the final goal is clearly known and the project is consistent and predictable. Similarly, it can be used when proper documentation for the project is being done. In cases where the stakeholders are not clear about the goals and want to give continuous feedback, it is not suited as it does not cater to changes that easily.
Scrum is a very famous model that implements the agile project management methodology. In this, the work is split into sprints, a short spell, which lasts for 1 to 2 weeks. At the start of the week, each team member takes use cases from the backlog in which the use cases are placed according to their priority. They work on the selected use cases for the entire sprint and then once the sprint ends the incomplete ones are added back and new ones are chosen through the same process. This means that in the next sprint one use case that was not completed can be chosen by some other member. Scrum masters are assigned to separate teams to monitor the average use cases being completed each sprint, evaluate the direction in which the project is going and then suggest changes based on the evaluation. A short stand-up meeting is also held before the start of each day to discuss the progress of each member.
It is best to use when the client wants to be involved in each stage of the process and the project is prone to changes because the outcome of the project is not clearly defined. Since it involves continuous client interaction, speedy work is required so this is not recommended in cases where a lot of documentation is needed and the team is not motivated enough.
Kanban is a Japanese word that literally means ‘billboard’. It is a famous framework that also involves the agile project management methodology. In this, the progress of the project is visually represented on the kanban board. There are mainly four columns on the board: ‘to do’, ‘in progress’, ‘completed’, and ‘backlog’. The backlog contains all the use cases which are added to the to-do column once chosen by the team members and then shifted to the following columns according to the progress. This visual and organized representation helps to identify the bottlenecks and monitor the work-in-progress limits.
It is highly recommended when a visual representation of the progress is required to evaluate the project status at a glance and monitor the WIP limits so the team stays focused. Moreover, it is preferred when you want to work with a continuous pull system from the backlog. However, it is not suggested for complex projects that involve a lot of stages.
As evident from the name RAD is a model introduced following the agile approach with the aim to deliver fast. It is based on the prototyping and iterative model with minimal focus on the planning. It includes a prototype cycle after the quick analysis and design phase in which the team releases the prototype, then gathers the feedback over it and refines it accordingly. Once it is done the testing is done and the product is deployed
Time and resources are the key factors here so you should adopt this model when you have to deliver the product in 2 – 3 months and you have sufficient resources and trained professionals in the team. It can also be used in cases where you need to produce multiple prototypes and let the stakeholder choose the best one. However, it is not recommended if the stakeholders do not have dedicated time to provide feedback or if a detailed analysis is required to ensure all functional and non-functional requirements are fulfilled.
It is a method in which the key step is to identify all the critical tasks in the project as well as their relationships with each other. It follows three basic steps: first of all identifying critical tasks, then estimating how long it will take to complete each task, and then using all the previous information to schedule the critical path. It is important to keep in mind that there may be some tasks that cannot be started until the previous one ends thus the starting and ending time of each task is allocated accordingly. The longest sequence of the critical tasks is the critical pathway which determines how long it will take to complete the project. To keep a check on the progress, different milestones are set in the critical pathway which can be monitored using Gantt charts.
It is preferred to use in cases when there are strict deadlines to be met and you need a visual representation of the sequence of tasks mostly in cases where there are a lot of dependencies amongst tasks. Moreover, it is also helpful in resource-sensitive projects where you need to identify tasks according to their priority so the resources can be allocated accordingly. However, it is not suggested in cases where your project is prone to change, and the time duration for each task is hard to estimate.
To conclude, all the project management models facilitate the development process in their respective suitable situations. Thus, it is very important to choose the appropriate model for each project after critically evaluating its requirements and shortcomings