In a past experience as a project manager, I was also a product manager. In both roles, I was responsible for the delivery of software. It was important for me to understand the relationship between products, projects, and software delivery to be effective in my role.
A product is not by definition temporary, but if it’s decommissioned/retired, then it’s over. A product exists to solve an ongoing business need or want. If there is no need nor any want, then there is likely no product (worth sustaining).
A project is a temporary endeavor undertaken to create a unique product, service, or result. I would take it further and say this is undertaken taking into account one or more business cases.
The software development life cycle (SDLC) is often part of product development generally (where there’s software to be made as part of a product life cycle) and the project life cycle (especially planning through the end of execution, which includes monitoring & controlling).
The SDLC is a process for delivering software and is commonly known as consisting of the following phases (or some associated variants):
- Analysis – understand what should be made to achieve the relevant goals (business need or want)
- Design – determine the way in which the implementation should be done so that it is sustainable
- Implementation – make it
- Testing – make sure it works as expected
- Deployment – get it out to the relevant environment
- Maintenance – keep it running and resilient
The development methodology selected will determine when any of the above phases of the SDLC are active. The ones I have worked with are waterfall and a few agile variants (Scrum, Kanban, and XP). I will not go into detail on these methodologies in this post.
How are products, projects, and software development related?
As my role has often been a mixture of project manager and product manager, I have seen how my involvement in the product vision ends up affecting the delivery of project outcomes resulting in the desired product.
For product management, I refer to the phases referenced in the ProdBOK® maintained by the Association of International Product Marketing and Management (AIPMM):
- Conceive – generate and prioritize ideas prior to putting in product planning efforts
- Plan – define the product more clearly by covering experience design and other market validation to ensure this product is worth developing
- Develop – build the product according to the plan with deliverables and beta preparation
- Qualify – conduct beta testing through select external users to refine the product and prepare for the launch with relevant marketing and sales training
- Launch – get it out there with the appropriate messaging and acquire users
- Deliver – scale the product to maximize opportunities and increase sales
- Retire – take steps to end support for the product including preparation of any necessary license terminations or documentation on migration to other products
- Initiate – get buy-in and approval to progress
- Plan – detailed analysis of the scope, schedule, cost, and other variables that will affect the final outcome of the project
- Execute – deliver the outcome according to the plan
- Monitor & Control – take relevant steps to ensure execution is going according to plan
- Close – wrap up once the project outcome has been achieved (or some other event happens that ends the project)
From my experience the way this would work conceptually (taking into account what I said about the development methodology above) is as follows:
I have seen that according to the Optimal Product Process™ that “Launch” and “Deliver” (or Maximize) are not traditionally associated with the SDLC, but I don’t believe there is a hard rule suggesting that they do not apply in those two product life cycle phases. There are numerous professional perspectives on how the overlap works, and all of them are valid in different contexts.
In my product perspective, which is focused on non-stop momentum and sustained value delivered to customers, there should be continuous software delivery without unreasonable stoppage until the product is set to be decommissioned or retire. That includes continuous delivery during the Launch and Deliver phases where necessary.
Additionally, regarding “Deployment” and “Maintenance” in the SDLC, it’s entirely possible that there is not much to consider in a “pre-production” (Pre-Launch) phase of the product, but I believe they still apply whether we are in pre-prod or prod due to how the development operations may be set up.
To recap, when “doing the work” to get the product made, many projects can take place to build and improve the product throughout its life. If we are talking about software and in an agile development context, then the phases of the SDLC will take place throughout this building and improvement of the product typically in scope of one or more projects. The level of formality and process strictness applied depends on the standards applied by the relevant product, project, and delivery managers. Business analysts will often have a role to play in all three distinct life cycles to bridge the relationship between the three.
There is no one-size-fits-all approach in managing desired outcomes for a product or project, though I am generally a proponent of applying lean practices to focus on results over process.
The difference is clearer, so how does the SDLC work?
I will cover more about the SDLC and the associated development methodologies in another post.