Please login or join to subscribe to this thread
There are a few methods to put you on the right path. The most common one is to use two measures - Focus and Certainty.
Focus: Process vs. People. If your project leans more towards process focus your approach will be more traditional and if it is more people focus it would lean more towards Agile
Certainty: If your project is deliverable is either fully defined or easily defined your approach would lean towards a traditional approach but if it is totally undefined or very hard to define then you would go towards an Agile approach.
You land in hybrid territory when these measures meet somewhere in the middle.
My personal view is that there is no hard rule on this and I normally use it only as a guideline, using historic knowledge (i.e. appetite for change) and outcomes as other measures to choose the right approach
Choosing the approach depends on many things:
1) Industry and Type of Project
2) Degree of Uncertainty
3) Degree of Complexity
4) Degree of Clarity about Scope
5) Organizational Strategy and Goals
In construction for example, we normally use a Waterfall - Adaptive Hybrid Approach.
The approach must be selected before the project exists and the business analyst is accountable for that. You will find the way to do that inside the BABOK (IIBA organization) or PMI´s Business Analysis guides (there are two). The knowledge are name is "needs assessment" or "strategy analysis" depending on you take one or the other. No matter that, PMI and the IIBA (between others) have published and article I wrote time along in their sections called "best practices" in related publications. But I prefer, if you are interested, you go to the guides. The basement is to understand you are creating a solution then you have to take into account the product/service/result characteristics plus the environment with basement on organizations are open and adaptable systems.
It's a good practice for organizations to have project profiling questionnaires, flowcharts or checklists to help teams decide on the appropriate life cycle for a project given its context.
DA provides a simple starting point with their lifecycle flowchart but as with all else, it needs to be tailored to fit a specific organization's needs.
There is a one-word answer to this question: experience. But, as that's somewhat flippant, I’d suggest that there are many considerations to assess and apply: size, complexity, degree of localization vs globalization, the nature of the project and its outcomes and deliverables, industry good practice - these are just a few of the dynamics to consider. It’s worth considering that you may not build space rockets using AGILE, but you can design software with it. What is certain, though, is that achieving the results of a project is more important than the process of achieving them – so choose the method which best enables benefits realization.
Could you share, if you know any, some useful questionnaire/checklists that could help in let's say a brainstorming session in order to identify the best approach to follow when starting on a project?
In the Agile Practice Guide there is an "Agile Suitability Filter" in Appendix X3. The primary DA reference Choose Your WoW also contains the flowchart I'd referenced on page 101.
Very good guidance - thank you for the insight everyone!
Please login or join to reply