THOUGHT LEADERSHIP WHITE PAPER In partnership with Agile or Waterfall? 4 Keys to Driving Results from Project Governance You can t 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 naïve 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 don t 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. That s 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 Reporting progress on a sprint using a waterfall-based status report is unlikely to add value, but can easily mask risks and issues. 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 2
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 that s 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 that s where the importance of alignment and collaboration comes in. Organizations don t 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. The development of business cases should focus on what the proposed initiative will deliver and why that is important to the organization s ability to achieve its objectives. 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 doesn t 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 3
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 aren t 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. It s 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 organization s 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 organization s 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 aren t 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 4
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 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. 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 departmentfocused 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. 5
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 There will be occasions where arguments can be made for the execution of projects using either approach, and there shouldn t be an expectation that there is always a right or wrong answer. 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 shouldn t 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 that s OK. What s 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. 6
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 hasn t 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 isn t 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. 7
About ProjectsAtWork ProjectsAtWork is THE online destination for leading-edge approaches and perspectives in program, portfolio, and project management. Our goal has always been to engage and collaborate with the PM community, bringing fresh thinking and new ideas to the forefront while building bridges to techniques that have stood the test of time. Established in 2001, ProjectsAtWork has evolved with the project management community, reaching a steadily growing audience of project, portfolio and PMO leaders, business executives, consultants and team members working in all types of organizations and industries across the globe. For more information, please visit http://www.projectsatwork.com. About PowerSteering Software PowerSteering Software is the leading 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 Development, Process Excellence and critical Business PMO initiatives. For more information, please visit http://www.powersteeringsoftware.com. 8