Is this a bid and proposal scenario you see in your organization? The proposal gets to the red team (or worse gold team) and the product is just way off. It could be of poor quality, incomplete, or not aligned with the organization’s vision, strategy, and ways of doing business.
What happens next? A mad scramble to fix the proposal with all the associated costs and stress on the workforce, a no bid of an opportunity and all the investment to that point down the drain, or submission of a substandard product that has limited chance of winning and probably reflects poorly on your organization with the client. Why does this happen and is there anything that can be done to fix the issue?
The commonly used proposal management methodologies from sources such as Shipley or APMP typically use a traditional waterfall type development methodology. In simplistic terms, the waterfall method follows a process of:
These waterfall approaches have a number of good features in that they’ve been around a long time, making people familiar and comfortable with them, they are simple and easy to understand, and they recognizes the need to move by stage gates. If you are building a bridge or a skyscraper, a methodical waterfall approach is critical to ensure the final deliverable meets expectations. However, there are downsides to waterfall approaches that can be seen in proposal development:
The common solution to these proposal problems is to have a retrospective where everyone agrees that the process needs to be followed better, and to maybe add in a few new procedures or forms to ensure better compliance. This may work for a short period, but many of the issues with waterfall methodologies are inherent in the process itself. Luckily, there is an alternative project management methodology being commonly used in the software development world that can be used in proposal management as well – Agile.
Agile is based on iterative, incremental development of small tasks, vice large implementation phases. The iterations are done in short time frames (usually one to four weeks) and a working product comes out of the iteration that can be demonstrated to stakeholders and product owners. Integration and testing is done during each iteration allowing for rapid feedback, easy modifications, and better decision making. A product backlog of requirements is maintained to determine which tasks will be undertaken during each iteration and to prioritize development.
So how can we use agile for proposal management [Note: This is based on the Scrum framework which is the most commonly used agile methodology in practice].
Putting agile methods in place will not guarantee successful proposals by itself, however studies have shown measureable differences in outcomes of agile methods versus traditional methods. Project success rates with agile are typically 10-20 points better (slightly under 50% success rates for traditional methods versus near 70% for agile), and there are measureable improvements in productivity, quality, customer response, and lower costs.
Implementing agile is no small task and does require a paradigm shift in organizational culture. However, many proposal managers already use ad-hoc methods to deal with the problems that come from traditional waterfall processes. Ad-hoc methods are often a sign that more flexibility and agility is needed in the process. Updating the organization procedures to align with agile, can improve flexibility and being able to respond to change that is the norm in business. There are plenty of opportunities to learn about agile methods and this is a change that can be done via beta testing before implementing throughout the organization’s business development unit(s).
Originally published by Zack Sionakides on LinkedIn