Posts Tagged ‘development’

New Product Introduction

Thursday, March 25th, 2010

New inventions, evolutions of existing products, or perhaps just a different package of a “same ol’” — there are important steps to then developing the product and eventually releasing into the market.

There is not much difference there between a (becoming) Start-Up or an established company: You will make a determination whether the new product makes sense pursuing; or, looking from the other angle, can we allow not to bring out the new product.

The  “Idea” will be analyzed and its potential for success examined; and important questions such as “what does it take” and “what does it cost” need answers.

Business Plan

The feasibility of said idea will be outlined, and the three basic areas addressed:

  • Who is your customer?
  • What appeals them?
  • How will they get the product?

A Business Plan would includes an Overview of the industry of the company and Trends with Market and Competitive analysis; a Mission Statement; then Management, Marketing, Finance, Operating plans.

Once the “go ahead” is achieved, the next step follows.

Market or Product Requirements Document

Product marketing provides the description of the new product, its purpose, the features, the target market and the customers,and the opportunities, comparing against older versions (if any) and competing products, pricing and position, strengths and weaknesses.

The product may be part of a roadmap, embracing trends and new technologies as they will become available.  The MRD or PRD will  specify goals, delivery dates, system and technical requirements, compliance, documentation, quality and testing, support, and perhaps planned life-cycle.

Following the holistic approach, development teams (hardware engineering, software engineering, technical publications, quality, etc.) perhaps key suppliers and partners, and customer sales and service, are included in the very early stages to ensure the document is sound and specifications and goals and contingencies clearly understood and agreed upon in one pass.

Project Plan

Depending on the type and complexity of the product, whether it is a brand-new product or one that just got a bit revised, will determine the amount of preparations involved until start of the project.

A detail plan is then drafted to list the efforts required and the resources needed, the anticipated costs involved and the complete time line.  A variety of tasks and subtasks are then identified with specific owners, priorities, efforts and resources and duration, inter-dependencies to other tasks highlighted, and such.

There can be also situations or events that will need to be included as well:  Availability of certain rooms, machinery or equipment, awaiting Compliance Certifications, etc.   Engineers working on various products may be “over-booked”; so conscious decisions re priority and affected tasks to coordinate  among various products or projects are necessary.

Once the various pieces are compiled together, all or at least most of the resource requirements and prerequisites known, cost estimates are calculated.  Questions to answer are:

  • Can we do it?
  • Everyone on board?
  • Does it still makes sense?

If the answers are satisfactory, and the price tag is below the, well, “walk away” limit, the product development can continue.

Design Document

Each task requires a clear scope, precise specifications, a functional design where applicable, interfaces need to be listed and defined.  Where one task is dependent of others, the hand-off parameters and the expectations have to be exactly spelled out.

The more detail (and thought!) is going into the design, the less problems will arise during development.  A simple misunderstanding or a potential situation not considered early on and caught in initial stages, can have severe consequences if detected only very late and the repair turns out to be rather complex.

Of course, the design is a “living thing”, it may have inaccuracies, or requirements were revised due to economic or technological changes, or a detail may become more time consumptive than planned.  There is consequently continuous feedback from development to design (and product marketing) teams.

Quality & Test and other teams (documentation, training, service) are involved in early stages so that they prepare appropriately and are ready for the new product to come.  An elaborate test plan will be authored to spell out the tasks and procedures that are run to ensure the developed product is in fact the one described in the design.  Manufacturing and sales and support teams (and the customers) will require product manuals and training courses.  Perhaps an older products is being phased out, so migration plans to the next product have to be outlined.

Development Stage

To shorten the overall cycle time, bigger tasks (say, those taking longer than two or three months) are carefully split into smaller, ideally independent tasks.  That way, the various teams (documentation, development, quality & test, operations, etc.) can work in parallel, rather awaiting full completion of the bigger tasks in their individual phases.  Potential problems may arise where smaller, already completed tasks need to be revisited or perhaps even redone, due to discoveries or findings from subsequent tasks…

In each hand-off (from one team to the other), a checklist of the planned / accomplished (sub)tasks, with a updated action items chart.  Program management drives the product development, monitors and communicates status of each task with the teams and stakeholders, ensures deliverables are fulfilled and milestones achieved — in time and on budget.

.
(to be continued)

.

© March 2010 Jürgen Menge, San José

go-esdc!

Tuesday, March 16th, 2010

Early March I visited the Enterprise Software Development Conference in San Mateo.  This is more an intimate expo with some 25 booths.  Though well visited, you still found time to discuss with the reps their products and offerings in great detail.

I must confess, I have a more academic interest there, still looking for the solution that kept me nagging when working for Mobile Information Systems (Offering real-time solutions for the time-sensitive, same-day transportation industry) — now an entity of Oracle — in year 2000.  Something that I was so used to when I had worked with Unisys in the System Software development in one of my former lives…

Software Releases

As products evolve over time new versions are designed and developed and will become available to the market.  These can be (labeled) completely new software products and customers can choose to pay for the upgrade.  And new revisions or support packages are provided to the user to update their existing software to the most recent level.

Companies release new software products to provide new functionality (aka, features)  to their users, to support new hardware components and devices, to improve usability, to tighten security, and — naturally — make use of the ever increasing resources in processor, memory, disk space, etc.

Using the software you may encounter incidents where the product does not do what it is supposed to do.  That can be a subtlety where, say, the output is not properly aligned.  Or more drastically, where the input is not processed correctly.  And that can range to more serious problems of security leaks or data loss, if not the abort of the application or even the underlying operating system.  Software releases are, therefore, also the vehicle to distribute a list of bug fixes or corrections to said problems.

As nature of things go — after all, computers are only human, too! ;) —, a new release may not only be the latest and greatest thing, it can also introduce new problems.  Perhaps some hardware component or software function not supported anymore.  Or new bugs frustrating the user.

There are a variety of reasons a user does not want to move to a new main release and expects that recent releases still to be supported.  Consequently, companies maintain several main and support releases, replicating development and addressing incidents and providing patches to the given “dot” release.  Eventually, older releases are phased out and their support will cease.

Release Streams

Main releases, as mentioned before, introduce new functionality and are intended to advance the company in a competitive market, increase share and revenue stream.  Likewise, said company needs to ensure their products are “bug free”; even if it means to continuously provide resources and fix incidents over the life of the product.

A company will, therefore, enjoy a variety of software releases.  A few main releases with various support or patch releases.  A software product usually consists of a variety of individual pieces, programs, drivers, user interfaces, messages, reports, libraries, third party components, and what not.  All these parts comprise — are controlled through — the release stream.  And perhaps there are also special software packages with different set of features, supporting specific hardware components, etc.

And while plans are executed to phase out older releases, there are already the future releases and schedules on the drawing board: specifications are laid-out and defined for the new product to be.  Functional and detail design are written, and eventual resources are planned and assigned for the development, documentation, test, etc.

Good strategy is to introduce new (major) functionality only in main releases = new products, whereas support or patch releases (branched off from the underlying main release) are more the vehicle to further stabilize the release with well-defined sets of software or product fixes.  (L10N and I18N also comes to mind.)

Software Development Suites record each individual modification to the software components, Software Life-Cycle and Change Management tools help to keep overall track.  The Task database on the other hand is the repository containing incidents reported and feature requests against given releases, severity and priority, detail description or specification, current task status and updates, department and engineer assigned, etc.

While certain problems can be more readily detected during the normal use of the product (the goal of the quality assurance team, naturally, should be to find said problems before the user installs the product!), others, however, may not be obvious to the end-user.  Either, the problem does not occur in the specific environment of the user; or, it may be some security exploit, the user would not even notice.  Whatever the nature, chances are that the incident could occur not just in one but in other releases as well.

Consequently, each software release stream is then reviewed and determination made, whether a fix will need to be replicated — or perhaps newly developed —, based on the problem at hand and the prerequisites and requirements of the given release stream.

Software Quality

While the software developer working on a new feature or creating a fix for a reported incident is doing the due-diligent to ensure the software change is doing what it is supposed to do (and there may also additional code reviews), based on the design or the description of the incident, it is later the software quality team’s task to put the final stamp of “passed!”.

Of course, the patches are not tested as soon they become available, rather, the defined collection of such software features and fixes are included in a formal release cut-off process and then handed over to the software quality team.  The interval of such cut-off can be weekly, monthly, daily; whatever makes most sense in the current situation.

The software quality takes the handed-off release stream and deploys the product on their prepared environment, what can be a fresh install or an update.  Part of the hand-off are release notes, updates of the task database linking the features and fixes to one or more changes in software and/or documentation.

A set of test runs are started (automated or manual) confirming the working of the feature or fix (Conformance testing) while assuring that no new incidents were introduced (Regression testing).  The tests and the results are carefully documented following the key principles: a test shall be repeatable, the results reproducible, and the test environment reliable.

There may be situation that a patch or a series of patches need to be pulled (and updating the task database, hopefully, setting task status appropriately), perhaps due to product stability concerns.  Software engineering is then addressing concerns based on the documentation provided.  Once software quality puts there “QA stamp” on the given release, that release is then ready to proceed to the next phase; e.g., handing over to professional services to customer deployment, publishing on web site for download, etc.

Release Readiness

Closing in on the scheduled release date, the software team re-evaluates the planned and prioritized features and fixes against those that are available and have passed testing.  Questions to answer are: Is the release process on target?  If not, what is missing and what would it take?  Are the missing pieces requirement for the target release?  What are the consequences if the schedule were to slip?  Would it make sense to get the product out as it and publish a revision soon after?

There can be different approaches to tackle these problems (and I may elaborate further in a separate blog).

Whatever the outcome, eventually the product is signed off and ready to go.  Let’s celebrate!   :)

And the next releases are already in the making…

.

(to be continued)

.

©  March 2010 Jürgen Menge, San José