Sell an IT Project Using Waterfall, Manage It Using Agile

Today, there are plenty of examples of companies using the traditional waterfall project management methodology as compared to the agile methodology. Both methodologies are valid and have ample potential for success. That success always depends on the discipline of the project team and business. In my experience, it seems that most consulting firms pitch IT projects to potential customers using the waterfall method. This method allows the consulting team or business development manager to set business plans according to duration, resources, and cost. It makes sense; you need to give the customer an understanding of the overall cost and duration approximations of the project. This allows the customer to make a decision about moving forward with the project and understand its ROI after implementation. Managers can go to an extreme level of detail when putting together this kind of plan – so much so that many times this becomes the actual project plan once the project is won and the team has been assigned. There is a case that you can sell your project using the waterfall methodology, but you should use the agile method when implementing the project. It keeps the customer consistently involved, mitigates changes in the project scope, and allows for project milestones / release dates to stay mostly intact. In the long run, this can lead to reduced cost, improved team efficiency, and customer satisfaction.   Keep the Customer Involved For waterfall-method projects I have been involved in, the development team captures requirements from the business at the beginning of a project. This can take days or weeks depending on everyone’s availability. The team consumes all this information then formulates how it will implement the technology to meet their requirements. After the business signs-off on the requirements, the development team has a milestone that could be weeks or even months away. It’s up to the team manager to make sure the team is running smoothly and maintaining its progress while ensuring that the customer is informed – especially if something goes wrong (e.g. more resources are needed, scope/variables are changed, or milestones are unattainable). Following this methodology, if the business is not engaged until the milestone dates, how will the team know if it is meeting the customer’s expectations? With the agile approach, the customer is involved in both the planning of the sprint, the burndown results, and the sprint review. The customer is constantly updated with the progress of the project, so there shouldn’t be any major surprise at the end of the sprint – thus customer expectations are met.   Changes in the Project Scope are Good Waterfall says your scope is defined, thus any changes require updated requirements, sign-off, documentation, and then implementation of the changes. It could take weeks or months before the team actually does any development due to these prior required processes. Project teams cannot always follow the original plan that was introduced or was sold to the client. They will try, but there are almost always variables that change once a project gets started due to factors like insufficiently defined requirements, business user’s availability, or lack of appropriate technology. Agile says keep the scope fluid between sprints. Discuss what will be implemented during the current sprint with the business so that the scope will be defined at the beginning but fluid enough to change during each sprint without requiring change orders. The business then knows what will happen during the sprint and can agree to the list of tasks and understand any necessary changes if they occur.   Meet Your Project Milestones Using the waterfall method, you have a set of sequential milestones that need to be met. If the project team misses the dates, the customers need to know why and how much it will cost to make changes. It requires change orders, documentation, and another meeting about why the target was missed. Project teams work extremely hard to hit their milestone dates, but sometimes this can mean adding resources or making changes – both of which cost money. When you are in an agile environment, in each sprint both the scrum team and the business know what is in the pipeline, the burndown of tasks, and what is due at the end of the short, precise sprint. An agile approach allows for the team to have precise 2-4 week sprints with everyone aware of the current end date. An agile team should never miss a sprint end date because the sprint will always end to some degree of completeness or changing of the tasks. This approach pushes project teams to be more efficient. The overall project can streamline without needing major changes, and the team will understand the run-rate moving towards the sprint goal.   Agile Implementation The waterfall methodology is meaningful to a customer when trying to approximate the duration and cost of a project – especially large, multiple month or year projects. It allows the customer to have expectations of the overall cost and ROI of the project. In my experience, when an IT project gets started, there always seems to be obscure variables and scope creep that were not recognized during the selling phase. The agile management methodology used in an IT project development cycle is a great option because it allows the customer to understand the IT milestones, expected work, and burndown of tasks. It keeps the customer involved and informed during the entire process ensuring customer expectations are maintained. Resources and costs can be managed during each sprint, and the customer will not experience major surprises when milestones dates are reached. The waterfall methodology is a plausible option to use to engage a customer and set up the strategy to implement a long durational project, but using the agile methodology will allow the implementation team to continuously produce work, reduce the impact of unknown variables, and keep the customer involved in project execution and deliverables.   Authored by Justin Taylor Justin has been architecting, building and managing business intelligence projects since 1999, including solutions for several Fortune 500 companies.

When Justin joined StatSlice, he was looking for an opportunity to make a major contribution to the company and utilize his technology experience to help clients solve their business problems.   Justin has broad experience in data warehousing, business analytics, reporting and dashboards, and data architectures. He enjoys opportunities to speak at technology events, conferences and training. He holds several Microsoft certifications include MCT (trainer), MCTS and MCITP certifications in SQL Server BI, and Certified Scrum Master through ScrumAlliance.org. For More Information   For more information about StatSlice Systems products and services, call (214) 206-9290 or email us at info@statslice.com. Please visit us at http://www.statslice.com.