Is it time yet? Time to move from a project-based to a product-based model? From an operations-based approach, focused on project delivery, to one focused on... product delivery instead?
Why would you? What would be the main benefits?
Why not just stick to a project-based structure? What are its limitations?
And, most of all: what are the challenges to expect when taking the leap to this new organizational setup?
Here are some possible answers to most of your questions:
1. But First: What's a Product Based Company?
Salesforce, Adobe, Microsoft... these are just 2 examples of product-based companies.
How are they different from project-based companies like... Accenture, for instance? They create products.
They don't provide services, they don't focus on completing specific operations within an agreed period of time.
Instead, their whole development model is centered around delivering a... product.
2. Product or Service Business: What Are the Differences?
Before we dig up the reasons why you should make this shift from a project-based to a product-based model, let's outline the key differences between these 2 organizational setups:
2.1. The service-based development model
It's your team's skills that you're providing. And it's their skills that the client, itself, “buys”.
Moreover, in an operations-based approach, the customer experience is the top-shelf priority for the development team. Therefore, a great value is set on the relationship that they forge and “nourish” with the client.
2.2. The product-based development model
It's a physical/digital product that your team delivers.
A product that's consistent in quality for every single customer. Therefore, the user experience becomes quite predictable: the same product provides fairly the same experience to all its customers.
3. And What's a “Product”, More Precisely?
See it as:
“Something” that delivers value to a customer base.
And it can be either an IT or a business product...
Note: one of the common mistakes that companies used to make was not approaching IT products the same way that they approached business products.
4. The Project-Based Development Model
Or the “waterfall” approach...
Here is this model of software development reduced to its key steps:
- a client needs a digital product (e.g. a mobile app)
- a project team gets put together, including people assuming several functional roles: designer, quality controller, project manager, developer
- they collect all the project requirements during a preliminary meeting with a client
- then, the team gets to work
- after a few months, they consider that the resulting product meets all the client needs and requirements
- they present it to the client
- who might not be 100% satisfied with the result
- next, the project team goes back to work and makes the due adjustments several times
- once the project is completed and accepted, it goes live and delivered to the end users
- the team disbands and the team members focus on new projects, probably as part of other teams
5. The Product-Based Development Model
And now, here's a product-based development cycle in 4 steps:
- multiple cross-functional teams are put together, made of developers, quality controllers, designers, a product owner, an agile team lead
- each team carries out a task collaboratively
- the whole process is centered around continuous improvement: the minimum viable product gets released, followed by several upgraded versions, till the final one gets launched
- with each iteration, the product team evaluates the users' feedback and identifies the next improvements to be applied according to those user reactions
In short: when you switch from a project-based to a product based model, your work gets structured around the idea that, over time, the product(s) you're creating keeps getting better and better...
6. Why Not Stick to a Structure Based on Project Delivery?
In other words: what are the project-based structure's “flaws”?
First of all, it sets up some sort of silos between business and development operations. And, implicitly, between priorities, as well, which should be tackled holistically instead.
IT and business share different strategies and different visions...
And this silo approach, where the 2 departments, IT and business, do not share the same goals and priorities, has an impact on the final project, itself.
For instance, in many cases the development team would underrate priorities like... risk mitigation. Even if that's highly important for the projects they develop.
7. Moving from a Project-Based to a Product-Based Model: Key Challenges
There are 3 major obstacles to overcome when you decide to shift from a service-based business to a product-based work model.
- success; perceiving IT as the main cost driver, whose costs need to be cut down, instead of a source of profit
- budgeting
- approach to teams; assigning teams with tasks instead of assembling project teams
And still, the main challenge remains:
Approaching the products to be developed with a business perspective. A perspective that you can then assembly teams around to support.
And this shift of perspective calls for a shift in the way:
- you manage your budgets
- you put together your teams
- you plan your product development cycle(s)
- you mitigate risks
- you set up your hierarchy of priorities
The END!
The ideal organizational setup that you should aim for is that where:
Your product teams are made of both IT and business people that tackle tasks collaboratively. Not disconnectedly...
Where they all — the software developers here included — focus on aspects like risk mitigation, as well, and not exclusively on business functionality.