March 9, 2015 Zack Sionakides , , no responses

Agile Proposal Management

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:

  1. Requirements Specification – SOW or PWS
  2. Design the solution – Technical solution, Win themes, Proposal outline, Teaming, etc.
  3. Implementation or Construction – Write and develop the proposal
  4. Verification – Color teams (red, gold, etc.)
  5. Maintenance – Post proposal submittal activities (evaluation notices, audits, etc.)

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:

  • Executive control is lacking throughout the process and is typically executed very late in the proposal process at red or gold team reviews. This causes the mad scramble to re-do the proposal to align with what the executive sponsor really wants.
  • Waterfall development is typically challenging to manage in very complex conditions, particularly where there are unknowns and unpredictable variables. In proposals this can be things such as: Q&A and modifications from the Government or client, teaming arrangement changes, or new business or competitive intelligence comes up that necessitates a change in approach.
  • Integration of the solution and verification of the product to requirements comes late in the process. This is when all the proposal problems come home to roost (i.e. poorly written sections, unfinished tasks, lack of alignment between different parts, etc.). The effects are disastrous on schedule and costs, and the rapidly approaching deadlines leave limited options to effectively correct the situation.

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].

  1. Conduct short iterations (or sprints) of one or two weeks with the goal of a working product at the end of each sprint. Working product means that it has been tested (reviewed for compliance and suitability), integrated in the master product (one voice), and is potentially shippable. This product can then be reviewed and retrospected with the product owner (this should be the executive sponsor or capture manager) at the end of each iteration, allowing changes and revisions to be made at that stage in the process, vice at the end stage with traditional methods. In essence a mini red team is conducted during each iteration, and a mini gold team conducted at the end of each iteration.
  2. Have daily scrum meetings where each team member reports what they did the day before, what they are doing that day, and what impediments they are facing. The scrum master (proposal manager) takes for action any impediments of the team, allowing the developers to focus on their tasks at hand – producing a great proposal.
  3. Use a product backlog to manage all the requirements of the proposal. The backlog consists of all the items required or that can add value to the final product. For a proposal, items can include: various writing assignments, compliance items, pricing sheets, various graphics, charts, subcontractor documents, etc. The key with the product backlog is to provide the product owner (executive or capture manager) a centralized location to assess the development effort, make changes to the items, and prioritize effort. The product owner is responsible for the backlog and for maximizing value of the product and the development team’s effort.
  4. Use the iterations to measure the work capability (velocity) of the development team so as to adjust resources or expectations as needed in future iterations. Using this measurement technique gives the product owner a reasonable idea of what the team is realistically able to do during each iteration, and they can make strategic or tactical adjustments as necessary to meet organizational strategic goals.

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

Share it!
Aenean mattis venenatis

Leave a Reply

Your email address will not be published. Required fields are marked *