You have probably heard about the agile approach. It was created to help software developers keep pace with ever-changing business and customer requirements. Agile practices enable developers to create better products, faster and more efficiently.
The approach is so effective that many companies, especially technology companies, now apply agile principles throughout their organizations. These companies are also leading when it comes to digital transformation, probably because they are working hard to cut costs and increase efficiency.
Interestingly, one of the results of this drive is an increase in the volume of RFPs these organizations are issuing. And an increase in the volume or RFPs they are responding to - which is great for RFP professionals.
In order to respond to a greater volume of RFPs, you’d need to do one or more of the following:
For most businesses, options 2 and 3 are the most appealing. They’re also the reason that proposal and RFP management is the perfect candidate for agile practices.
An agile framework for proposal managers
There are several types of agile frameworks, each the topic of many books, blogs, lectures, and TED talks. To keep things streamlined and simple, an approach in line with all agile frameworks, we’ll focus on only one: Scrum.
Scrum is an agile framework. An agile framework is not a set of formal, sequential processes; rather, it describes roles and rules that are focused on removing obstacles and addressing dysfunctions.
Scrum is the most popular agile framework because it’s simple and flexible. The building blocks of Scrum are roles, events, and artefacts, and each element has several sub-elements. However, the value of Scrum is in its flexibility. For the purposes of a company applying Scrum to the RFP process, only a few pieces are required.
The roles in scrum are:
The product owner is the person who best understands the client, marketplace, competition, and/or the relevant product or service. Then delete the final sentence.
This is a project manager with a twist. The job of a scrum master is to facilitate rather than to oversee. The scrum master clears away obstacles, aids communication, and runs interference. In some organizations, teams choose their own Scrum masters; in others, the Scrum master is selected for their ability to work well with the product owner.
Development teams should represent all the competencies relevant to the RFP. For a company producing an RFP, that team might at least include the subject matter experts most familiar with the type of problem the customer needs solved; a marketer who understands how to align your strengths with the prospect’s needs, and an administrator to produce the document.
Other team members might include business development personnel, proofers, or any other people that make sense for a particular RFP. Only have the team members that are necessary and no more. The intent should be to keep everything as simple as possible.
Events in Scrum are organized around sprints. A sprint is a defined period of time in which specific work is completed. Within each sprint are the following components, which are also restricted to a set period of time:
Sprint planning answers three questions: What deliverables will result from the sprint, how they will be achieved, and what is the goal of the sprint? For a team using Scrum to answer RFPs, the sprint might be the RFP response in its entirety, or it may be pieces of the response; for instance, there may be a sprint to develop the budgeting section and another sprint for the rest of the document.
How you define a sprint will depend on the RFP, your experience in responding to RFPs, and other unique factors. The golden rule is: do what makes sense as simply as possible.
Sprint planning meetings that focus strictly on those areas can (and should) be kept as short as possible. As your team becomes more experienced in executing sprints, the meetings will likely become very short since everyone will know what their role requires. Likewise, it’s a good idea to take a fresh look at how previous sprints were organized when answering a new RFP; a team that simply replicates the same original sprint for RFP projects months or years down the line is probably
missing an opportunity to streamline the process further by reusing content rather than creating it from scratch, or wasting cycles on communication processes that are overbuilt for their now seasoned team.
A daily Scrum is a short stand-up meeting in which every team member states what they did yesterday, what they will do today, and whether any problems have emerged that might hinder the team’s ability to meet the sprint goal. The product owner or Scrum master may also raise concerns or provide useful information.
The Scrum Master usually schedules the meetings for the same time and place to keep things simple, and during the meeting, it is the Scrum Master’s role to hold each team member accountable for their assigned results.
While daily make sense for big teams that are focused solely on meeting the sprint goals, a smaller company answering an RFP probably doesn’t need to meet daily. As with all aspects of Scrum, the Scrum team should make changes that make sense for their purposes.
The sprint review is conducted by the Scrum Master and includes the development team and anyone invited by the product owner. During a review, the product owner explains what has been achieved and what remains to be completed by specific dates. If there have been any changes to the market or other strategic shifts, they are addressed in the review. The team describes what went well, what problems arose, and how they addressed those problems. The entire group works together to determine next steps that can be used for planning the next sprint or a similar sprint for a future project.
During the sprint retrospective, all the members of the team examine what went well in terms of people, relationships, processes, and tools. Areas for improvement are identified, as well as strengths that should be replicated. The deliverable is a plan to implement improvements to the Scrum team’s processes.
The product backlog is a prioritized list of everything needed to produce the RFP. The product owner is responsible for the product backlog, including its content, prioritization, and availability. Product backlogs are always works in progress; they are never considered complete. An initial product backlog may only consist of the requirements that are known at the time of its creation, but those requirements are grown and modified as the product owner and development team learn more.
Your scrum, your choice
The elements of Scrum—roles, events, and artefacts—were conceived in service of developing software products, so not every element is a perfect fit for answering RFPs.
Proposal teams that want to produce RFP responses in the same way businesses produce products—with speed, accuracy, and consistent quality—will bend the Scrum framework to suit their particular needs. For instance, daily Scrum meetings are probably overkill for most RFPs, especially once a team has used Scrum a few times.
By then, the team members will know their roles and the proposal management system will be populated with a rich product backlog that can be used to quickly develop new RFP responses.
Flexibility is the essence of an agile framework, so people tend to modify the way they implement the processes, so much so, in fact, that there’s a name for modified Scrum: it’s called Scrumbut.
In the world of Scrum, Scrumbut is vilified. The thought is that if Scrum is modified, it’s no longer Scrum and the benefits are lost. So teams that plan to change the way they use Scrum should monitor the results and be careful not to modify the framework so much that they end up incrementally reverting to the cumbersome traditional project management methods that they were trying to escape in the first place.
The importance of the user story
To help guide a sprint, Scrum teams rely on user stories. Traditionally, user stories are created by software development teams to describe a software feature from the user’s point of view. Software developers write stories for generic users.
Proposal teams have an advantage when creating a story for a RFP— the user is a known quantity who has provided specific information on what they hope to gain from the engagement. For a team developing an RFP, the user story will describe the firm’s specialization or expertise from a prospect’s point of view. If possible, it will also include non-functional needs, such as the prospect’s known preference for firms that champion diversity, even though the problem defined in the RFP is not related to diversity.
The Discussion is the Deliverable
The deliverable is not the user story itself; it is the discussion among the development team that arises from examining the story. The story’s value emerges as the team gains a deeper understanding of how the RFP should be shaped in order to resonate with the prospect. The user story is referred to throughout the development process, acting as a touchstone to ensure that every piece of content in the RFP response is aligned with the prospect’s hopes, fears, and expectations.
Every piece of content in the RFP should, either subtly or overtly, refer back to one or more elements of the user story.
For a law firm for example, the About the Firm section may be tweaked to mention the firm’s history of successful patent work, the partner bios may be adjusted to highlight experience in guiding businesses through the funding process, and so forth.
User stories can be created at any time during the RFP development process, and by anyone on the team. They can and should be changed as the team learns more and as stakeholders offer comments. In most cases, the product owner will be in charge of creating them, since that is the person who is most familiar with the client and the market.
Putting it all together
How a company executes a Scrum will vary according to its particular structure, culture, and requirements.
However, the principles remain consistent:
- Assign roles
- Communicate concisely and frequently
- Choose an intelligent and intuitive proposal management system
- Always value common sense more than the sanctity of an established process
Qorus proposal software can help your team become agile
Qorus is an intuitive, Microsoft-based proposal management solution. It plugs right into Word, PowerPoint and Excel, and adds a powerful interface to SharePoint. It enables you to easily assign roles, communicate, and collaborate.
If you haven’t seen Qorus in action yet, we invite you to request a short demo: