Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Information Technology, Work Breakdown Structures (WBS)
How do you determine if an Agile, Waterfall or hybrid approach is best for your project?
A chief of IT services shared her thoughts on determining project delivery approaches, managing stakeholders and more in this PM Network interview: https://www.projectmanagement.com/articles...k--Call-of-Duty
Sort By:
Page: 1 2 3 4 <prev | next>
Jul 28, 2019 1:37 PM
Replying to Jerry Yonga
...
Avoiding the PM -speak is best approach and deliver based on the objectives of the projects. My experience has been that the business community is not interested in any methodology.
An experienced project manager will use acquired expertise to deliver the "project" regardless of the methodology. Have we ever asked McDonald which method they use to harvest their potatoes? But I can assure you the french fries are the best. Focus on the objectives of the project and use your knowledge to intelligently deliver the project.
Jerry, I don´t think I follow your example here. Methodology is not on place to create the best outputs from the project, but to deliver. The same way as PM is involved into the project - to have a certain level of probability of successful delivery with the quiality requested.
If you target to use a methodology in a purpose to have the best possible output in a way of competition, then I would like to read some of your experience with it.
Jul 25, 2019 10:49 PM
Replying to Aaron Smith
...
In the interview linked above, Katie Sierzego says, "It’s about using the right tool for the right job. I use waterfall processes when outcomes are predictable and uncertainties are at a minimum, like with server deployments or data center builds or expansions. I leverage agile for software development and building out capabilities incrementally—projects where I focus on tight feedback loops and where the enduser representatives are available and interested in being deeply involved in the product’s evolution. And sometimes we use a combination of both, like if we develop a base product using waterfall but then customize it using agile.

It’s imperative that our project delivery teams have a breadth of understanding of project delivery approaches so they can apply each one, or a hybrid of them, as appropriate.
Do you have an experience with the example at the end of your comment?
"And sometimes we use a combination of both, like if we develop a base product using waterfall but then customize it using agile."

As we know some cons and pros of agile approach, then we should be aware to use agile along with the delivery contract, where deadline is specified.
Usually when we see a deadline on the contract, its means a big NO to involve an agile tooling. But ... To stay solid,add a value and stay competitive there is always a place for some custom features developed for the customer. So we put it inside the scope to get a contract in a purpose to develop it in time.

Could somebody share some experience with the waterfall project which include development (developed feature is in the scope)? As we well know, development always take some risks with the time and delivery estimation. In that case it could affect contract delivery term hardly. Could somebody describe this kind of hybrid approach? How do you react if development ruining your waterfall project plan?
Specially in Europe, customers are not so open to do an IT solution delivery project with indistinct delivery term (not specified in contract).
Jul 28, 2019 11:13 PM
Replying to George Freeman
...
Agile and Hybrid were whitewater rafting one day (on a bonding excursion) when they noticed a sign stating “Danger: Waterfall Ahead.” Agile, recognizing a teachable moment, told Hybrid that the rigid structure of the upcoming Waterfall posed an extreme danger to the general public, but that they had full indemnification from injury due to their flexibility.

Hybrid, recognizing Agile’s emotionally driven statement, expressed the risk-outcome this opinion would have on their immediate wellbeing. Undeterred, Agile (still in the teachable moment) insisted that they accept this risk and move forward, while Hybrid - hearing a rumbling in the distance, recommended an immediate strategy of avoidance.

How does this story end? ;)

Agile purists (as a whole) view waterfall approaches as the epitome of project evil and immediately take the contra view on a given subject if they sense anything that gives validity to a waterfall (e.g., a sign stating - waterfall ahead) – oh, now I get it.

-------------------------------------------------------------------------------------------------------

The views stated in this thread are excellent (some of which are - excuse the paraphrasing):

- Agile is a mindset, behavior and/or a way of thinking (Kiron and Sergio)
- Agile can be used on any type of life-cycle (Sergio)
- Waterfall projects can benefit from Lean, Agile, and Scrum practices (Eric).
- It’s about using the right tool for the right job (Katie, Dora, Anton, Andrew)
- If you don’t use the word Agile, your approach is considered less than optimal (although Sergio used more descriptive terms).
- I recommend you avoid words like; waterfall, agile or hybrid (Wade, Jose)
- Change the game a little, call it “Your Process Framework.” (Muhammad)
- Ultimately, the best fit for the project may not be the best fit for the project manager (Daire).
- Agile is the norm is small organizations but doesn’t necessarily scale well for the enterprise – speaking to the metrics (Stelian).
- An experienced project manager will use acquired expertise to deliver the "project" regardless of the methodology (Jerry)
- All projects use a Hybrid approach (Jose)


To Aaron’s question: I believe (along with many on this thread) that there is NO pure Agile or Waterfall project. Instead, projects are by nature Hybrid (being a generic term) as that is our mandate as a project manager - to pull together that which is necessary from a process and practice perspective to meet the specific needs of our project/product.

Thank you Aaron for a great question!
Great summary of the discussion George.
I love the lesson learned: take risks early on. We should take that to heart in our projects.
Looks like most commentators agree its about choosing the right approach for each project. One thing I've noticed in recent years is a growing awareness in the industry that the various methodologies, approaches and tools are just that - things we can use to make sense of a project. I've found, as my experience grows, I make judgement calls as I go about which to use. My bottom line is doing the least I need to do to run a project safely as most people around me aren't project trained so find the process and jargon a barrier. I tend to plan in stages and apply an appropriate approach for each stage - whether 'waterfalled' or 'iterative' or a bit of both.
I've also noticed PMI's recent work in the soft-skills space and I've found that no matter what tools, plans, documents etc I use, its all about the people and relationships. I've worked with thorough project managers who struggle to relate well with others, and so depsite having a well-planned project they have problems delivering.
...
1 reply by Sophia X. Guo
Jan 30, 2020 11:40 PM
Sophia X. Guo
...
Hi Chris:)
Very glad to see your comments here and it really helps and makes me much more confident on the job hunting for an ICT PM in New Zealand.

Cheers,
Sophia Guo
I've been in charge of IT areas, national level system administration, development and support for public/government agency... I can share that the methodology depends on a few factors, which are: Time, budget, political relevancy.

Time is always the main factor because there are sometime projects that have to be done for yesterday and you were notified 5 minutes ago, there is no personnel to spare and there needs to be a result ASAP. In this case you can only do a basic WBS (with emphasis on deliveries) and sort of follow it as your project plan, then at the end document retrospectively and start a project to tune up the result. (Horrible but all too common), so you can adapt agile... or even shorten it.

Budget is a headache for many projects, and sometimes you need to deliver a result with only 2 bus tickets and 1 shoestring. int his case waterfall works a bit better if you also pass on the allocation of the shoestring.

And the bane of government projects: Political relevance. This is probably topic for controversy, but teams in many countries, specially those working for governments know this projects are ordered, are prone to change, and are of course urgent. For this, considering SDLC as base works well, scrum in particular is often used just to ensure the new random changes are implemented.
Has anyone tried to use SAFe framework and I'd love to know your experience? Thank you
Simple or simplistic answer:
If the scope/requirements are stable and periodic demos/reviews with the end users/customers are not needed, then Waterfall would do nicely.
If the scope/requirements are fluid and expected to change frequently during the project, and/or the project has a high level of risk (technical or otherwise), then agile or hybrid could be a better approach.
Of course, the delivery framework will depend on the organization's/team's capacity/capability to properly execute with agility.
Although I advocate for the right tool for the right job approach, it does pose a challenge when reporting from different forms of datasets and interpreting the information at the executive level. This approach can work in mature organizations that have figured out how to execute efficiently using the most appropriate tools and enable standardized visibility into performance of projects and portfolios.
Fantastic and a very inspirational leader, many congratulations to the CTO! In the future it would be really great to have a more in-depth podcast perhaps that highlights in details the challenges the CTO, thanks for sharing this thread Aaron!
Page: 1 2 3 4 <prev | next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"A mind once stretched by a new idea never regains its original dimensions."

- Anonymous