Blogged on:

Product Based versus Services Based Project Management

As a  software project manager, over the years I’ve worked in some environments where the orientation of the projects were purely product based, others where the projects were strictly service based, and environments with where the focus of projects was a blend of both Project and Product. There are definite similarities and cross overs – a competent project manager should be able to transfer their skills from one to the  other with some adjustments. It would be beyond expectation that the transition would be seamless, but part of being a project manager is adaptability! A PM making the switch should be mindful of of a number of things that make the two environments different. First, the constraints that are prioritized in one versus the other. As you may recall, according to  the PMBOK, there are 6 competing constraints. Depending on the project and the reality of the situation, each constraint can be the priority designate .


While the constraints can entirely be disparate from one project to the next, and the conflict can shift during a single project, by and large, my experience has been dominated with the constraints laid out in prioritization as such.


Service clients usually deprioritize Time (in my experience) given a slipped timeline, unless there’s either an exogenous hard date or a special occasion hard date that has to be hit, but they generally would prefer to have it done right and in budget than on time and either with scope loss or budget increase (Of course one solution to handle it would be rolling release with segmentation of the functionality into two separate releases or with a patch release at a later date which is prioritization of scope).

Introducing the element of scale is characteristic of Product. While quality is certainly a consistent priority- a bug in a service based project can be costly, but due to the nature of service, it can be contained to one client. A luxury not shared by products where the impact can be far greater because the reach is further. Emergency patches can be difficult in service, but in product you also have to consider potential refunds or other financial repercussions on a greater scale (which is why risk is also a higher prioritized constraint).

To be sure, the element of scale also changes the nature of the investment and cost. In product, the investment is front loaded- the business unit will take a loss on the project with a potential return on investment after release. The level of loss would be unacceptable in service oriented delivery. Often in service oriented projects, a retainer exists to cover some to all of the costs (or at least cover direct costs) for development and delivery, and the remaining invoices cover indirect costs and profit margins. Alternatives to retainers would be a higher sticker price to represent 1) Forgone interest on investment investment and 2) Costs associated with risk or borrowing money to cover the cost of development (i.e: a credit line which could have a high interest rate).

In terms  of management of resources, in services based environments, having a certain level of productivity is relatively easy to track and maintain. Having teams report their hours, and setting goals for billable hours at around 80% is the norm in order deliver a roughly expected level of profitability in the project. The remaining 20% can be associate with internal projects, administration and miscellaneous (such as contributing to projects that team member is not assigned to- for example to land second set of eyes on an issue to lend a quick hand with something). Conversely, product based doesn’t have as clear a delineation for a level of attributable productivity. While reported hours can be associated to product development, the lack of billable association makes for a reduction in the ability to attribute cost to revenue.

The converse, a product based environment has the potential for a more collaborative environment (unless you have two product teams competing in tandem).  The opportunity to collaborate and not have to worry about billables and direct costs to clients is greater in product based, allowing teams to collaborate to a greater extent.

In my experience, the optimal arrangement has been a blended offering of both services and products- that is specifically, a baseline framework that the company offers for license or SaaS model, and customization of it. This has a number of benefits, not only multiple revenue streams, but  it can also aid in resource leveling of an organization, instead of a sinusoidal on demand production capacity of service or the market generated demand, (both exogenous examples, I realize), but both present the potential of crippling your bottom line by trying to change your production demand to have trouble meeting your production capacity. At companies where they experience periods of feast and famine, they can dedicate their resources to product when client work dries up instead of assigning busy work.


In conclusion, a project manager looking for ways to bridge his or her experience from product to service or vice versa need not be overly concerned about the relevance of their skills in the new environment.

Coming next: The relationship between Risk and Resource constraints.