Tags

, , , ,

Current R&D practice based on agile way of doing things is that R&D accepts the project and passes it through various departments, such as Systems Analysis, Test, Release Management, Licensing, etc. At the end of that process there is a hand out of a seemingly ready project, which should involve a license (where and if needed), set of documents (such as manuals) and a training session for requester. During that process though, since obviously it takes time, the requester is not really involved, or at least her involvement is limited to planned reviews of various milestone related meetings. The more the project is complicated, the longer it takes to complete it and the wider spaced are the milestone meetings. If R&D is quick with delivery, then the requester is busy checking (working with) new releases and is kept happy with some tangible progress. But if not, or if the project is truly complicated, requester (or customer) is forced to make adjustments in the original request, in order to adapt it to needs evolving from passing time. This is a fact of life: things change when time passes and original ideas seldom fit new reality. It needs to be continuously adapted, leading sometimes to great changes which often make idea from the start of work completely irrelevant and different to what comes out at the end.

This leads to following issues, just to name the few:

  • Projects are never finished. If they take long, they always are being adapted or adjusted. This adaptation and adjustment takes life on its own.
  • Projects are abandoned after a lot of work was put into them. This because passing time made them obsolete. Here some organisations pursue those dead horses anyway, just because.
  • Projects are way out of the budget. Time is money.
  • Ready projects are never truly being handed over. Because of the time spent on the project the only people who really have an idea about the product are the ones who developed it, meaning the same people are the best suited to support it. Proper training session would have to be very long to make any sense, practically for a long time product is in fact supported by R&D, draining resources needed for other projects.

So what can be done? I think that R&D does it wrong and the whole project management needs to be rethought. I am sure that involvement of requester needs to be much greater than it is now. I would envision a project team where a representative(s) of technical support and/or sales are involved as of certain development stages in order to:

  • Ensure a smooth hand out. Since technical support is involved in development, they are already trained and know the product.
  • Ensure ease of licensing. Sales would know, that what they are getting is what they needed.
  • Usability would be ensured. Sales would get not only what they want, but also how they want it. What developer considers to be good enough, market or users often find very difficult to use or at the extreme, completely useless.
  • Involving requester in development work could also result in more understanding as per what development means and maybe result in less adaptations or better specifications in the future projects, saving time in the process.

I know that this is not yet mature. But it is a start and I am sure that the idea is worth pursuing further. If it hasn’t already been – I am not so sure that I am the first who thought of it… 🙂

Advertisements