I have seen a lot of different project organizations in different tertiary sector businesses, but I have never felt that IT R&D projects were well organized.

I understand that R&D projects need flexibility, and less time-constraints to give free rein to innovation.

My guess is R&D projects organization needs to be revised at a certain stage.

What is your experience about IT R&D organizations/methodologies - especially planning and resource management?

  • Do you or your boss plan them from the beginning?
  • Do you or your boss ask for time reports?
  • When do you think it's time for a R&D project to enter a "standard" project organization stage?
  • Omitting time limit, when do you think its time to get things done even if the goal is not totally reached?
  • Omitting time limit, when do you think its time to give up if the goal is not reached?

Both last ones are subjectives, I know :/

  • This seems like a great question for pm.stackexchange.com, espectially since you haven't made this question specific to Programming. While it could be closed here for being off-topic. This definitely won't be closed on Project Management SE. You could consider deleting this question and re-posting there since duplicate questions on Stack Exchange is discouraged.
    – jmort253
    Mar 20, 2011 at 20:18
  • omg another stackexchange site again... It becomes difficult to know where to ask... Anyway thanks for the remark : you're right, my question is not programming oriented but it can be classified as "development methodologies" isn't it ?. I'll edit to add this point. I'll think about recreating it in PM.
    – JoeBilly
    Mar 21, 2011 at 11:37

2 Answers 2


IT R&D is an oxymoron. IT is a discipline that is focused on the management of existing intellectual property. The term was created when computing and communications technology converged. Glass house managers needed an all-encompassing name for the operational technical specialists who managed this equipment. Software engineering is not IT. Software engineering is a project-oriented discipline that is focused on the creation of intellectual property in response to a need. Most in-house software development projects are poorly organized because they are run like IT implementation projects, not intellectual property creation projects.

  • It's probably why most software engineering projects don't meet deadlines :) But that does not answer my question. Can you get into details on how this sort of project should be organized ?
    – JoeBilly
    Mar 22, 2011 at 7:00
  • First of all, if the people in one's organization refer to one as a "programmer," there isn't a chance in Hades of fixing the problem. These organizations are structured such that software development is something that one does at the beginning of one's career. The concept that software engineering projects should be led by a practicing software engineer is a foreign concept. Medical teams are led by highly-experienced doctors. Legal teams are lead by highly-experienced lawyers. Mar 22, 2011 at 16:12
  • 2
    (cont) Most software development teams are led by business types or people who did a “tour” through software development while working on an MBA. Most successful software R&D teams have a mature software practitioner at the helm (i.e., a practitioner with more than twenty years of hands-on practice). No amount of management training is going give one the insight needed to mitigate technical risk and navigate the path that needs to be traversed from an idea to a product. Mar 22, 2011 at 16:16
  • 2
    (cont 2) A successful R&D project is usually started by principal-level software engineer. Often working with a small group of assistants, he/she usually fleshes out a new idea. Once he/she is confident that the idea is feasible, the principal will usually pitch those who control capital for more funding. If the funding is approved, the principal engineer factors and scales the project by bringing on senior-level SEs to lead small teams of mid-level and junior SEs. Mar 22, 2011 at 16:26
  • 2
    (cont 3) Each workbook usually contains the artifacts necessary to build a major subsystem. A senior-level engineer is responsible for partitioning a subsystem into configurable components (a.k.a. units). He/she then delegates the design and construction of each unit to individual team members. Depending on the design and implementation method chosen, workbook artifacts may remain relatively static (waterfall) or change as more information is discovered (iterative). Identifying the "the magic happens here" portions of the system early in the development life cycle is the key to success. Mar 22, 2011 at 16:37
  • R&D project is basically like a software development with 95% of it Unknown.
  • Hence the time estimates vary drastically depending on the effort-manpower put into the project and how organized they are in approaching the project.
  • Organization and management would be similar to any ongoing mainstream project where the deadlines,milestones keep evolving with the project progression.
  • The team is better when close knit with each member tackling a module and frequent meeting -updates to incrementally increase the understanding of the overall picture.
  • When you successfully reached the Beta basic working prototype its time to start getting things done.
  • If you omit time limit the other major factor coming to play would be money-resources availability to sustain the project.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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