The Agile methodology has become a cornerstone for software development. But, in recent years, other teams—from marketing to bid teams—have taken notice of the tactics of using an Agile method for project management. The reason? A traditional, linear approach is often too cumbersome for today’s teams and an Agile process can provide new, exciting benefits.
Taking an Agile approach is definitely a new departure and way of working for an RFP response team. So what is it exactly? How is it helpful? Will it really make a difference in the RFP response process? Let’s answer those questions and more.
Question: What is the Agile methodology all about and how does it apply to a Bid team?
The Agile methodology all started in 2001 when a group of software engineers created the “Manifesto for Agile Software Development.” From these early beginnings, it has become mainstream for the software industry.
Today, the most popular and well-known Agile process is known as Scrum. By focusing on collaboration and cross-functional teams, this approach enables faster decision-making and a focus on business value. Scrum uses “sprints” to accomplish the product development (more on that in a minute).
But let’s start out with the actual roles and how that would apply to the RFP team:
- Product Owner: The manager for the proposal and who owns it
- Scrum Master: The owner of the proposal who facilitates the actual process and work
- Scrum Team: Everyone else involved, including any stakeholders
Question: How do you develop a proposal development “sprint?”
In APMP’s “Agile Proposal Development Methods” webinar, Neal Levene, Director of Proposal Management at Siemens Government Technologies, shared his first-hand experiences of developing a sprint for his proposal team. A sprint is basically the amount of time for development of an entire proposal project and/or portions of it.
“You start with the project owner who is the master of acceptance criteria for the proposal,” Levene says. “This person creates the proposal backlog with everything that needs to go into the proposal along with the team and the scrum master.
“During the sprint planning session, you determine what and how the work is going to be done,” he continues. “This is going to form the sprint backlog and what will be done during a particular sprint. And it’s important that there’s a clear definition of what ‘done’ means. That then becomes input for a sprint and the period of time where work actually gets done.”
Then it’s time to determine the timeline. According to Levene, one week sprints work well for a typical 30-day response window for a proposal. But that doesn’t mean everyone is left to their own devices for the entire week. A daily scrum meeting is always done to check on the status of tasks or address any roadblocks.
Question: What should a daily scrum meeting look like for an RFP team?
The daily scrum meetings are 15-minute stand-up meetings. It’s really all about a laser focus on status, accountability, what was delivered, what was promised for the upcoming day, and what is blocking any progress, Levene says.
Biggest no-no of a daily scrum? Discussions! These meetings must be short and to the point. If something warrants a deeper discussion, it should be scheduled later with the required team members. For many team members, it can actually be pretty refreshing not to get bogged down in long, drawn-out meetings with irrelevant issues. They can quickly get back to their own work if other team members need to hash things out further and offline.
During the daily scrum, everyone is on the line for accountability—and everyone knows if you didn’t complete your tasks or overcommitted. “It’s kind of like the rules of the buffet. You can take whatever you want, but you have to eat what you take,” Levene says.
Question: How do you know when you’re done?
At the end of the sprint is a “sprint review” meeting to review your product (a.k.a. your proposal). The scrum master will determine if it’s ready to submit or if another sprint is needed.
Of course, the sprint review shouldn’t be confused with the “sprint retrospective” meeting. This is a “lessons learned” opportunity to look at the entire process and how it’s working. “Sprint review is like quality assurance for the products,” Levene says. “Sprint retrospective is quality assurance for the process.”
Question: What are the benefits of doing a scrum and sprints for an RFP response team?
Overall, the RFP team is becoming much less siloed and requires more input and expertise from various stakeholders across the organization—whether it’s sales, subject matter experts, senior leaders, or legal. The flexibility and cross-collaboration provided with scrum and sprints allow for easier, faster ways to make this happen.
At the same time, the RFP process is no longer a linear process. You can’t just start at “Point A” and head to “Point B, C, and D” before you submit. Sometimes you have to skip to Point C before Point B, such as doing a legal review earlier in the proposal process or involving a close sales contact. And the technology that supports the entire RFP response must be able to take an organic, flexible approach to accommodate all of it as well.
Getting Agile With RFP Response
Taking an Agile approach is beginning to revolutionize how proposal teams tackle their workflow. As organizations become more and more cross-functional, the proposal process must do so as well. Adopting an Agile method—along with a scrum framework and technology that can support the activities and deliverables—will deliver greater insights and inroads for successful, faster, and more effective proposals.