Tom BjörkholmConsultant| Knowit ConnectivityLinköping, Sweden
I would like to get some feedback from you experts here on the balance between one bigger project versus many smaller projects.
This seems to be a recurring question in organisations I have worked for.
Here is an example to illustrate the question:
There is a small R&D development group (approximately 5–10 engineers). This group has developed and is continuing to develop and enhance several products. These products are used as building blocks in larger products. The customers of this group are a handful of other R&D organisations developing one large product each. The customers are running waterfall style R&D projects that require new features in the products produced by this small group, in order to create new versions of the larger products. There is a single person available to act as project manager for the projects run by this small group.
One approach to this would be to set up a small project for each of the projects of the customers that require work from this small group. The advantage of that is that each project in this group would map in as a sub-project of the project of the customer. This means that the project scope, requirements, success criteria, etc. will be straight forward to determine. The downside of this is that the resource allocation and priorities of the developers cannot be handled inside the project, but all such matters become inter-project questions. Most tools for prioritisation and resource allocation are easier to use inside a project, than between projects. To set up program management when the total number of persons is less than 10 appears like overkill. Also, in the extreme cases the engineers in the group find it funny when the same project manager changes hat and approach them as a representative of another project.
Another approach would be to set up one project handling all the customers. This make priorities and resources easy to handle, as all of that are decisions internal to the project. The downside is that the project time frame and scope becomes somewhat arbitrary. The projects of the customers do not run in synch with each other. What will be in the scope of this project, and what customer requirements will have to wait for the next project? In the extreme case this approach might deteriorate into operations (as opposed to projects).
A third approach would be to set up separate project for each of the internal products. Then those projects would each handle a release cycle of an internal product. This gets most of the problems and benefits of both of the other approaches, but in different proportions.
Do you have any opinions about what approach to take, and what consideration to make when selecting an approach? Saving Changes...
From my experience in matrix organisations, I see this more suitable for Product or Product Portfolio management:
- Define list of products in portfolio and product roadmaps
- Create a prioritised list of candidates for projects by product based on portfolio strategy and product roadmaps. Priority can be based on urgency, cost savings/revenue expected, importance of the customer, link to strategy, contractual or regulatory requirements...
- Select top priority candidates to be managed as project
- Manage the rest as activities (e.g. via schedulers, Agile SCRUM) for which you might need a really good tool that allows you to define tasks, link them to product and project (if applicable), set deadlines and priority, assign them... And has good reporting capabilities Saving Changes...
Tom BjörkholmConsultant| Knowit ConnectivityLinköping, Sweden
Thank you Maria for your kind answer. Your suggestions make sense, and I have seen companies successfully work like that.
What is the best approach if the company prescribes that all tasks shall be done within projects? Saving Changes...
"If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time--a tremendous whack."
