Everyone knows the difference between Products and Projects – right? I mean, doesn’t everyone understand what these terms mean and what functions Software Configuration Management (SCM) provides to them? Maybe so, but not in my personal experience. The tasks associated with Product Management and Project Management vary as much as their definitions. In the following sections, I will give a few definitions and show how SCM supports the various stages in both Product and Project life cycles[1].

• Product – Webster’s Revised Unabridged Dictionary states that a product is, “Anything that is produced, whether as the result of generation, growth, labor, or thought, or by the operation of involuntary causes; as, the products of the season, or of the farm; the products of manufactures; the products of the brain.”[1] I will go a little further and say that a product is something created for use and a successful product is one that is delivered in a timely fashion and satisfies a user’s expectations as to use, features, cost and quality. Nothing requires a product to be physical; however, it must have some perceivable manifestation.
• Project – Webster’s Revised Unabridged Dictionary states that a project is, “That which is projected or designed; something intended or devised; a scheme; a design; a plan.”[2] It goes on to state, “A project is something of a practical nature thrown out for consideration as to its being done. A design is a project when matured and settled, as a thing to be accomplished. An ingenious man has many projects, but, if governed by sound sense, will be slow in forming them into designs.” In other words, a project is a planned intent to deliver functionality in a product. The way we use the word, it means the life cycle stages from just prior to Requirements Elicitation through delivery of something that satisfies the agreed upon requirements.
• SCM – Software Configuration Management is a specialization of Configuration Management (CM), which, according to Wikipedia is, “a technical management model that focuses on establishing and maintaining consistency of a product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life. For information assurance, CM can be defined as the management of security features and assurances through control of changes made to hardware, software, firmware, documentation, test, test fixtures, and test documentation throughout the life cycle of an information system.”[3],[4] We normally include the tasks of Version Control (VC), Defect, Issue and Enhancement Tracking (DIET), Build Management (BM) and Release Management (RM) as part of the SCM umbrella, though not all organizations will actually have these performed by the same non-development team.

• Define what the meat consists of, its basic granularity (texture) and how it should be prepared for taste, texture and safety. This includes thickness of a “patty,” method of cooking and final internal temperature.
• Define what type of bread the bun consists of and how it should be prepared for taste, texture and safety.
• Define which condiments will be offered, how they will be dispensed (self-serve, prepackaged or on the Product at time of delivery).
• Implement the defined (and refined) requirements.
• Perform Quality tests and feedback into the Implementation phase until satisfied.

 The second Project could be the introduction of multiple variations of the hamburger such as thicker patties of meat, multiple patties of meat, additional condiments, addition of vegetable augmentations (cheese, lettuce, pickles, tomatoes, onions, etc.).

Regardless, Product Management, including Marketing, would establish the actual Project requirements based on market and other research, determine the delivery names (should all variants be called a hamburger or should each major variant be given a unique product name), advertising hooks, etc. It is up to the Projects to select components, determine implementation methods, perform Quality testing, ensure requirements are met prior to release, etc.

Summarization
The differences, from an SCM perspective, are that Product Life Cycles consist of a Ramp-up phase, iterations of Project Life Cycles and a final Wrap-up phase. From a broader perspective, a Product is what is intended to be delivered and it is rare that it can be conceptualized and implemented correctly in one pass, so it requires iterations of development, test and release to meet the final goals. There is generally either a single person or a very small team chartered with the responsibility for keeping the big picture in mind at all times so that false starts and rework is kept to a minimum as development progresses.

Overall, a Product’s SDLC should look something like the figure below. Note that the Project iterations are shown overlapping and the final Production run of the Product may extend past the Development life cycle.

Project Life Cycles are where the core of the planning, implementation and testing occur in order to develop a Product. Projects have a reduced scope of requirements to be met and allow iterative Production releases in order to meet market pressures and to satisfy customer expectations. This is especially true when the “final” Product is intended to satisfy the needs of a diverse customer base. Each subsequent Project allows for features to be added to satisfy more and more customer needs as well as to fill in the holes identified by the existing customers.

Projects are what we are most used to thinking of when SDLC is mentioned. This is what most of our tools are intended to help us with. And that’s OK, so long as we never forget that the Product is what earns us our pay, not the Project!

Trackback(0)

TrackBack URI for this entry

Comments (1)

Subscribe to this comment's feed

Robert Cowham said:

... Nice and clear - good article. I prefer to see some form of version control available right at the start because even if you don't have requirements to version, you do have plans and other documents! I have seen many times that documents are the poor relation - get saved on some file share (hopefully), or even worse emailed around - people often not quite sure which version is the master or where Fred's comments went. Then with multiple copies in the same folder, someone sorts them alphabetically and accidentally opens up ProjectPlan-v9.doc instead of ProjectPlan-v10.doc ! Given that most projects don't start in a vacuum, this is the sort of thing that organisations gain huge benefit from having a standard framework (and preferably tools in place) for and have in place from day 1. Robert

report abuse vote down vote up

September 12, 2008
Votes: +0

Write comment