AgiWater

Abstract

For the six decades following World War II, the sequential approach on how to divide a project into phases was the predominant approach to project life cycles. This approach, also known as waterfall or plan driven, was found in projects where the triple constraint (quality, scope, time and cost) required delivering the product and project scope, were determined very early in the project life cycle.

In reality, most projects are technically, organizationally and socially complex adaptive, having to materialize within a complex environment. The number and nature of human, organizational and technical elements effecting the project, both between the project and its environment as well as within the project itself, the degree of uncertainty about the project's goals and the way to reach them, parallel and interrelated supply chains, shifting and variable stakeholder interests, all add toward impossibly prognosed and complete project initiation and planning phases.

In the last twenty years, a new approach to project delivery was introduced: The adaptive life cycle, which is also known as change-driven approach or agile methods. This agile approach seems to be in contrast to the traditional project management approach. What are the differences and the similarities? How can A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) and ISO 21500 support agile and Waterfall? Can we mix the waterfall approach with the agile approach? Is agile a blessing or a curse compared to traditional project management?

Introduction and Background

Worldwide, 20% of the gross global product, US$12 trillion per year, is spent on fixed capital projects (McKinsey & Company, 2008). Trillions more are spend in projects for healthcare, IT, new product and service development, entertainment/IP, NGOs. If someone tries a Google search on the word ‘project,’ the results are amazing:

• 21 November 2009:          686 million results
• 10 March 2013:   2.7 billion results

So, every year, more and more projects are initiated. Still, the majority of these projects are at risk mainly because of bad project management practices. Project management is mainly about people, people working together in synchrony in order to achieve the project's objectives. A philosophy called 5M, which comes from the lean world of manufacturing, harmonizes or helps the 5Ms together for the best possible outcome in any manufacturing operation. These 5 Ms are:

• Money
• Men
• Machines
• Materials and
• Methods

In the world of change (projects), the fifth M is called “project management” and is the essential part to putting all the other Ms together and making them a cohesive, efficient, and effective whole. It is well known that the first ever decision we make in every project is how to divide the project into phases. It's like deciding if you are going to buy a small car or a truck. This decision on project approach is the most crucial decision we can take on a project. Should we follow the traditional project management approach (waterfall or plan driven); or, should we use the agile approach (iterative or change-complexity driven)? Furthermore, the full potential of the project team is enabled when its members share their knowledge, skills and cognition and collaborate, supplementing each other. When information (how to do it and/or what the goal is) is chaotic and scattered the project team may become disillusioned and fragmented. An agile approach running in parallel to the standard approach most of the times eliminates this phenomenon.

According to the PMBOK^® Guide — Fifth Edition, (PMI, 2013), there are two basic types of phase-to-phase relationships in any project: Sequential relationships and Overlapping relationships.

Also the PMBOK^® Guide — Fifth Edition, (PMI, 2013), distinguishes between the following life cycles: (1) Predictive life cycles, (2) Iterative and Incremental life cycles and (3) Adaptive life cycles

In 2001, Agile Manifesto for Agile Software Development was published (Agile Manifesto, 2001) with the following values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Actually, Agile Manifesto, at first glance, seems to be contrary to the classic plan driver project management approach. But is this the case?

Finally, in September 2012, ISO published ISO 21500:2012, Guidance on Project Management. ISO 21500 provides guidance for project management and can be used by any type of organization, including public, private or community organizations, and for any type of project, irrespective of complexity, size or duration. ISO 21500:2012 doesn't make any specific notes on the project phases.

PMBOK^® Guide — Fifth Edition

The PMBOK^® Guide — Fifth Edition, (PMI, 2013), is a process based ANSI standard with good practices that can be used in most projects, most of the times and in most of industries. The main characteristics of the PMBOK^® Guide are:

PMBOK^® Guide Approach to Project Life Cycle

In the latest edition the PMBOK^® Guide — Fifth Edition (PMI, 2013), two basic types of phase-to-phase relationships in any project are described:

• Sequential relationship: In this approach, the next phase starts only when the previous phase is 100% complete. In this approach, overlapping is not taking place and it also eliminates most options available for reducing the overall schedule
• Overlapping relationship: In this approach, the next phase starts prior to completion of the previous phase (the two phases are run in parallel for some time). This approach is also called fast tracking and it is usually used as a schedule compression technique. In this approach, the overlapping nature of relationships increases the project risk

Also the PMBOK^® Guide — Fifth Edition (PMI, 2013), distinguishes between the following life cycles:

1. Predictive Life Cycles (or Plan-Driven Life Cycles)

These life cycles are usually found in projects, where the triple constraint (quality, scope, time and cost), which is required to deliver the product and project scope, are determined very early in the project life cycle. As shown in Exhibit (PMI, 2013), these projects proceed through a series of sequential or overlapping phases, with each phase generally focusing on a subset of project activities and project management processes in order to complete the phase.

When such a project is approved and initiated, the project management team will focus on eliciting requirements for the whole product and project scope very early in the project life cycle. Also, they will create the project management plan for delivering the product and any associated deliverables. Any changes to the approved scope are managed through the change control process and if the change is approved, the project is re-planned and re-baselined. Of course, rolling-wave planning can be used in this approach, where a more general, high-level plan is developed for the whole project and more detailed planning done as new work activities are approaching.

Exhibit 1 – Predictive Life Cycle Example

2. Iterative and Incremental Life Cycles

These life cycles repeat project activities as the understanding of the project and product scope increases. Project phases are also called iterations that deliver the product iteratively and incrementally. Iterative and incremental life cycles are usually preferred in order to:

• Reduce complexity
• Manage changing objectives
• Manage changing scope
• Reduce risk
• Increase value for partial product delivery
• Incorporate lessons learned from previous phases

3. Adaptive Life Cycles

These life cycles are usually iterative and incremental and are referred to as agile or change driven. The mail concept of the adaptive life cycles is to embrace change even late in the project life cycle with continuous stakeholder involvement. The only difference with the previous life cycles is the very rapid iterations, which last from one week to a maximum of four weeks with a fixed number of human resources. Actually all iterations are time boxed with fixed duration (time) and cost for each iteration

The most known adaptive life cycle approach is Scrum. In adaptive life cycles the overall scope in decomposed into prioritized requirements. Many refer to these requirements as product backlog. From this product backlog, the team selects which requirements (based on priority) to include in the next iteration, taking also into account the team velocity. Adaptive life cycles demand that the team, stakeholders and product owner cooperate closely even on a daily basis. Furthermore, in complex environments, attempts to plan and control the system as a whole by controlling a few variables usually lead to unanticipated results. Control must be decentralized and exercised in small loops, adapting to system feedback effects for every next loop. Awareness that small changes may produce significant changes in the final results are of paramount importance and the project manager must proactively manage these during every loop.

Agile methods are generally preferred in:

• new product development
• unknown requirements and scope
• small incremental deliveries give business value to stakeholders
• rapidly changing environment
• stakeholders need to “feel and touch” the product as soon as possible

Agile Techniques

In the marketplace someone can find dozens of agile approaches, like: Microsoft Solutions Framework (MSF), Rational Unified Process (RUP), Scrum, Dynamic Systems Development Method (DSDM), Crystal Clear, Extreme Programming (XP), Adaptive Software Development, and Feature Driven Development (FDD). When someone refers to agile, he or she usually means one of the above approaches.

Agile Manifesto

A catalyst on the agile approaches was the publishing of the Agile Manifesto. On 11–13 February 2001, at The Lodge at Snowbird ski resort in the Wasatch Mountains of Utah, USA, 17 independent-minded practitioners met to talk, ski, relax and try to find common ground. What emerged from this gathering were the Agile Software Development Alliance and Agile Manifesto.

The participants didn't agree about much, but they found consensus around the following four main values; actually they noted that, although there is value in the items on the right, we value the items on the left more:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Twelve (12) Agile Manifesto Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Manifesto Approach to Project Life Cycle

Actually, the Agile Manifesto and many other agile approaches note nothing special about project management and how to divide the project into phases because its approach was based on embracing change and keeping the customer satisfied through early delivery.

Almost all agile techniques use rolling wave planning for the project implementation. Rolling wave planning is a form of progressive elaboration planning where the work to be accomplished in the near term is planned very well in detail, whereas the work to be done in the future is planned at a more general level. Agile techniques use very rapid iterations, which last from one week to maximum four weeks with a fixed number of human resources.

These iterations in Scrum are called Sprints, with Scrum describing the following ceremonies (Exhibit 2):

• Sprint Planning: the team meets with the product owner to choose a set of work to deliver during a sprint
• Daily Scrum Meeting: the team meets every day to share issues and progress
• Scrum of Scrums meeting: what the team has done since we last met
• Sprint Review meeting: the team demonstrates to the product owner what it has completed during the sprint
• Sprint Retrospective meeting: the team looks for ways to improve the product and the process

Exhibit 2 – The Scrum Process (Scrum, 2013)

Also, Scrum describes the following roles:

• Product Owner_is the voice of the customer and is responsible for the scope to be delivered during every iteration in order to deliver business value.
• ScrumMaster carries “food and water” to the team and removes any obstacles that prevent the team delivering the scope of the sprint.
• Team is responsible for delivering the scope of the product in many small sprints.

Actually, in sprint planning, which usually lasts less than 4 hours, we use the “plan driven approach” to plan the sprint because we know all the scope (features and/or characteristics) to be delivered during the sprint. This means that the agile project team utilizes critical path method (CPM) scheduling for each iteration (or sprint). This carries on until all product scope, according to product owner, is delivered. So, agile approaches coexist with waterfall approaches in the agile world, creating an AgiWater environment.

ISO 21500:2012

ISO 21500:2012 is a process based ISO standard that was developed from 2007 until 2012 and, as ISO 21500:2012 (ISO, 2012) states: “This International Standard provides guidance for project management and may be used by any type of organization, including public, private or community organizations; and for any type of project, irrespective of complexity, size, or duration.”

ISO 21500:2012 (ISO, 2012) provides high-level descriptions of concepts and processes that are considered to form good practice in project management. Projects are placed in the context of programs and project portfolios; however, ISO 21500:2012 does not provide detailed guidance on the management of programs and project portfolios. Topics pertaining to general management are addressed only within the context of project management.

The main characteristics of ISO 21500:2012 are:

• 10 Subject Groups (the PMBOK^® Guide's Knowledge Areas)
  • Integration
  • Scope
  • Time
  • Cost
  • Quality
  • Resource
  • Communications
  • Risk
  • Procurement
  • Stakeholder
• 5 Process Groups (the PMBOK^® Guide's Project Management Process Groups)
  • Initiating
  • Planning
  • Implementing
  • Controlling and
  • Closing
• 39 Processes with each one having Inputs, Tools and Techniques and Outputs (ITTOs)

ISO 21500:2012 Approach to Project Life Cycle

Actually ISO 21500:2012 (ISO, 2012) states: “Projects are usually organized into phases that are determined by governance and control needs. These phases should follow a logical sequence, with a start and an end, and use resources to provide deliverables.” Also ISO 21500:2012 (ISO, 2012) states that “project life cycle is defined set of phases from the start to the end of the project”

So, ISO 21500:2012 doesn't make any specific note about project phases. This means that the project team can decide how the project will be delivered using any one of the following life cycles:

• Predictive life cycles
• Iterative and incremental life cycles
• Adaptive life cycles

Comparing the PMBOK^® Guide — Fifth Edition with ISO 21500:2012

If we make a comparison between these two “process based standards,” we will come up with the following simple comparison table (Exhibit 3):

Exhibit 3 – Comparing the PMBOK^® Guide — Fifth Edition with ISO 21500: 2012

Comparing the PMBOK^® Guide — Fifth Edition with Agile Manifesto Principle

All twelve principles mentioned in the Agile Manifesto, are not at all in contrary with the PMBOK^® Guide. The following table (Exhibit 4) provides a basic comparison between the 12 Agile Manifesto principles and Knowledge Areas in the PMBOK^® Guide (numbers are the corresponding chapters in the PMBOK^® Guide).

Exhibit 4 – Comparing the PMBOK^® Guide — Fifth Edition with Agile Manifesto Principle

AgiWater environments

AgiWater environments in project management are environments where both plan-driven approaches and change driver approaches coexist.

So there are no black and white solutions. The project team must select the appropriate project approach in order to mainly deliver the business value needed by the customer.

Conclusion

For many decades, the main approach to dividing a project into phases was the sequential approach (also known as waterfall or plan driven). But lately, the agile approach to project delivery has been introduced (also known as adaptive life cycle or change-driven). This agile approach in not in contrast to the traditional project management approach because the two different approaches can coexist in the same project. Finally, we believe that under this combined approach every project must be run as a “new business” with a project manager having full support of the organization's senior management. Senior management must view the project managers not just as organizers but the “project's managing directors.” On the other hand, project managers must be trained to combine business vision, communication skills, and at least some technical savvy in order to be able to continuously plan, coordinate, and execute stepwise; they must not only manage but also lead. The use of agile techniques within a complex project environment places a higher premium on leadership than ever before.