Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

Background

We have got a R&D department within our company. It consists of a few 'core team members' who work full time. They are open-minded technical people who jump into new ideas and try to do whatever they come up with. Also there are a lot of ad-hoc / part-time members who want to do something else than their normal projects or want to try some new technology.

The process, in general goes like this:

idea -> research -> prototype -> sandbox -> project / product.

The first step: ideas is fine; there are lots of ideas, which is good ;) The last step is also fine because when an idea becomes a project it goes out of the R&D and falls into a "normal" management and processes.

Problem

The problem we have is with those three steps in the middle. As I said, there are too little core team members to cover all ideas by themselves and this is a bottle neck. On the other hand, when the other ad-hoc staff want to help, they can usually only spend a few hours a week so the progress is very slow and it is very hard to plan their work.

Questions

Is there a third way? To have a reasonable progress without queuing the ideas? How to organise their work so everybody is involved without the trade-offs?

share|improve this question
add comment

4 Answers 4

A few ideas that might help to find you an approach which is suitable for your organization:

  • 20% time. The approach used, among others, by 3M and Google. Of course it might be something different than 20%. The idea is that everyone can work for some predictable amount of time of their side project. With such approach you basically base on people responsibility - since they consider the idea "theirs" they will likely use much of their 20% time to work on it. On the other hand it might be problematic if you want to pursue ideas that are thrown at people. In other words if some of ideas are of kind that no one really loves to work on them they can be starved.

  • FedEx Day. Well, maybe not exactly FedEx Day "by the book" but similar initiative constrained by choice of subjects to these you'd like to work on. This way you gather a bigger group of people willing to invest their time to develop some of the ideas you have. On the plus side you can count the intent to deliver something after 24h and possibility of building bigger groups that can push project way further than an individual. On the other hand it can be tricky to split the work among bigger group of people. And again you have rather short sprint of work (one day) and not long-time effort.

  • Slack time. If you introduce slack time in your project teams in a consistent way, meaning that in the long run you have rather steady slack, you can invest it, among other things, into developing your R&D ideas. Tight WIP limits are one of ways to achieve that. Another idea is to constrain slack in longer time periods, like year. Depending on the way you choose you can get different specifics of people availability to your R&D project: either frequent short slots spread among different folks or rare long periods when people can focus on a task for a week or even a few of weeks.

  • Strengthen R&D team. As obvious as it might sound: if developing your ideas is important for you and you find it hard to get enough time from project team for that consider adding people to your R&D team. Do it especially if any of above methods doesn't really work because project work always gets higher priority than R&D side projects and you don't expect the source of ideas to dry out.

  • Temporary spells in R&D team. This one is variation on the previous idea. Instead of having someone to permanently join R&D team you can have a "loan" from project team to R&D group for a specific period of time, like a couple of weeks or a couple of months. It leaves you flexibility (the person would go back to their project team after all) and gives you some ind of guarantee that you will be able to work on an idea for a longer time. It usually is a nice motivator for a loaned person as well, as they can work on something "cooler" than typical project work.

Of course all of these approaches can be mixed.

share|improve this answer
    
+1 for a "loan". –  Zbigniew Kawalec Apr 16 '12 at 12:28
add comment

You may want to take a page out of Pharma's book when managing R&D projects. Although making drugs is far more heavily regulated than writing code, the key ideas are:

  • Regular and frequent kill points. From 10,000 good ideas you'll get one drug to market, and the best way to do this efficiently is to kill the 9,999 ideas that won't work as early in the process as possible.
  • Prioritization of winners. Put your time, effort and money on the horses that are winning rather than keeping the worse performers "on track". The faster you get the winner done the faster you get more money to spend on the other ideas.
  • Don't get emotionally involved. Keep the decision makers for an idea separate from those that are advocating the ideas so that when an idea no longer gives value for money it can be killed. If your key decision maker has a personal stake in the project continuing you can bet it will continue - possibly to the detriment of the company.
share|improve this answer
    
Great answer. To add to it, the best way to kill redundant ideas early in the process is to focus the research phase only on specific issues that you know will make or break the project, and assign a time frame within which the decision needs to be taken. –  Abhinav Apr 13 '12 at 6:10
1  
+1 for the emotionally involved –  Zbigniew Kawalec Apr 13 '12 at 19:40
add comment

Pawel offered some excellent ideas but I am going to approach this question in a completely different way: Why?

While having zero experience in an R&D environment, I'd suspect that majority of the ideas generated in any given R&D organization in any industry are non starters. I would suspect that the queuing process, the racking and stacking of ideas based on some set of criteria that suggest some likelihood of viability, is a valuable step in the R&D process and for the organization. It costs money to go through your middle three steps so I think it would be prudent to analyze viability against your costs and risks, which would occur in the queuing process. So trying to work "all" of your ideas without a bottleneck seems like a bad business choice. I would use the bottleneck as a filter so that I would maximize the the value of every R&D dollar spent.

Secondly, your goal of "without tradeoffs" is like a goal of perfection. It is unachievable. Nothing you can do in business, no choice, no action, will deliver benefits WITHOUT costs and penalties somewhere. There are always tradeoffs. Indeed, there is a way to organize work to maximize efficiencies and throughput; however, it has to be paid for somewhere somehow.

share|improve this answer
    
Maybe it was not mentioned before, but the ideas being processed have already been approved. So we DO want to try to realise them. The "research" phase is to answer whether we can or not. Thanks to the "perfection" comment. –  Zbigniew Kawalec Apr 11 '12 at 13:27
    
Oh!! Okay, I see that now. –  David Espina Apr 11 '12 at 13:37
add comment

You said "there are too little core team members to cover all ideas by themselves and this is a bottle neck." And really this is the key. If you don't have enough people to do ALL of the projects, then you have to pick which ones you DO have enough people for, and let the others fall to the ad-hoc teams that show up.

If you don't have enough resources, then you have to prioritize. The core members can work on some of the more important projects full-time, and provide oversight and guidance on the others as other team members become available to make sure they make some progress.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.