Project Startup Activities are Key to Success in Both Agile and Traditional Approaches

I recently attended the Business Analyst World conference in Ottawa, Canada. The audience was comprised of mostly (no surprise here) business analysts but also included project managers, technical leads, and a few project sponsors. What I found intriguing was that about one third of the track sessions were concerned with agile-related topics, and the buzz in the hallways between sessions and at lunch seemed to lean towards agile. I guess this means that agile is now solidly on the radar of the mainstream project community.

Having delivered a presentation and participating in a panel discussion on agile, many came to me during the lunch sessions and breaks to answer questions they had about the implementation of agile methods on real projects. A theme that commonly emerged was the chaos that project teams were facing in the face of inadequate project startup activities. Some believed that project startup work was essential to traditional (a.k.a. “waterfall”) approaches, while these activities were not required for agile approaches. Let me summarize for you the answer I shared over and over again during these discussions.

First off, for there even to be a project in the first place, some up front work needs to take place. For executives to approve the expenditure of resources on a project, they want to know three things: what are they going to get, for how much money, and when will it be delivered – the old iron triangle of scope, time, and budget. Typical governance policies in organizations will not allow a project to begin without appropriate approval, and those providing such approvals require this basic information to make their Yes/No decisions. Such decisions are usually based on some type of business case analysis. The level of rigor in developing the business case depends upon the size of the project, the organization’s industry, and its level of maturity. Generally speaking, however, the business cases should quantify the benefits expected from a project and the costs required to create the environment wherein those benefits can be realized. Using that information, a business executive can then decide if the project is “worth it” – i.e. do the benefits outweigh the costs enough to justify the risk and investment in the project. The work required to gather information on benefits and costs is required no matter which project delivery method is being used: traditional or agile. This information is needed to decide whether or not the organization should bother launching the project (traditional or agile) at all.

Developing the benefits analysis for a business case is one piece of work that I won’t go into detail here. The process is the same whether one is using a traditional or agile approach. Developing the cost case, however, differs somewhat.

A cost case is developed by gathering the prices of materials and labour inputs to the project. Labour input estimates from external vendors are usually provided in dollars, and internal service teams may provide their estimates in either dollars or hours/days. Regardless of whether these estimates are coming from internal or external service providers, think for a moment on what work is required to create them. In both cases, the underlying number is an effort estimate measured in hours or days. External vendors will then apply contingencies and multiply this by some type of cost rate in dollars. Effort estimates can then be translated into a project schedule/timeline. To come up with the effort estimate, however, requires a much deeper analysis.

A team being asked to estimate the effort to do some work first needs to understand the nature of the work (overall solution design or approach) and enough details (scope or estimating assumptions) about the work that they have a reasonable basis upon which to base their estimates. It is clear then that before estimates can be prepared, some amount of solution design work must be done; else, how will the team be able to prepare their estimates – they would not know what it is that they are being asked to estimate.

The overall solution design, in turn, is based on an even earlier analysis of requirements. We need to understand the business requirements that are driving the need for the project’s output in order to make sure that we understand all of the required aspects of the solution. These requirements can then be transformed in the context of an overall solution design into a list of solution features for which the project delivery team can then provide estimates.

Under most organizational governance models, all of this work is required to be completed before a project can begin. This work all leads to the completion of a business case that the project funding person or group within an organization needs in order to conduct a reasonable assessment and make its Yes/No decision on whether or not to proceed with the project.

The difference between traditional and agile methods is the level of detail that goes in to the preparation of the business case. Because traditional methods perform most of its analysis and design work up front in order to come up with a detailed project implementation plan, these methods need to spend a lot of time conducting detailed analysis in order to prepare a detailed business case. Agile methods differ in that they begin with only a high-level understanding of requirements and solution design before the team prepares rough estimates that can be put into an initial business case. Initial funding may begin with only a high level business case, but typically the detailed business case is required before the full project funding can be released. In traditional approaches, the detailed work is usually completed before developing the project solution can begin, while under agile approaches, the solution development work can begin right away and the more accurate estimates and plan are delivered after a prototype/proof of concept phase wherein the delivery team gains experience with the technology, the other team members, and the stakeholders before committing to a more firm set of effort estimates and timeline.

With the greater level of detail required, traditional approaches tend to spend more resources in preparing business cases for the Yes/No funding decision. Agile methods tend to work at a higher level of detail, avoiding deep analysis until just before the work on an element of the solution begins. This means that the organization can get to a Yes/No decision much more quickly and cheaply using agile methods. Yet, it is important to point out that a business case for an agile project still needs up-front requirements analysis and solution design, just at a higher level of detail.

Adequate performance on these project startup activities of requirements analysis, solution design, estimating and planning can mean the difference between success and failure on your project – regardless which delivery method (traditional or agile) that you use. If you are using traditional methods and do a poor job on your project startup activities, your estimates and plans will be wrong and your project will struggle right from the moment that real project begins. Similarly, and agile project that does not spend adequate time with up-front work (before the first solution development iteration) will not only have a difficult time getting funding approved, but also the team will struggle in trying to build the right solution and in providing meaningful tracking and forecast metrics to help manage the project delivery.

Many agile proponents minimize the importance of project startup activities to the overall success of the project. In part, this is due to the fear that teams will be tempted to do a full, detailed up-front requirements analysis and solution design, wasting resources on items that may change before they get implemented later in the project. In other words, they are afraid that teams will migrate back towards doing a big design up front (BDUF) – a less than agile approach. As a consequence of this, many inexperienced agile project leaders then try to launch projects without adequately performing the project startup activities, leading to failing or troubled projects and demoralized teams. Many organizations have attempted and failed at their adoption of agile methods for this very reason.

It is absolutely critical that our project leaders understand the differences in the level of detail required in traditional and agile approaches and to ensure that they expend the right amount of effort in these project startup activities. Failure to do so means that your project may not only be significantly challenged throughout its lifecycle but also its business case may never be approved in the first place.

-----

Kevin Aguanno, PMP, MAPM, Cert.APM is an executive project manager for the world’s largest IT services organization and is its Canadian Agile Centre of Competence lead. He has written over 20 books, DVDs, and audiobooks on agile and project management-related topics. Find out more at www.AgilePM.com