Written by: Mike Sanders
Senior Health Consultant
Delivery
When it comes to project management, product management and the deployment of tools and services, it’s all about delivery. Regardless of the quality of the deliverable (a topic for another day!), what customers will often remember most, is the quality of the delivery. Therefore, it’s important to consider the platform and mechanism for delivery as fundamentally as the scope of the project / product itself. Selecting the right approach can improve the speed of delivery and the quality of delivery, but even more importantly, can create a better quality end result, endear end users to the programme, it can encourage engagement, feedback, collaboration and quality embedding of the project / product into business as usual (BAU).
Options – Project vs Product
There are infinite variations on delivery methods and deployment approaches, but with the rise in popularity of agile / product management, the most common question we currently get from aspiring delivery managers is: Should this delivery be a project or a product? This is, perhaps unsurprisingly, a difficult question, because the answer could be either, both or neither.
Clear as mud? Let’s look at them both and start unpicking the differences:
Projects
In the words of the project management institute (PMI) is defined as:
… temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal.
Because of the finite and tangible quality of a project, they have historically followed traditional, waterfall methods, such as Prince2. However, in recent years, due to changing mindsets around user expectation and support, there has been a marked shift to more agile ways of working, such as Scrum or Lean, which has in turn generated a migration to products from projects…
Products
A product is loosely defined as:
…a good, service, platform, application, system, etc., that is created to meet customer and business needs. In retail and manufacturing, this may be taking materials and turning them into finished goods. In technology, a product may be software or a service.
This open description, provides teams more flexibility, creativity and, crucially, more engagement with the users, when delivering products or services; when viewed alongside each other, it becomes clear why the project approach often runs into problems of inflexibility, scalability and predictability. As the product mindset leans towards engaging people with openness and empathy, the product can often yield more accurate, impactful and effective results. Don’t be fooled, however, if this approach is not adopted effectively and led with purpose, the increased flexibility, engagement and iterations, can become unwieldy, messy and counterproductive.
Summary
So whether you should utilise a project or product approach comes down to a number of crucial factors; team size, appetite for approach, tool or service being delivered, team skillset, is there a crucial timeframe or other milestone, etc.? Before any major delivery it’s always important to perform a readiness assessment to understand your current status, identify your goals and select an appropriate approach.
