subscribe: Daily Newsletter

 

Software projects versus software products

0 comments

When building software solutions, whether internally or outsourced, much of the focus is often on enforcing budget and deadlines, or on risks, such as choosing and implementing the right methodologies, technologies and platforms. Included in this list of pitfalls is a topic that does not get as much airtime as it deserves: understanding the differences between developing a software project and developing a software product, says Matthew Butler, GM at Entelect Software.

At Entelect it is apparent that awareness of the differences between these two concepts needs to be promoted, mainly because the mind-set and approach required for each are different, and using the wrong combination means guaranteed friction and/or an engagement failure that could have been avoided.

It is very important to note that software solutions do not need to be polarised into either the project or product category. Each solution or engagement falls into the spectrum somewhere between the ‘quick and dirty’ project and the full-blown product.

With this in mind, let’s first look at some of generally understood differences, which most project managers or product owners will already know:

* Audience: Projects will generally have a more specific, internal functionality set, tailored to a certain audience, such as one department or one customer. It is not a stretch to stereotype projects as customer-specific software. Products need to leverage broader functionality for often a larger and/or external audience.
* Delivery: A project typically needs to provide only a specific set of deliverables. Examples could include a workflow system customised to a business process, or a new online capture form for customer feedback. A product must provide a viable solution for ongoing business, which is likely to include preparation and planning for the product life cycle: growth, adaptation, enhancement and decline from the software development perspective. Good examples of this include Salesforce.com and the Uber mobile apps.
* Time: Projects should be time-limited while products generally have a roadmap, but only loosely defined timelines upfront.
* Return: Projects will often have an indirect return on investment through efficiencies gained, load reduction on teams, reduced operational or staff requirements and so forth. Products typically need to have a direct return on investment in such a way that, over a period of time, the product generates direct revenue to pay for its own development and enhancement.
* Development: Projects are often outsourced as contained pieces of work. Products are not usually outsourced, especially not for core business IP or competency.

Added to this list, there are other important differences that are not as well understood and can at times be overlooked:
* Users: Projects regularly have a focused feature set and a controlled set of users. Control in this case means you know specifically who the users are (often they might have no choice but to use the software as part of their work). At the very least, you can chat to them and get direct feedback. Software products often need a large user base to be successful and this can impact many other decisions during the development process – we will see this influence coming through in the points below.
* Quality: As a consequence of a larger, and less-controlled, user base, products need to prioritise quality. For any product, things such as first impressions, performance and user experience are critical for adoption and brand value. Another aspect is longevity. Code quality is crucial for products because should the product be successful in the marketplace, existing source code will need to be worked on for the foreseeable future. However, this is not to say that quality does not matter in a project, but it is less important.
* Technology: When developing a software project for a specific customer, generally technology choices are constrained to what tools and platforms are already in place. With product development, often the best and latest tools and technologies are needed to give the product the best chance it has in the marketplace.
* Architecture: There is an industry-wide buzz around building ‘software as a service’ (SaaS) systems. Although the topic is beyond the scope of this article, the point is that architecture must suit the intended usage of the solution. Large products will require broad, and sometimes complex, infrastructure to allow for things such as multi-tenants, data partitioning, high availability, elastic resources and shared caching. Projects tend to be more predictable.
* Adaptability: Software products (think Microsoft Office, or Eclipse IDE) have demands from multiple customers, so they need to adapt to varying customer requirements both now and in the future. This requirement is far more muted for projects.
* Testing: With a project, ‘just good enough’ will more often than not suffice for the intended purpose. However, as a consequence of the user base, products require the accommodation of more hardware and software configurations.
* Investment: It is probably clear now from the differences tabled so far that building custom software products is expensive. More time is required for planning and executing a good software product solution that caters for the variability, quality, testing, user breadth, and the other product features mentioned, and time is the key cost factor for software development.

At Entelect, we like to use a set of questions to help stimulate the thought process to guide the project/product owner to an understanding of where on the spectrum their solution lies:
* Is it for your company (internal system), or is it for users whom you would consider customers?
* Do you want to make a direct income from the solution?
* At the moment, are there any users of the system that you do not yet know of?
* Is there a market demand for your system – would anybody else want to use it? If so, would you expect them to use it as-is or would you need to tailor it?
* Does the solution represent a ‘core competency’ – would this software solution be the key revenue driver for the business?
* Does the system need to be highly adaptable?

If you are answering ‘yes’ to these questions, it means the solution leans more to the product side and answering ‘no’ pushes it more to the project side. This really is a key point to establish as early as possible in process. With this positioning known, the next steps will feel more natural for the topics above. You can proceed with more confidence with your technology roadmaps, scoping, test planning, competitor analysis, project vision, architecting and budgeting.

Successful projects and products start with positioning the solution or idea on the project-product spectrum and then tackling all of the topics raised (particularly approach, budget and timelines) in a way that is tailored to that position. Ultimately, when building software, and especially when looking to outsource, knowing whether you are building a project or a product is a great head start for setting expectations, vision and driving decisions.