Before undertaking a project, one of the most crucial decisions is which approach you want to take. Which project management methodology will you employ?
What are project management methodologies? The methodologies are the guiding processes and principles involved in how you manage a project. They determine how project tasks are acted on and organised.
The methodology you choose will set out how you communicate and work through the project - and there are two major methodologies to consider: agile and waterfall. The primary difference between agile and waterfall is how they're completed. Waterfall projects are done sequentially while agile projects are done iteratively in a cycle.
JCurve Solutions (ASX: JCS) delivers cloud technology solutions and runs implementation projects based on agile and waterfall frameworks. The team at JCS has found that a combination of agile and waterfall project methodologies the can bring significant benefits in this scenario.
I'm Alena Suvorava, JCS Project Manager, and I'll explain further with an in-depth look at agile and waterfall, and why JCS chose a blend of methodologies.
Waterfall is a model; a breakdown of activities in sequential stages where each phase follows the other. Usually, the second phase does not start until the first phase is completed.
This approach is usually used in engineering design. As far as software is concerned, it is not as intuitive or flexible in comparison to agile methodology. In terms of progress, it flows in one direction. This notion appeared in software development in 1956 during presenting programming methods for digital computer presentation.
In waterfall, one stage follows the other one and its very strict. During pre-sales, JCS reps work hard to walk through the requirements. At the end of the pre-sales phase, they produce a SOW (Statement of Works) which uses fixed scope. On the positive side, it's fixed scope and it's good for the client. There are fixed dates; a start date and an end date. It's very clear to the customer.
After the SOW is signed off then we start planning, usually it takes into account the kick-off meeting, we talk about resource allocation and time planning. We will then start with a business analysis.
After the business analysis, we will walk through delivery and scope to make sure it is clear on paper and get sign off, ready to start implementing and building. After we set-up, build and configure, we then proceed to the UAT (User Acceptance Testing). After the UAT phase, we then deliver to the client.
On the positive side, waterfall is fixed scope. The start date is clear and the progress is well defined because the customer understands exactly what they get at the end of the project. With the exception of reviews, feedback, and status meetings with the client, the client is not participating a lot in this type of approach. The involvement from the client is minimal in this methodology.
On the negative side, as the customer is not as heavily involved in the implementation, it's possible to see situations where the customer's expectations are not in-line with what's been produced. This can result in additional work, cost, and delays. Another drawback is that the customer needs to understand what they get at the end of the implementation. Sometimes during pre-sales, asking too many questions or going into too much detail can delay the project sign off. Also, sometimes we don’t want to overwhelm the customer with a lot of details, that’s why we try to push it to a later stage.
Waterfall is a very predictive methodology, one step, one stage follows the other. It's very well defined and we know what we are getting. Agile on the other hand is very reactive.
The agile methodology is very flexible, it’s very iterative, it’s team-based approach and it focuses on rapid delivery. The customer during a time-slotted period can get features that end users can benefit from. On the one hand, it's planned within sprints or iterations. At the end of every sprint we review and re-prioritise the tasks. The focus is on the value of the product rather than the process.
On the positive side of agile, it runs in constant cooperation with the customer. The customer is involved in implementation and project delivery. They make decisions, they can give feedback, and we can avoid significant changes at the end of the process because they've been involved all the way through.
On the negative side, this approach does require a high amount of customer’s attention. Customers can be busy with their day to day operations and their attention to the project can vary - sometimes resulting in delays with the final implementation delivery.
Agile works very well for team-based and dedicated team projects, where one team has one project. As an agile time-framed project, sometimes during the sprint the backlog will identify that the sprint cannot be delivered. During a sprint review, we may need to push back on features, re-think the approach, or push back to second or third sprints. This can increase the overall time and cost of the implementation. The other potential downside is that agile projects work better for teams that work in the same physical space rather than dispersed spaces. This is an important consideration for JCS being a cloud solution provider and often working with clients remotely via video conferencing and other cloud applications.
Agile has different methodologies, it's lean. One is SCRUM; this is a methodology that was formed from a rugby word that means teamwork. Teamwork is a common goal to achieve something which is to win. It is generally used for software development, it’s pretty modern and this notion appeared at the beginning of 2000. The idea of SCRUM is that features are delivered within sprints. For us, a sprint generally covers 2 weeks to a month. The SCRUM teams are usually no more than 10 people. Within SCRUM activities, there are planning, daily stand-ups, sprint reviews and retrospective that we actually blend in our implementations.
Kanban methodology is a lean methodology that was borrowed by the Toyota production system. The main idea of Kanban is to eliminate waste and to optimise the processes. The main principles of Kanban are having workflows, and the board where tasks are distributed. Team members visualise how many tasks they have, and they need to spread out their work evenly. They need to decide, depending on the number of tasks, whether they need to speed up or take a slower pace.
JCS uses a Kanban board during the UAT phase. We provide our customers with UAT scenarios, and the customer comes back with feedback or changes that they want to implement. We have a backlog with a list of tasks that are to be done. There are times when clients want changes and desired features added to the scope even after system testing. They may have originally been out of scope but are now added to the scope of requirements for project go-live. Using the Kanban approach, visualisation of such tasks and changes can bring clarity to these situations.
For this methodology, it is not recommended to have more than 2 tasks per team member - so they can stay focused on the tasks at-hand without other distractions.
Can agile and waterfall methodologies work together?
The answer here is that collaboration is a success factor and JCS uses a hybrid approach. This approach helps us to be more efficient and adaptive instead of only relying on the traditional waterfall delivery framework. We stick to fixed deadlines making sure that our projects are delivered in a timely manner.
On the agile perspective, we try to collaborate with customers more often. For example, we run personalised sessions for our NetSuite SuiteSuccess methodology during which we try to understand the set-up of the customer, discuss it with them in detail, remotely we set up the system for them, and then do a final walkthrough. During the walkthrough, we ask the customer again to provide feedback and then we tweak things according to the customer's needs.
During the third round of UAT, the customer does their own review. This allows them to take a hands-on approach, provide feedback, and flag additional changes. This helps us to implement changes much more easily and tweak aspects of the implementation instead of waiting until after the project has gone live.
We also use workshops at the beginning of traditional NetSuite implementations. We send a business requirements document to the customer and give them time to go through it in detail. The customer confirms their understanding before proceeding. We then create a blueprint that we present to the customer, making sure that we have the same understanding and visualise what needs to be done.
We have also introduced a stand-up that happens 3 times a week, along with a retrospective that I will cover in more detail. Those are SCRUM events that we borrowed in our methodology.
We have a 10-15 min meeting 3 times a week where every team member talks through what they did yesterday, what they are planning to do today, and any impediments to note. This meeting allows us to confirm that we are on track, there are no delays, and no one is stuck.
Another SCRUM event that we borrowed, we call "external retrospective". It is similar to a sprint review or internal retrospective. This is a meeting with a project team and the client which is held at go-live time. The purpose of this meeting is to get feedback from the customer and actually demonstrate what has been done so far.
Questions in focus:
- What has been done
- What has not been done?
- What work has been added?
- What work has been removed from the project?
These are 4 questions that we talk about in the meeting. The team presents and demonstrates the modules that we have configured so far, and things that still outstanding. We also talk about additional customisations or additional features from which the customer can benefit.
Anything the customer does not want to include is also discussed in this meeting. This is a quick way to confirm what's in or out of scope. It generally takes 20 mins to talk to the customer and walk through the questions.
Another event is internal retrospective. This event is an internal one, and it’s essentially a process improvement meeting. Usually this meeting is held after the closure of the project or just before the closure. It is obligatory that all members of the team participate during this meeting and they provide their feedback.
Internal retrospective questions can include:
- Things that worked well need to continue being done
- Things that didn't work well and that we would not do again
- Things that need overall improvement
This meeting does not involve the customer. It provides our internal team reflection of our delivery and how we can improve our next implementations. It's very key that every team member of the project participates actively and shares their vision and feedback.
Agile and waterfall working together
As you can see, agile and waterfall project management methodologies both have their pros and cons. Different companies will have different ways of working - and may gain more benefits from one over the other. In my experience as a Project Manager for cloud solutions provider, JCurve Solutions, it has made more sense to use a blend of methodologies to leverage the benefits of both.
Are you interested to learn why process improvement is the profitability dark horse? Get your free business guide now: