As we move into the DevOps world with regards to software development, the concept of a software development project has changed or no longer applies.
In the past the traditional approach to delivering a software product, Waterfall Software Develop Life Cycle (SDLC), involved one or more projects that would deliver the software product to the customers. This would take months and even years to deliver and normally result in a product that was less than satisfactory. There are plenty of writing and other blog posts that discuss the need that resulted in Agile practices and frameworks that improved the SDLC. I will not revisit them here.
What I wanted to discuss here is the change in project thinking that comes from the new way we manage produce and manage software. As we move into the DevOps world with continuous integration and continuous delivery of software, changes to software in the form of micro-services are being delivered multiple times per day. There is no longer a major delivery of software which in the past has been the major milestone or marker of a software development project. Software is now viewed as a product that has a continuous life and a set of features where each feature can be enhanced when the opportunity for additional value is identified or retired when the particular feature no longer provides value to the end user or customer. These enhancements are incrementally delivered over the course of hours or days rather than months. With this new way of thinking then, “Does the definition of a project change?”
The Project Management Institute Guide to Project Management Body of Knowledge, Sixth Edition, defines a project as follows:
“A temporary endeavor undertaken to create a unique product, service, or result”
So how do we apply this definition to the life of a software development product that is continually delivering a new or enhanced services, all the while it is in production. Are project day long or hour long efforts.
I believe that the definition of a project rarely applies to the software product management domain. BUT the Project Management Knowledge Areas (Scope Management, Schedule Management, Communication Management, Cost Management, Quality Management, Risk Management, etc.) are still important and must be applied in the management of software products. Although these processes are applied differently and in some cases with a “lighter touch”. For example, in the case of Schedule Management, a Product Manager or Project Manager may only schedule to the milestone level, just enough information to identify dependencies between the start of the development of a particular feature and the readiness of other products, services, and materials necessary for the the delivery of the feature.
So the management of product no longer fits the temporary nature of a project. A product is ongoing until it, in total, no longer provides value. Also, product management delivery of services is too rapid for the full planning process group of a project life cycle. Therefore if one were to take the definition of a project and apply it to product management, this mean the project would last the life cycle of the product. Yes that is temporary but with product management, a product can last decades, as long as it is providing value. This relegates the definition of a project to a budget and time construct.
