The process of resource (in this post, we are talking about people) allocation during the process of product development is tricky, and because there are high costs associated with the same, it requires careful planning, and sometimes circumstances can throw such planning out of the window.
For projects, where people are assembled for a specific one-off project, the situation is slightly simpler. There is a proper schedule for the project, and that project schedule defines when what resources is required for the project and this can be done with the identification of resources and their allocation to the project at the required time (or it can be done in a staggered manner with part work on their existing project and slowly taking up more work on the new project until they are fully on the new project).
However, consider the case of product development where versions of the product are released after a periodic cycle. For simplicity, consider the case where the product is released every year, say in October. During the course of the year, the resource requirements are not static. At the start of the cycle, during the requirements phase, the need for resources is lower, it increases during the design phase and can be maximum during the cycle of develop, test, fix; it is during this time that the phrase 'all hands on deck' is most suitable. But as development and testing starts to taper down, the product team needs to simultaneously start work on the next version. Identification of new features, the most critical fixes, interactions with customers to identify those features or changes that are highly needed by customers all happen during this time phrase, which usually does start before the previous version has shipped.
Even the use of more complicated requirements and workflow design involving prototyping, developing sample user interfaces, and so on, is something that takes time. If these are attempted to be started after the previous version has shipped, it will eat up the development and design time for the next phase. The problem is in terms of assigning more accomplished developers and some testers for this effort, since there will be need for simultaneous working on critical defects and so on. However, teams that have been working on multiple versions over the years have learned how to do this; the amount of resource allocation needs to be fluid, with people moving from one version to another during the course of the week, or even during the course of a work day (with the intention that these changes are not too chaotic, since that could unnerve even the most rational of people). The program / project manager, the leads and the product manager need to handle this process carefully, being careful not to fluster the people working on this too much and it will work just fine.
For projects, where people are assembled for a specific one-off project, the situation is slightly simpler. There is a proper schedule for the project, and that project schedule defines when what resources is required for the project and this can be done with the identification of resources and their allocation to the project at the required time (or it can be done in a staggered manner with part work on their existing project and slowly taking up more work on the new project until they are fully on the new project).
However, consider the case of product development where versions of the product are released after a periodic cycle. For simplicity, consider the case where the product is released every year, say in October. During the course of the year, the resource requirements are not static. At the start of the cycle, during the requirements phase, the need for resources is lower, it increases during the design phase and can be maximum during the cycle of develop, test, fix; it is during this time that the phrase 'all hands on deck' is most suitable. But as development and testing starts to taper down, the product team needs to simultaneously start work on the next version. Identification of new features, the most critical fixes, interactions with customers to identify those features or changes that are highly needed by customers all happen during this time phrase, which usually does start before the previous version has shipped.
Even the use of more complicated requirements and workflow design involving prototyping, developing sample user interfaces, and so on, is something that takes time. If these are attempted to be started after the previous version has shipped, it will eat up the development and design time for the next phase. The problem is in terms of assigning more accomplished developers and some testers for this effort, since there will be need for simultaneous working on critical defects and so on. However, teams that have been working on multiple versions over the years have learned how to do this; the amount of resource allocation needs to be fluid, with people moving from one version to another during the course of the week, or even during the course of a work day (with the intention that these changes are not too chaotic, since that could unnerve even the most rational of people). The program / project manager, the leads and the product manager need to handle this process carefully, being careful not to fluster the people working on this too much and it will work just fine.
No comments:
Post a Comment