Yes, that one
When onboarding a new customer and starting a brand new custom project, we often run in to the following conversation: “We would like to work on the project utilizing the Agile approach, but we do need to identify budget for the finished product and we want to have an idea of a timeline”. If your company is anything like ours- you’ve heard this statement more than once. And if you’ve been in this situation before, you know how difficult and sometimes outright impossible it is to navigate the client into a pure Agile or pure Waterfall approach to a project. This mixture of project management styles is something that we internally call “Agile-but”. In this very post I’ll try to share with you our own experience on a few different Agile-but projects that we had to tackle.
Waterfall to Agile
A few years back we were involved in the development of the stand-alone cloud based WMS system with plugins for various ERP Systems. This project was originally expected to be performed in the Waterfall fashion. Original specification document was designed (BRS) and even its technical counterpart – Solution Specification (SRS) was put together. Budget was put together, development resources were decided on and allocated, and the timeline was clearly established. Development started according to plan, and first parts of the system were developed according to the plan. As development has progressed, the client wanted to switch to the agile approach, because it became obvious that a lot of changes were needed to the project plan and, more importantly, changes to the system needed to be developed and sometimes discarded to achieve the desired results. Some of the resources from the client’s side wanted to be able to participate in the project design on a constant basis and be able to affect elements of the system as it is being written. After discussing the possible implications to the timeline and budgetary implications of this switch, the project development methodology was changed to the agile style, and the project was developed in that manner all the way to its successful completion.
In our experience this is not a common occurrence, to have a client decide in the middle of the project to completely switch the delivery approach. Fortunately, common ground could be found with the client’s various influencers to achieve a graceful transition. After a common system code was developed, switch to by-weekly builds was quite easy and painless. At the end, delivery team’s flexibility allowed the client to achieve desired involvement in the project and flexibility of bi-weekly builds, even though multiple design changes without formal change order process meant that original timeline and budget were no longer relevant.
Budgeting for Agile
On multiple occasions we were presented with the dilemma where the client needed to have a budget and a timeline for the project while still needing to maintain the agile style of project delivery. In this case, BRS is essential to determine the initial requirements for the product and to be used as a starting point for identifying budgeting and time line requirements. A few times we had to perform a project in this manner, we used this approach. BRS becomes that minimal project documentation. In one specific instance, a project required a separate group of sessions to create a BRS. After the initial set of sales meetings it was determined that a separate set of sessions will be required to determine the set of requirements. Client was quoted a BRS portion of the project as a separate project of its own. Afterwards, BA had a group of requirements gathering meetings with the client and developed a BRS in 8 days. Using the developed BRS, the team was able to come up with 2 estimates for time and finances treating the project as a Waterfall and Agile projects. Afterwards, it was explained to the client the quotation methodology itself, demonstrated how switching between Waterfall and Agile affects budgeting and timeline, and provided an appropriate risk factor for obtaining the proper financing for the job.
In conclusion
In our industry it is critical to be flexible in accommodating client’s wishes. It is often unavoidable to run some sort of a mix between different project methodologies to satisfy client’s needs. As long as you’re clear upfront with the client the differences in those 2 approaches, their benefits and downsides – you should be able to navigate your project to its successful conclusion according to your client’s wishes. After all, what is project management if not managing work and expectations of all parties involved.
Greg Reznik,
President at FiduciaSoft
Linkedin profile