I'm
assuming you want a different development process.
Without knowing what you are doing exactly, it is difficult to say, because different situations are suited to differenct processes.
I suggest you move to an agile process:
- They are popular and will look good on your CV, especially if you have used "formal" processes elsewhere
- Studies show they produce better results quicker (especially where point 3 applies)
- They work well in a situation where the problem is not well defined (as you are doing a research project, you fall under this category)
- Some studies show they do not work well for large teams: you don not fall into this category
"Formal" methods (Scope --> design --> implement --> test --> release), which is what 4D seems to suggest from what I could find of it, is problematic. Getting the design right is hard for any significant system is
hard, doubly so for a research system all other steps are predicated on it. The main "benefit" of this approach is that managers think they have a concrete plan (but often this is flawed due to the difficulty of planning). It is also what people are normally taught as the "correct" methodology because it looks strict.
I suggest you look up
XP (eXtreme Programming) as your first choice: it works well with small groups is responsive and doesn't have much documentation "drag". Depending on how helpful/ knowledgable/ flexible your panel is, they may not accept it as they might think it is just chaos if it they do not understand what XP is properly.
An alternative is
Scrum, it will be easier to sell to your panel as it has some light planning in (with increased documentation drag, but nothing compared to formal methods). See
A comparison between XP and Scrum[
^].
In the case of either XP or Scrum it is important to understand what the methodology is trying to achieve, and apply it thoroughly. Pair programming may seem slower on the face of it, but it is quicker. Unit tests must be used, they will save work on a project that is weeks long even if they seem unecessary in the outset, and goe some way to replace documentation if done well.
All this is my opinion, others will hopefully give a different viewpoints so you can select the one you think appropiate.