Which project methodology is best?

Or is this the right question?

Maybe the question should be: what problems do the various project methodologies best resolve?

Much of the discussion on project management today focuses on project life cycles – especially the various RADs, or rapid application deployment. Being a software development methodology, RADs involve methods like interactive development and software prototyping. This has resulted in RADs being a merger of various structured techniques, especially data-driven Information Engineering, with prototyping techniques to accelerate software systems development.

In RAD, definition of users’ requirements and the design of the final system are especially focused upon by structured and prototyping techniques. Developing preliminary data models and business process models using structured techniques mark the development process. Next, requirements are then verified using prototyping, eventually to assist in refining the data and process models. These stages are repeated iteratively; further development results in a combined business requirements and technical design statement to be used for constructing new systems.

Here is a simplistic summary of the pros and cons of the various RAD’s

Agile software development (Agile)
Pros
Minimizes feature creep by developing in short intervals resulting in miniature software projects and releasing the product in mini-increments.
Cons
Short iteration may add too little functionality, leading to significant delays in final iterations. Since Agile emphasizes real-time communication (preferably face-to-face), using it is problematic for large multi-team distributed system development. Agile methods produce very little written documentation and require a significant amount of post-project documentation.

Extreme Programming (XP)
Pros
Lowers the cost of changes through quick spirals of new requirements. Most design activity occurs incrementally and on the fly.
Cons
Programmers must work in pairs, which is difficult for some people. No up-front “detailed design” occurs, which can result in more redesign effort in the long term. The business champion attached to the project full time can potentially become a single point of failure for the project and a major source of stress for a team.

Joint application design (JAD)
Pros
Captures the voice of the customer by involving them in the design and development of the application through a series of collaborative workshops called JAD sessions.
Cons
The client may create an unrealistic product vision and request extensive gold-plating, leading a team to over- or under-develop functionality.

Lean software development (LD)
Pros
Creates minimalist solutions (i.e., needs determine technology) and delivers less functionality earlier; per the policy that 80% today is better than 100% tomorrow.
Cons
Product may lose its competitive edge because of insufficient core functionality and may exhibit poor overall quality.

Rapid application development (RAD)
Pros
Promotes strong collaborative atmosphere and dynamic gathering of requirements. Business owner actively participates in prototyping, writing test cases and performing unit testing.
Cons
Dependence on strong cohesive teams and individual commitment to the project. Decision making relies on the feature functionality team and a communal decision-making process with lesser degree of centralized PM and engineering authority.

Scrum
Pros
Improved productivity in teams previously paralyzed by heavy “process”, ability to prioritize work, use of backlog for completing items in a series of short iterations or sprints, daily measured progress and communications.
Cons
Reliance on facilitation by a master who may lack the political skills to remove impediments and deliver the sprint goal. Due to relying on self-organizing teams and rejecting traditional centralized “process control”, internal power struggles can paralyze a team.

For good or bad, RAD approaches may entail compromises in functionality and performance in exchange for enabling faster development and facilitating application maintenance.

Citing the Project Management Book of Knowledge, there is no single best way to define an ideal project life cycle. PMBOK notes that the project manager, in collaboration with the project team, is always responsible for determining (1) what processes are appropriate, and (2) the appropriate degree of rigor for each process, for any given project. It is well known by the experienced Project Manager that best practices of any project life cycle methodology can be used within the overall PMBOK framework of project management processes. Basically, this means all the PMBOK processes can be performed using an agile project life cycle or a waterfall project life cycle.

I presume everyone has knowledge, and agrees, that every project has a constraint triangle – functionality (whether it be system or software), budget, time. Usually thought of as the more ‘contemporary’ of the project management styles, the agile project life cycle– theoretically – focuses on delivering high value functionality, quickly and often, while keeping the budget and schedule of iterations fixed. In contrast the waterfall life cycle focuses on features first (that is, the project scope), where they are defined in detail driving the ability to create schedule & cost estimates. Waterfall approaches works hard to prevent changes in scope, whereas agile expects and embrace scope change and focus on delivering business value quickly instead. This is contrasted against the agile strategy which is to fix schedule & cost constraints and then work to implement the highest value features as defined by the customer, so that scope remains flexible. Basically, they are two different methods that supposedly provide a delivered product in the best way possible. So why the fuss about Agile versus Waterfall project management? And why so many times a defensive posture is taken on the preferred project life cycle?

Compared to the Waterfall project life cycle, Agile has simply flipped the triple constraint triangle…and the focus is on delivering high business value quickly. Anytime anything is done quickly, expediency is given precedence and priority. The standard practices of scope definition, work breakdown structure (WBS) creation, and scope verification occur interactively in agile. During agile release planning, the features are defined at a very high level and placed into iterations in priority order. At this point the agile WBS only has deliverables, not work packages. These features, or deliverables, can be estimated at a gross level only. Once the iteration begins, the features slated for that iteration – and only that iteration – are elaborated. Some like to think of it as just-in-time elaboration that prevents a wasteful buildup of requirements inventory that may never be processed.

Many times, when a Waterfall project life cycle is short or burdened with a requirement inventory then it is not the fault of the life cycle but in the management style and lack of preparation. Basically, the initial approaches have not been performed correctly. This is usually a failure to interview the end users that will be ultimately responsible for the use of the system as well as the reporting needed from the system.

From my own experience, no matter how an ideal project life cycle is defined any time expediency trumps propriety, there is an escalating downwards slide which eventually is impossible to stop until the project crashes from excessive momentum and lack of direction. This is true for BOTH Agile and for Waterfall project management. So the defensive posture for either project life cycle, again from my own experience, is more personal than objective. Business, in the end, is very objective –the service of the business on the other hand should be personalized.

On these topics, I refer you to the articles already published in TIEspecialistas Brasil…
• BEFORE searching for your HRIS system
• Systematic & Efficient Planning for Your SIRH Project
• Performing a Needs Assessment on Project Management
• Looking at Project Management From Outside the Box
• Why Are Implementation Costs Higher Than Initial Estimates?

Is there a right or wrong way to do things? As with resolving any problem, the methodology you use must be driven by the problem you are trying to solve. If the end state is well known & requirements are clearly defined and documented, then waterfall works well. However, if the end state is unknown or changing rapidly, then agile works well. Many project managers have found that generally the Agile Methodology works best for custom software development projects while the implementation or upgrade of enterprise systems the Waterfall Methodology works best.

When comparing waterfall to agile, you really need to look at things differently. However, the core PMBOK based project management best practices you have worked so hard to perfect are still very much relevant and necessary — even on an agile project.

With special thanks to…

Steve McConnell : Rapid Development: Taming Wild Software Schedules, Microsoft Press Books (1996) ISBN 978-1556159008

Dale Olson Consulting, led by Dale Olson, PMP, an experienced project manager in Business and Information Technology.

Wikipedia.org