Finding a Partner to Trust - Writing an Agile RFP to Outsource a SW Development Projects

October 22, 2008 by Peter Stevens

My customer wanted to find an external partner to develop their new software product and develop using Scrum. So we needed to evaluate the potential partners, but how? The classical approach is to define the application “exactly”, then ask some potential vendors if they can do it and how much it will cost (and then haggle over the price). This is not very Scrum like, but it represents a starting point which is well understood by customers and vendors alike. What is different about an Agile RFP? How can a fundamentally non-agile bidding process be adapted, so that the transition to agile development be as easy as possible?

This article is Part 2 in the Agile RFP Series

Last week, I described how my team and I used Scrum to create an Agile RFP. This week, I will describe what we produced. Will this be a valid template for your project? This question is very difficult to answer, since the contents of our RFP were based on the needs of our project and our readers. The agility in Agile comes from empirically determining the best way forward, not blindly following some predefined template or process. So caveat emptor, let the buyer beware!

An Agile RFP is something of an oxymoron: an inherent contradiction. The development team should be involved from the early stages of conceiving the product to create the vision, identify the users, and write the user stories. But the team doesn’t exist yet and cannot exist until the vendor has been selected. So the Agile RFP should serve to bootstrap the process.

Based on our understanding of our readers, we created the Table of Contents:

• Company
• Goals
• Budget Considerations
• Development Process
• Current State
• Desired State
• Selection Process

Company

This chapter was just some boilerplate from the corporate web site to provide context for companies who were not familiar with us.

Goals

This section is also known as the Project Charter. What are the overriding organizational goals? What should the product do for the company? What should it do for its users? We used a Mission Statement and an Elevator Pitch to answer the product related questions.

Budget Considerations

Our goal was to ensure that the target cost fall within a range that ensures a satisfactory return on investment, even if the costs and benefits don’t work out as planned. It can be difficult to come up with a believable model. For each consultant out there with a spreadsheet, there is a manager who has been burned by believing his models.

So we simply framed the problem. How many employees will be affected by the system? How much more business could they process if their productivity were raised by 5%, 10%, etc. Or how much money could be saved?

Applying the double worst case analysis to the various scenarios provided a first approximation of a reasonable budget.

Development Process

A classical project charter will describe the roles and responsibilities of the key personnel, so an Agile RFP can simply insert Scrum as the development process. We found it helpful to recapitulate the essential points and to include our company specific practices:

• Product Owner and ScrumMaster and who will provide them
• Sprint Planning & Demo Meetings
• Burn Down Charts
• Additional metrics (test burn up charts)
• Escalation procedures

Scrum itself does not define relationships beyond the Scrum team. So we included a “Management Oversight Committee” modeled on Ken Schwaber’s Enterprise Transition Team. This should be an effective alternative to a steering committee. The MOC should meet (at least by phone) regularly and resolve impediments raised by the ScrumMaster.

Some issues aren’t directly addressed by Scrum. How do you ensure system maintenance over a 10 year period? This is both a financial question and an engineering question. These issues are best raised with the suppliers in the RFP.

Current and Desired Situations

An RFP should describe the current and desired state. An Agile RFP should describe that state in terms of what the users currently do and what they will be able to do with the new system. User Roles and User Stories is the basis of this discussion.

We augmented the user stories with a flow analysis of the current state (inspired by simple Value Chain Diagrams) and functional diagrams of the desired state. The flow analysis identified potential productivity improvements and the functional diagrams highlighted new functionality and new business potential.

We wrote a complete set of user stories for all major users of the system. The result was 20 pages long, so we moved them into an appendix. In the main document, we included a top level description of each user role, his/her duties and what that role expects from the system.

Who will buy the system?

Brainstorming on the users and their expectations led to some important discoveries. For example, optimizing the work of primary (full time) users of the system are prerequisite functions. If that is not effective, no one will want the system.

But the primary users are not the buyers. The users’ managers, the suppliers’ and customers’ sales, marketing and management and even our own top management will decide to the system’s fate, even though they are ‘only’ occasional users. By giving these users value, we can create Exciter Functions for those users who are most essential to success of the product.

Technology - not

We did not specify any technologies in the RFP. The desired functionality section focused on what, not how. We did however list some technologies that we thought might be of interest and provided links to some applications in a similar context that we liked.

Retrospective

Did we specify too much? In an agile process, the objective is to create the specification just in time through direct communication between team and product owner. This is not possible before a supplier has been selected.

Writing user stories was a good compromise. We have the basis for a conversation about the entire system, with development, with management, and with our users. We have a thorough definition of what the business wants. We learned a lot about the desired application (which lead us to shift its center of gravity in ways we would not have expected). By writing the stories ourselves, we remained business focused.

But should we really have written 20 pages of user stories? I am not sure. I had the feeling we were over-specifying. The more we produce, the more we will have to communicate to the implementation team.

This approach is a step away from a classical submission process, but is not yet purely agile. On the plus side, the vendor will be able to size the system and give us a reality check on our budget goals. We’ll see how this works when we start talking to vendors.

Next Steps - Selecting the Partner

So now we have an RFP. How do we find the right partner to implement it? Tune in next week for Part 3 of “Finding a partner I can trust”

Other Articles in the Agile RFP Series:

1. Using Scrum to Create an Agile RFP
2. Contents of the Agile RFP
3. Selecting an Agile Outsourcing Partner

Permalink