Pros and cons of both product-oriented and project-oriented development are well known, but some companies try to mix both paradigms, apparently to get the best of both worlds. How does it look alike in practice? Does it make sense? What are the drawbacks?
Let's start with the basics. Project-upon-product: how does it work?
- Actual development teams work in a product-oriented regimen. "Product" is defined & bounded. There's a dedicated PO - in charge of the product backlog & work priority queue.
- Revenue is acquired by executing projects - which are all about deployment & integration of "products" for client companies. Some projects do require a lot of flexibility: in terms of customization & adaptation to client-specific conditions. The more coarse-grained the project granularity (projects are fewer but bring more income), the more flexibility is (usually) required.
- Once the project is "sold" & phases into execution, the work to be done is being allocated to the product teams. Project Managers negotiate with Product Owners prioritization of their projects' work within backlogs. Obviously, the goal is to squish the work in in a way that doesn't exceed any contractual deadlines (of the project).
So, to summarize it:
The rigidity of the project's fixed scope (& contractual terms like deadlines) is mapped onto the flexible (up to some limits ...) reality of iterative product development. Written obligations & schedules VS on-the-go short-term planning.
What could go wrong?
Only a million of things, e.g.:
- If the project doesn't book the team allocation explicitly beforehand - what's the guarantee the team will have time to execute project work when it's time? Within the assumed timeframe?
- Even if the Product Owner is forced to give the project work top priority, what if more projects are "sold" than the team can handle? It's hard to estimate the time & effort for a single project, but it's exponentially more challenging in multi-project reality, where Project Managers sell & compete for "resources" independently.
- Even if Project Managers (& Sales) fully consult Product teams & ask them for their estimates, Product team reality changes very frequently (& that's no guarantee someone who does estimation will do the actual work) - that actually encourages the "sell now, worry later" approach.
- Needless to say, all the advantages of Product-oriented development pretty much disappear: work ain't evolutionary, forget about product feedback loop, welcome deadline-driven development, etc.
- What may be even worse - the Product team is reduced to a task-fulfillment workforce. Someone else is in charge of the scope, controls the execution. The team's role is to deliver their part of a Gantt chart, probably even w/o getting a proper "big picture".
My point is NOT to criticize the project-oriented development style. It has its drawbacks, but there's pretty much no other (reasonable) option for some business models. My issue is with mixing both (product & project) realities and pretending that there's any advantage in that. There's none (unless projects happen very rarely and don't take much of teams' time).
If projects are your main source of income (as an enterprise), I strongly believe it's better to put a clear line between your project and product oriented teams:
- for each project, build a 100% dedicated (technical) team (out of available people, for the project's life period) that takes ownership over the project (planning & execution) - it can start small & be extended gradually
- if you have an allocation variety problem - you never know who'll be needed for a project, you have a fundamental functional architecture problem with your products: there should be a very clear distinction between parts that are customization-friendly (expose contracts, business rule metadata, etc.) and the core parts that should never be a subject of project-related change; fix that ASAP
- in case of more flexible arrangements (than "fixed price, fixed scope, fixed date"), there's an option of pool-per-topic allocation - instead of building a dedicated project team, the Project Manager agrees with the Product Owner how much effort (in terms of time/team capacity) is dedicated to the project
Such a model does require re-organizing your teams into separate units: project delivery one and a long-term product development one. It may be a challenge itself, but if you think about it for a moment, that is e.g., for big, successful SaaS providers do:
- they independently develop their products according to their strategic vision, market research, competition analysis, etc.
- and in parallel, they invest in project-focused integration and client implementation teams that are supposed to bring the actual money to the company's coffers
