Mention of the word, “methodology” need not elicit groans. Without a repeatable approach to projects it’s easy to miss key requirements, expectations, errors, etc. So use a software developer methodology for your project.
Which methodology to use?
Frankly, I don’t care which methodology you use as long as it’s not a waterfall methodology. I’ve been at clients where they describe their waterfall approach as the gating approach and that provides an apt description. Waterfall lacks the agility to deal with the change we see in projects now. You probably don’t have the luxury of launching your new site revision in 15 months. Your end users probably demand a much shorter release cycle. That cycle most likely cannot be met by a waterfall methodology. Instead, you should consider SCRUM or RUP.
Rational Unified Process or RUP provides an approach where you iterate through development and include requirements and design for that piece of functionality. Out of the three things that can change, RUP usually lets the timeline or the $$ slip. If you run into a problem developing that new portlet then tack on a few days and adjust the plan accordingly.
SCRUM uses a sprint approach to deal with change and focuses on modifying scope as change occurs. If you run into a problem developing a new portlet, then cut a view from the portlet and finish your sprint without it. At the end of the sprint, revise the backlog to slot that missing view into the next sprint. At the same time, you would push other functionality out of the sprint. SCRUM and other agile standards operate on the mantra that change will occur, you just have to be able to modify scope as necessary. If you work on a constant release cycle, that might fit into your needs nicely.
If you have a more focused release as we consultants often have, you may have to modify your approach. We usually end up modifying an agile approach to finish high level requirements before hitting the sprints. We will also add extra time if the scope isn’t as flexible as the date. It’s a matter of rolling with the priorities of the project.
Regardless, as boring as the approach seems, you need to choose and stick with a defined approach. At the same time, you need to use that methodology as a means to an end rather than the end itself. When you focus solely on the methodology then you end up sliding into disaster just as easily as if you had no repeatable approach at all.
