Why the Proposal Process has Always Been Agile

The latest craze surrounding Agile Proposal Management has puzzled me since its original buzz within the industry. When studying project management and Agile as part of my MBA program a few years ago, I immediately recognized proposal management as project management, and similarly recognized the long-standing proposal best practices to follow Agile. The notion that Agile proposal development is something new or innovative baffles me. This article will examine eight key Agile terms and draw their correlation to proposals and the proposal development process.

1. Agile Project Management: Agile Project Management is a term used to describe project management that uses Agile methodologies. This may include daily standups, collaboration among the stakeholders, continuous integration and availability of working product, etc.

Sounds familiar, doesn’t it? Since I can remember, daily standups, stakeholder collaboration, and continuous integration and availability of working product (drafts between color team reviews) have long been standard proposal best practices. I maintain that standard proposal management has always been Agile Project Management.

2. Backlog: A backlog is a collection of user stories and tasks that the team needs to complete. Product backlogs are related to the tasks to be done for the overall product while sprint backlogs are the ones that need to be completed in the current sprint.

I don’t know about you, but this sounds a lot like an Action Item list. I always maintain a running list of the tasks that need to be completed before the next color team review (sprint backlog) and that tasks that need to be completed before final submission (product backlog).

3. Iteration: An iteration is a period—typically 1 – 4 weeks long—when the agile development team produces the next increment of the product. At the beginning of the iteration, the product owner defines the requirements/tasks to be completed in the iteration. These requirements/task are agreed upon by the team.

When I manage proposals, I typically have my team develop the draft in iterations too. Depending on the length of the response period, these iterations typically last 1 – 4 weeks. After each of these iterations, we review the work in progress, and the start the next iteration.

4. Scrum: A Scrum is comprised of short iterations, called sprints, within which work is completed iteratively. The Scrum comprises three key roles: Product Owner, Scrum Master, and Scrum Team. The Scrum also involves four key activities: daily standup meeting, sprint planning meeting, sprint review meeting, and the retrospective meeting. With the exception of daily standup meeting (done everyday during the sprint) the other three are done once every sprint.

In my calculations, a proposal response effort in actuality is a Scrum. The Product Owner is simply what we have always called the Capture Manager. The Scrum Master is what we have always called the Proposal Manager. The Scrum Team is logically what we call the Proposal Team. Sprints are just the writing and development process that occurs between each color review, and the sprint review meetings are what we have called the color team reviews. The retrospective meeting? It’s another name for a lessons learned meeting. Maybe to be more “Agile,” proposals could add a brief lessons learned to each “sprint.”

5. Scrum Master: As noted previously, the Scrum Master is responsible for daily standup meetings and tracking the overall progress of the product development. The Scrum Master is charged with making sure the team is not blocked at any point of time due to external or internal issues. As alluded to earlier, this sounds a lot like the roles of a Proposal Manager, doesn’t it?

6. Sprint: We’ve touched on this already, but sprint is simply the Scrum term for an iteration. As mentioned previously, an iteration is a period when the development team works to produce the next increment of the finished product—for a proposal, the development period between each color review.

7. Stakeholder: Stakeholders are anyone outside of the team with vested interests in the working of the team and the products they develop. If you’ve worked on a proposal, you know there are many stakeholders involved, and their buy-in is critical to a successful proposal effort.

8. Stand up/Daily Meeting: This is noted as one of the most important activities in a Scrum-based approach. In a stand up meeting, the Scrum Team and Scrum Master sit and discuss the daily progress for a 15 – 30 minute period. A key point of Agile is the important of keeping these meetings short and precise. Daily stand-ups—so called because they should be so brief that you don’t need to sit down for them—have long been a best practice in the proposal development process. For some organizations, these have morphed into longer, more dreadful meetings, but that has never been the intent.

Do I think Agile Proposal Development is the way to go? Absolutely. However, I haven’t recently adopted this “innovative” approach to proposal management and development; I have practiced Agile Proposal Development my entire career. For this reason, I just haven’t been able to buy into the notion that Agile Proposal Development is something new or innovative. As this article has shown, our long-standing best practices in proposal development are inherently Agile—and these processes have been Agile long before Agile was the latest industry craze. 

Written by Ashley Kayes, CP APMP

Senior Proposal Consultant, AOC Key Solutions, Inc. (KSI)

https://www.linkedin.com/in/ashley-kayes-cp-apmp-a3750413/