Using Agile to write RFP
Many of software projects are outsourced projects(at least in my country), the problem is that the project period(deadline) is defined in the RFP by the IT people of the customer(owner of the RFP)
so, how can we use agile to serve RFPs?
Around which dimensions might you propose flex, among time, scope, and budget?
What does your customer want to achieve with the FRP? If eventually the goal is, a legal binding contract, where you the supplier commit to deliver something within a fixed budget, then this contradicts the agile way-of-working.
Agile in that sense doesn’t provide you with the tools to estimate the overall costs and associated risks for a project. It just doesn’t, because it assumes that it’s impossible to determine the scope beforehand.
I think the best would be to agree working according to ‘time & material’, that is if your customer sees the benefits of working agile. Otherwise I’m afraid you will have to resort to other templates & tools.
It however would still be possible to use agile to build/deliver the solution, since it’s more of a project delivery method than it is a project management method. But it’s not suited to calculate the overall costs and risks for a project beforehand.
Prince2 recently for instance also covers agile delivery, so you can look there for inspiration.
Love to hear other opinions.
I did a little "googling" and found a lot of pages on multiple sites on this topic. Usually the solution is to negotiate relaxation of at least one of the parameters and usually it was more than one. As it has been said, Scrum isn't designed for fixed parameters. The premise of Scrum is to build the right product. The inspect-adapt loops are introduced to ensure that the end product is one that the end user actually wants. All fixed scope/price/time projects that I have ever worked on ended up having multiple Change Requests introduced that modified all three of the parameters with the exception of two. Those two delivered exactly what was asked for in the time frame requested at the cost agreed upon. In both cases, the product delivered was never used by the end users because their needs had changed in the ## months since the original requirements were provided. Every technology dependent (and even some non-technology dependent) industries have come to realize that constant change is a necessity to remain relevant. This is exactly why Agile Software Development was introduced and the driving force behind the Agile Manifesto for Software Development.
Based on all of the questions you have asked in this forum, it appears that your company is not fully committed to Scrum or any type of iterative development. If they were, then the negotiation of all your RFPs/contracts would be done towards an iterative development process instead of fixed contracts. Since you are the one posting all of these questions it seems that you are one of the Scrum Leaders for your company. I suggest that you have serious conversations with your executive management about whether they really want to have Scrum used. You may be better off going with some other project management practice, possibly even a non-agile approach.
Many thanks for your detailed reply that’s very excellent
But I need to know what is the best way to put the Time, Budget & scope for OUTSOURCED S.W. projects in case of using Agile?
From your replies, and from many sites, I found that Agile can’t decide the deadline
So, how can the customer plan his strategic planning? Suppose some company put in its strategic planning that they will have XYZ system, they need to put a date for it
@Ripple All of the fixed scope projects to which I referred in my reply were part of a strategic plan for the company for which the project was being executed. A couple of them were outsourced to the company I worked for at the time. One of the two that stuck to the plan was an outsourced project. So nothing changes in my response. Fixed projects, in my experience, are either not fixed or are not successful.
Remember that a Strategic Plan is just that....a plan. Strategic Plans provide guidance to what the company plans to do. But in today's global economies those plans often have to change and sometimes multiple times.
Not sure how familiar you are with American history, especially during World War II. But Dwight D. Eisenhower has a famous quote about planning.
In preparing for battle I have always found that plans are useless, but planning is indispensable.
Plans give you a goal but once you start on the path to that goal, you will often find that your decisions were made on limited information. Agile is about applying empiricism to decisions. That means you expect that the information you have available at the time you made the original decision will change and you will have to revisit the decisions. Plans, especially Strategic Plans, are made so far in advance that it is virtually impossible to get it right.
Maybe a suggestion for your company is to ask questions about the RFP. For example
- How much flexibility is there in the cost/time/scope in case we discover information not known today?
- Who from your company(customer) will be dedicated to the project so that we can make all work and information gained completely transparent in order to adapt quickly?
- Are you(customer) prepared to adapt the cost/time/scope based on our discoveries while doing the work?
- How will any changes from your(customer) organization be communicated and by whom?
Again, if your company is actually committed to Scrum, they will need to adapt the way that they do business and make it very transparent to your customers how that commitment is likely to impact any contractual agreement entered into. Scrum and agile can be used by contracting companies but they must adapt their business model to fit their commitment to the practices. Just as a company committed to agile and Scrum must adapt their internal business. It is truly a commitment and anything like this will require change.
Many thanks for your answer
Really you've given a great information to me, not only in Agile,but in Strategic planning also
That's it, Agile is Just-in-time planning, and traditional contracts need to be updated to fit with agile