How does the RAD process model accommodate an iterative nature of adding features during the course of development, when there’s a budget.
I only know to adhere to a set amount of features/functionality. This keeps the budget under control (ie. "We'll make this, it will take this long, therefore it will cost this much.")
The RAD model encourages the adoption of new changes and features throughout the life of the project. But how are you able to add new features when there is a set budget? Saving Changes...
Sort By:
Mike Cooper PMPPrincipal Project Manager (retired, sort of)| New England Project ServicesWestford, Ma, United States
Jay, generally when working with iterative cycles and a need to constrain them financially, I have worked on developing suitable constraints. This usually takes the form of time constraints. For example, "we will work on this approach for a maximum of 3 weeks, then move on to the next section and have a maximum of 3 weeks, etc". There might be a need to constrain the number of team members working on it. Sometimes it is clear what a "cycle" in the iteration is, and how long and how much effort / resources it takes (and thus how much it costs). In this case, you might be able to make the constraint x number of cycles.
The point is, to map the cost to a budget you need constraints - in other words, a plan that is not open ended. Without this, you will have the automatic constraint of stopping work when the money runs out, regardless of what state the project is in. Or having to beg for more money.
As you work out what constraints might be suitable, make sure you set and manage expectations with the other stakeholders of the project. For example, users could be made aware that there is a budgetary limit, and you are working on setting suitable constraints. They might even be able to suggest some of the constraints. Perhaps a brainstorming session with stakeholders on constraints might be useful. The more you can get the stakeholders bought in to the idea of constraints, and ideally even owning them, the easier it will be to use the constraints during the execution stage.
Hope this helps, Mike Saving Changes...
Anonymous
That certainly makes sense Mike. I basically follow Microsofts MSF process, but with my own additions/changes.
I really like the creative a collaborative nature of spiral types of process. But, the problem i always have is feature creep.
We have a product which is basically complete. We just try to modify it slightly adhering to a 80/20 rule (80 core functionality - 20% new features). But it always comes out to be 60/40 because once the client sees we're open to their changes, they go overboard with it. Creating feature creep.
For instance, you allow the client to make changes during the Development phase because of changing business, new ideas....but the client will always add more and more feature creep, until you're expending too much labor. Perhaps a unique type of 'constraint' would keep the client happy and involved, but not so involved as to allow feature creep which could take too much labor. i'll think about it some more. Saving Changes...
Anonymous
The spiral method is supposed to be open to changes and accommodating to new features during development. But, I haven't figured out how the 'accommodating' and the 'sticking to schedule/budget' work together. anyone know?
I have a similar problem. Feature creep is killing me.
To me, this issue really comes down to A. Do you want to accommodate the client or (60/40), B. Do you want to adhere to rigid guidelines to keep you on budget/schedule (80/20).
Keeping to 80/20 is impossible, unless you really put the clamps on the client - making you look unwilling to make changes/suggestions...which goes against what the spriral method was trying to accomplish in the first place. Saving Changes...
Anonymous
In my experience the first thing you have to do with a RAD project is get the trust of the customer. This is pretty bloody hard when it is the first time you have worked with the customer. However once you have a trusting relationship there can be give and take on both sides to balance the budget, time, scope delimia (without getting lawyers involved in every discussion!).
The second thing then is to agree priorities and set some constraints for the project. Let the customer determine what is most important to them: delivering to time, budget, or scope.
Once they have a priority you can manage to it. It pays to remind them every so often that it is THEIR priority and you are making it happen for them.
From there it's down to good old project management practices and pushing the trade-off decisions back to the customer "Yes we can introduce that new feature. Is it critical to phase 1? What shall we take of phase 1 so we can still meet the deadline? Nothing? Time and Scope are your priority so we better bring in another developer to meet those priorities. I'm sure we can do a very competitive rate at this short notice...".
Jay, the 1st thing a PM should is conduct STAKEHOLDER ANALYSIS, I've attached an Acrobat file that shows you how to do this analysis. Next, follow Mike Cooper's post. When the customer wants to add new features, I suggest you provide him or her with an impact statement with perhaps 2 or 3 alternatives focused on changes to schedule and cost. ALWAYS GET THE CUSTOMER'S CONCURRENCE BEFORE MOVING ON with the project. Saving Changes...
