andrew smithPMO Project Manager| Dimensional Fund AdvisorsAustin, Tx, United States
I'm trying to nudge our client services organization toward a RAD-based methodology. Currently, our methodology is heavily based on a business analyst developing thorough requirements document that is signed by the customer. Developers then build to the requirements working closely with the business analyst. The solution is deployed for user acceptance after thorough QA, and usually after an 8-12 week development cycle. The expectation of the developer is that they have delivered the solution, at that point.
The benefit is, the customer has signed up to scope via the tech spec, which a PM can easily manage to. The downside is that the end solution is only as good as the requirements doc, and the developers ability to get in the head of the customer. And while the solution is being developed, the customer's business is changing. At the end of the deployment, therefore, you are faced with many changes to manage.
My preference is to identify changes early and often by demonstrating prototypes to the customer. And our solution seems well suited to RAD. But how do you manage a customer through a RAD implementation avoiding scope creep? I understand that businesses change quickly, and I want to plan for that, but how do you apply change control without agreement on a thorough requirements document? Thanks for any help. Saving Changes...
As for a solution is only as good as the requirements doc, I agree usually. It can depend on the users, the team and the project. We use RAD to varying degrees on our client engagements. We find that a solid requirements doc may take a little longer, but the understanding gained about the requirements serves you well in the end.
One variation we have been successful with when you need quick releases (8-12 weeks) is we do a thorough requirements doc. Then break the requirements into feature sets that can fit you releases schedule. We then employ multiple prototype iterations to develop the ?solution? for that release. Depending on how much/complex your technical architecture is the first feature set can be more technical in nature. We also try to get UI look and feel out of the way in the first feature set. It all depends on the long range goal of the combined feature sets.
To directly answer you question ?how do you apply change control without agreement on a thorough requirements document??. You need agreement on the approach and agreement on the impacts of not having a thorough requirements doc. The biggest impact is less accurate estimates and more change orders. This may mean no hard dates for final delivery. Or are you going to time box? Scope, Cost, Schedule: They get to pick 2.
Scope creep can be more of an exercise in setting expectations. You can always change the baseline business requirements as long as the impact is analyzed before moving on.
Change control is about controlling change. I think of this on two levels. One is the over all project approach. How often are changes coming in? How often do we NEED to release? What are the costs (long term and short term ) and other trade offs of frequent change. The second level is the individual change request. Relatively accurate cost and schedule estimates need to accompany them so that the user can make a good business decision based on the information you provide.
It sounds like RAD may indeed be suited to your situation. The nice thing about RAD is you can make it is heavy or as light as you want.
I always try to remember to tweak the development process to fit the project, not the project to fit the development process. Saving Changes...
