Agile vs WaterfallAgile vs.

waterfall is an important consideration in managing projects, but without a solid foundation the
portfolio will fail to deliver the expected results regardless of how well an organization executes its projects. Here
are four keys to driving results from project governance.

You cant swing a project manager these days without hitting the debate of Agile vs. Waterfall. Both have established themselves as legitimate
project execution approaches for the modern project driven organization. However, with all of this discussion about which approach is best, we
seem to be losing sight of the fact that there are many decisions that need to be taken in the portfolio lifecycle before worrying about how to
manage the project. In this white paper we look at how an organization can create an environment where it can make smarter Agile vs. waterfall
decisions by introducing four rules that need to be followed before the Agile vs. waterfall decision is made.
For most organizations both Agile and waterfall approaches have a part to play in project execution. Agile has demonstrated that it is more than a
niche tool and has a track record of delivering business success that executives simply cannot ignore. As more and more organizations are faced
with a need to develop and / or customize software for their specific needs it follows that Agile will steadily increase its reach until it is a key part
of virtually every company and agency. At the same time it is nave to think that waterfall will be replaced as a core project execution tool. In all
but the most focused of software development companies there will be initiatives that are better suited to traditional project processes.
This leads us directly to our first rule:

Rule #1: You must create a project execution environment that supports both Agile and waterfall techniques, allowing
them to co-exist effectively and efficiently.
The implications of rule #1 are that organizations require two sets of project infrastructure one that supports the process and tool intensive
demands of waterfall, and one that can regulate the less structured Agile approach that the organization embraces while still allowing teams the
freedom that they need. This can be a hard sell to organizations that see this dual approach as driver of additional (and potentially unnecessary)
expense, but this is a situation where the investment should be easy to justify.
All of us have a number of different software tools on our computers, tablets and phones, each of them designed to perform a different, sometimes
very specific, job. We dont try and use a word processing tool to develop presentations or manage tasks, although it could handle either of those
functions, because we have better tools available to us. Thats analogous to the way that organizations should handle project execution
recognize that there are different methods available to handle different types of project and use the best tool for the job in each circumstance.
That requires a project execution environment in which Agile and waterfall can coexist, and for many organizations that results in attempts to
force both methods into a single project infrastructure with common reporting requirements, shared templates, a combined approval process, etc.
This is a short sighted attempt to minimize overhead but compromises the effectiveness of both approaches and can lead to significantly bigger
problems reporting progress on a sprint using a waterfall-based status report is unlikely to add value, but can easily mask risks and issues.
Other organizations look for a hybrid approach that seeks out best practices from waterfall and Agile and combines them into a single execution
approach that incorporates elements of both. There may be situations where this works, but it is often a case of subtraction by addition we end
up with a single approach making the infrastructure easier to manage, but end up with a project methodology that is less than ideal for the vast
majority of initiatives.
The best chances for success comes from recognizing that both methods of project execution have their merits; that both will need to evolve and
develop independently; and that both will need the environmental, infrastructural and cultural freedom to do so effectively. While ultimately the
organization needs to be able to measure performance on these initiatives regardless of the method of execution that is being used, this should not
be through arbitrary reporting and tracking measures, but should reflect the business drivers that are the reasons why the projects are being
executed. Typically this would include whether the project will deliver the expected benefits (gross and net of costs) and whether those benefits
will occur within the timeframe defined in the business case.
Unfortunately, in many cases the chances of success are jeopardized before the project ever starts because the process of conceiving and
developing the project proposal is flawed. And thats where the next rule comes in:

Rule #2: Idea generation and development must encourage collaboration from all stakeholders in building objective
business cases.
The biggest challenge that many organizations face with developing project proposals is that they see it as a once a year exercise something that
occurs over the course of a few weeks leading up to the annual planning meetings where the decisions are made on how to allocate the project
budget for the next year. Effective proposal development needs to be a year round exercise, and thats where the importance of alignment and
collaboration comes in.
Organizations dont generate ideas once a year people generate ideas all year round. However, frequently those ideas get lost simply because
there is no process for capturing them. Organizations need to create an environment where all areas of the organization understand the corporate
priorities, so that looking for ways to deliver against those priorities becomes built into the fundamental culture of employees as they undertake
their work.
Of course communication is not enough. There also needs to be an infrastructure for those ideas to be captured and developed. Yet this is rarely
handled well by organizations. Instead, the focus is frequently on getting from idea to project as quickly as possible, and often that leads to a bias
for proposals with high benefit, low cost estimates and a seemingly thorough execution plan in the form of preliminary schedules, resource
requirements, etc. Unfortunately this approach works frequently enough at the individual project level which of course is why it continues to
occur but can lead to a portfolio that consists of less-than-rigorous business cases with unrealistic expectations and execution approaches based
on personal bias rather than objective needs.
To fully comply with this rule, organizations need to create a culture of collaboration and enhancement that is fundamental to their entire
operating approach. Someone who comes up with an idea that can help the organization to achieve its objectives needs to be able to capture that
idea, share it with others, work collaboratively to develop and refine the idea, and evolve it into a full business case. If even the most junior
frontline resource doesnt feel as though they have the ability to present and own their ideas then the organization will lose opportunities to
improve and fail to deliver on its potential.
Of course that culture needs to be supported with a robust process infrastructure, and modern tools have started to make this easier. Project
Portfolio Management or PPM tools now offer powerful workflow and collaboration modules to help facilitate people working together to develop

ideas, consolidate multiple ideas into a single proposal and develop that proposal into a solid business case. The tools can also integrate with
existing processes to provide standard templates to ensure that all business cases are developed and presented in a consistent format.
However, organizations can still be successful without PPM tools. Most of these functions will be available in existing tools even if they arent as
integrated, and the provision of solid process and templates should be well established through existing project execution methodologies
regardless of the tools that are in use.
Its important to stress that the development of business cases should focus on what the proposed initiative will deliver and why that is important
to the organizations ability to achieve its objectives. The detailed how of execution, which will include the decision of Agile or waterfall execution
approaches, should only occur once the project is approved and there is a better understanding of the available resources and the needs of the
combined portfolio, budgets and timeframes.
A well-developed business case provides an extremely solid foundation for the portfolio selection and approval process, but there is still plenty of
opportunity for things to go wrong, and that leads us to our third rule:

Rule #3: Project selection and approval must be focused on enterprise needs and the achievement of overarching
corporate objectives.
Inevitably the project review and approval process is a stressful time for the decision makers. There are generally more funding requests in the
proposals than there is budget available for the portfolio, and there are a lot of decisions to make in a relatively short period of time. Additionally,
the decisions made will have a significant impact on the organizations ability to achieve its goals for the coming year, and one bad decision can
impact a lot of different areas. The process can be just as stressful on project practitioners, even if the second rule has been followed and the
organization has created a culture of developing proposals and business cases throughout the year.
Much of this stress is created by the perception that the entire process is a battle with winners and losers among the initiatives that are
competing for the limited resources. Often there is concern that projects will be approved because of the strength of will of the sponsors rather
than the strength of the numbers and logic presented in proposals. Finally, there is the concern among practitioners that unrealistic expectations
will be set that will simply not be achievable timelines that are too aggressive, budgets that are cut too severely, and assumptions over the
execution approach that simply arent feasible. There is a common belief that no matter how well thought out the business case, an initiative will
likely be adjusted to become more aggressive less funding, less time, more features, etc.
The more structured approach outlined in rule number two creates a number of project proposals as inputs to the project selection process that
can be compared objectively. If proposal development has been executed properly, then the proposals offer consistent approaches and
comparable cost benefit data, cash flow projections, etc. This alignment of business cases should allow for a significantly less stressful annual
planning cycle, as many of the unknowns have been eliminated and objective data is readily available to all involved in the process. This should
remove much of the uncertainty that drives the battle for approval.
However, decisions are not made (and should not be made) based solely on the quantitative data that is contained within those proposals. While
that data is vitally important and should provide a meaningful assessment of what the project will require in terms of resources, what risks it will
expose the organization to, and what benefits it will deliver, there are other variables in the decision making process that may override those
numbers. For example: a regulatory initiative may need to be undertaken regardless of the cost; a product may be invested in even if the return is
more long term because of its strategic importance; or an automation project may be pursued simply because of the reducing availability of the
skills required to do the work manually. All of these variables will impact the decisions over which projects to approve, but they are still logical,
business-focused drivers. The organizational leaders tasked with approving portfolio elements may need to make subjective decisions over the
strategic importance of one project over another, but the decision is still based on what is best for the organization and its ability to deliver its
objectives.
Maintaining that organizational focus will help to eliminate the championing of, and lobbying for, department specific initiatives, a problem that
frequently occurs when project selection is based simply on qualitative presentation and debate. Most importantly, the organization-first
approach should result in a portfolio that stands a much better chance of achieving what it is designed to do. Organizations should invest in a
process infrastructure to support this approach for example delaying the setting of key performance indicators (KPIs) for departments until
after the portfolio has been finalized. This will help to avoid unrealistic expectations and also eliminate some of the motivation for putting
department-focused initiatives ahead of projects benefitting the overall organization.
Organizations might also consider independent facilitation of the annual planning process, and the head of a PMO or similar role will often be a
good choice.
Finally within this rule, organizations should avoid making decisions on initiatives based on project execution constraints. What is best for the
organization should never be compromised by what is believed to be the capacity to execute, because that can be addressed if the benefit is there.
The concept of rationing the number of projects that can be undertaken using Agile or waterfall, the number of projects within a business area, or
the number of projects that can be completed with the current number of project managers is simply limiting the potential for success . If those
decisions are needed then they should come much later in the planning and execution process.
Once the projects that will ultimately make up the portfolio are approved, then the more detailed project planning work can begin. It is this
process that will ultimately result in the decision around how each project will be executed waterfall or Agile but there is still one more a rule
to be considered:

Rule #4: Every project is unique, and execution methods should never be determined based on arbitrary criteria.
The very definition of a project is that it is a unique endeavor. When deciding on something as fundamental as how to execute a project, one must
consider all of the nuances and individual elements of the initiative, not simply a set of predefined rules. Organizations that attempt to shortcut
the process by determining that Agile will be used for all software development or that Waterfall will be used for any effort greater than five
person years will simply trade quicker decision making for effective decision making.
Organizations can, and should, develop frameworks for the type of projects for which Agile or waterfall is preferred, and those frameworks should
be based on the environment that discussed under the first rule as well as experience, skills, resource numbers, etc. These frameworks will help to
generate recommendations and simplify the decision making process for more straightforward projects. But there should still be a willingness to
go counter to those guidelines when appropriate. Here again the organizational benefit should be the driving factor in the decision which
execution method maximizes the chances of success when considering all of the variables of time, cost, risk, quality, etc.
This requires PMO resources, program managers, and any other role that is involved in determining the approach to be used, to understand the
advantages and challenges with each approach as well as to have an objective view of the organizational capacity to execute on Agile and waterfall
projects. The implication of this is that there cannot be two distinct sets of specialists. At least at the PMO level there needs to be shared expertise
in what the organization can achieve. Additionally, there needs to be an understanding that this capacity is dynamic. Agile capability in particular
will change rapidly as practitioners (and the organization) gain more experience with Agile projects.

There will be occasions where arguments can be made for the execution of projects using either approach, and there shouldnt be an expectation
that there is always a right or wrong answer. If Agile is the preferred method but there are no Agile resources available for six months, then
should the project be undertaken using waterfall? The decision can be distilled down to which offers the portfolio the best chance of achieving its
goals and objectives, but the decision may well end up being a toss-up and thats OK. Whats important is that the decision is taken at the
individual project level. The actual results will contribute to the overall pool of knowledge and make the decision easier to make next time around.

Conclusions
So where do these four rules leave us? There are two distinct messages to take away from this whitepaper.
Firstly, recognize that the discussion of Agile or waterfall should be finished by now. The correct answer is both, and if your organization hasnt
recognized that and invested in an environment that supports it then you could be in trouble because your competitors probably have! This
means that organizations need to develop a culture that encourages and promotes Agile and waterfall existing in parallel cooperatively, not
competitively. Culture takes longer to create than process infrastructure, and it needs a lot more work. It also requires much more commitment
from all of employees, from the most senior to the most junior. However, it is also what will ultimately drive success.
The second message is that while Agile or waterfall is an important decision to make when it comes to how to execute a project, it isnt the most
important decision around that project. The investment of time and effort into developing the processes and infrastructure needed to produce
consistent, quality business cases and execute annual planning work that is objective and focused solely on maximizing the likelihood of achieving
the organizational goals and objectives will have a much greater impact on overall success than the execution approach that is selected.
Agile vs. waterfall is an important consideration, but without a solid foundation a portfolio will fail to deliver the expected results regardless of
how well an organization executes its projects.
This white paper was developed by ProjectsAtWork and PowerSteering Software, a cloud provider of business project & portfolio management
(PPM) software, helping organizations drive results by enabling real-time visibility, strategic alignment, optimized asset allocation, workforce
productivity, and agility in response to change across their global portfolio of projects, programs, and resources. More than 150 clients with
over 100,000 active users rely on PowerSteering to accelerate business performance in IT Management, New Product