CMMI processes for R & D Projects
These projects tend be different from the usual client-driven projects undertaken by the engineering division in multiple way.
Firstly, The R&D projects tend to be a lot more ambitious than the client driven ones for the simple reason that client projects usually only happen once we have a proven expertise in some field, and we have shown that we can execute projects of a similar nature to the one the client is proposing. R & D projects on the other hand, are designed to expand the companys' capability in new directions, "to boldly go where no one (within the company) has gone before", so to say. For this reason, usual methods of effort estimation and timeline planning are tough to apply on R&D projects.
Also related to this is the problem of project management in general: by its very nature the projects are less clearly defined than client projects. And while surely the level of definition can be improved over the current low ones, a full definition in advance is not possible as such projects tend to change directions (in acute angles) all along their evolution, as new problems are uncovered and resolved during implementation. This amount of change is an inbuilt feature of the R&D project and cannot be handled by the usual "change request" procedures followed for client procedures. The changes made need to be swiftly incorporated into the process documents, and while the R & D "architect" should need to clear the change, the change decision and its update in the document should happen at the implemters level, and on his/her initiation. The R & D person should recieve a change notification, with a short window available to him/her for accepting or rejecting a change or suggesting and alternative. In short, there should be a clean and swift procedure for frequent changes to the project design and consequently, to the process documents. Such a process should also capture all the reasons for the said change, and preferably capture any alternatives that were considered, other than the one that was accepted, along with a "pros-and-cons" analysis of each.
This problem is further compounded by the fact the project vision remains in the head of the R & D "architect" while the execution is squarely in the purview of the engineering PM/PL. This is completely different from a client driven project where the project vision is transferred from the client to the PM/PL at the initiation of the project or at worst, by the end of the feasibility. At that point, in a client project, the PM/PL can work independently, with very limited dependency on the client. In an R&D project, the vision transfer currently does not take place, and in addotion, there is never an intention of reducing the involvement of the R&D architect to as low levels.
A solution needs to be found which:
- Ensures that the vision transfer from R&D to PM/PL takes place, if that is what is desired. This is tough to achieve as the vision could be very deep and wide, spaning multiple projects to create a whole, and if may just not be viable to transfer all of that information to a single PM/PL. There may be further complications related to the abilities of the PM/PL, time availability, Corporate secrecy issues, and motivational issues. On the practical side, the vision transfer needs to be documented and the amount of effort and time involved for this may be enormous. The primary issue here is that there needs to be a process for achieving this vision transfer/capture at the initiation of the project.
- If vision transfer/capture is found to be impractical or ineffectual by itself, the the only other option is for a very well defined process to ensure that unknowns in the project are resolved as early as possible. This could take the form of a feasibility study, for example. As varied teams with varied problems maybe involved in a single project, and they may have interdependencies on each other, this could be much more complex than the usual feasibility done for client projects.
- Another issue is that of physical resource availability: Client projects in general do not suffer from this problem, of unavailable hardware/tools etc due to multiple reasons (the client pays for all of these are predetermined times, thus ensuring their availability, or, the required tools are already available with us, or the tools are made available at appropriate times as necessiated by the project dependencies). This is not true for R&D projects where tools are almost always not available, budgets are small, and hard deadlines for making certain tools available are just not practical. While it can be argued that such problems can be resolved by making sure that tools are made available, a more realistic solution is to incorporate hardware/tool dependency are part of the project management process and create "what if" analyses of what effect the delay/unavailability of such resources may have on project time lines. Such "risk management" IS already part of the standard CMI process, but for most client projects such "plan B" s and (god forbid) "plan C"s never need to be put in practice. For R&D projects, such plan Bs and Cs and Zs need to be very real and planned more thoroughly than others.
In short, a modified flow for R&D projects needs to be put in place. This post just covers some of the issues that such a process needs to address. R&D projects need proper process adherence even more than client projects do (the successful execution of client projects is very well monitored by the client), but the current process is not completely applicable to R&D projects. A proper process will reduce the high level of risk currently associated with R&D projectes to a more manageable level.
Please post views below.