Over the years we have directly and indirectly participated in every aspect of product development and support. These products have included software, hardware, consumer-oriented, business-oriented, small (semi-conductor chip) and large (steam turbines). We are a big proponents of standards and the production of high quality and supportable products. Successful project completion is not driven by how many people you apply or how much money you spend, it is who you apply and how they are applied, that ultimately determines the final results. The following is a partial list of areas that we might be able to help you with in your product development and support effort.

Product Requirements

Product requirements should reflect the needs of the market and your target customers, and not be a justification using the latest technology. While it is relatively easy to develop a new state-of-the-art solution, it is much more difficult to develop a solution for your key customers and have them use it day in and day out.

Whether you are developing products in-house, in another division or through a third party, you need written product requirements. The more complete they are (not necessarily formal), the more likely you will be to develop and receive the desired product. Product requirements should identify the high-risk development and support areas before any real development begins. They should help determine how much it will cost, and how long it will take to develop your product. Finally, product requirements should help define the product acceptance tests, and provide guidelines for your quality assurance testing.

Project Planning & Management

Who is going to do what when? How long is each task going to take? What are the dependencies between tasks? What is the impact if a problem occurs, or a deadline is missed? What is the benefit if you apply more resources to several tasks, shortening the time for completion?

For large, multi-person projects, project management is crucial to the success of the development effort. With it, you maintain visibility into the development process. You can anticipate problems before they happen, and more rapidly resolve and minimize the impact when they do happen.

Systems Engineering / Product Architecture

A picture is worth a thousand words.

Every product (or service) that involves multiple components should have one or more diagrams that identify the key components and how they work with one another. If the product involves complex information flows, then dataflow diagrams should also be included. If there are complex timing dependencies, then there should be timing diagrams as well. If there are external system dependencies, then all of these external interfaces need to be defined and all dependencies clearly identified. Finally, if the product will work with a human, then the key elements of that man-machine interface should be described.

Everyone who is involved with the product in some fashion, should be able to understand the product architecture, even if they don't have a technical background. The architecture should describe what the product will do and how it will generally operate. Lay person reviews many times detect critical oversights and omissions before the product is even designed.

Product Design

Product design is basically functional decomposition. Each product component needs to be decomposed into its key parts. The function and its interface needs to be designed and documented. With the completion of the design and a successful design review, most, if not all, unknowns with regards to building the product should have been removed.

Product Implementation & Support

While we have developed many different types of products from stand-alone to client/server, web based, and agent-based over the years in a variety of programming languages, we primarily provide advice these days on how to set-up development teams, how, when and where to effectively use standards, and how to set-up efficient development tools and processes. The size and the experience of the development team, and the nature of the product being developed greatly influences the specific advice that we provide.

Product Documentation

There are many different types of manuals, such as user, training, installation, support, test and development. Depending on the product and its intended audience, you may not require any manuals, or you need some or all of them. Each type of manual needs to be carefully written for its intended audience. Each should be reviewed and periodically updated to include the latest information to meet the current needs to its audience. The format of each manual should follow the standards that its intended audience has become accustomed to.

Over the years, we have created all types of manuals for many different products. We can help you layout your manual(s), organize them or even write them if necessary. If you do outsource your manuals, it is critical that the outsourced technical writers and editors work closely with your developers and the intended manual audience.

Product Review/Assessment

How often are you holding program or development reviews? They serve two purposes. First, they enable you to keep track of what is going on. You know whether the program is on schedule and on budget. And, if not, you have an opportunity to make the necessary corrections. Second, they enable you motivate and reward the development team for the progress that they have made to date. A properly motivated team will develop a more reliable product, faster and cheaper than an unmotivated team.

We have participated in and performed many program reviews over the years. We typically identify a number of small adjustments that improve the development process, increase product reliability and further motivate the developers.

24 x 7 (ASP/Internal) Service

Providing 24 x 7 service and support with a high degree of reliability is not easy to do. The more dependencies you have on different third-parties components and services, the more challenging it is. Consider that the standard internet and telephone connection is not 100% reliable and everything else is less reliable, it becomes a very interesting problem to solve. For low bandwidth centers, the solutions are fairly simple with redundant, automatic fail-over systems, but high, bursty bandwidth centers are a different problem altogether. We have worked on and solved both.

System and Network Monitoring (Nagios)

Over the years we have developed proficiencies in many different areas. System and network monitoring is one of those that we have developed out of necessity. When working with Amblit Technologies, they had a need for monitoring their ASP and web based systems. After exploring all of the available options, we discovered that Nagios, a Unix based open source solution, provided an extremely cost effective solution for them. Nagios could be configured to monitor all of the key hardware and software components throughout their multiple networks, both from within and outside of their firewalls. Today, their system runs automatically, sending notifications to the appropriate parties whenever systems or components need to be serviced and /or repaired.

With our successful implementation for Amblit Technologies, we have subsequently implemented Nagios for our own systems support. We now also endorse this solution and are a registered Nagios partner.

We can quickly, and inexpensively implement this monitoring system on any size network with all of the basic operating system types (e.g., Microsoft, Unix/Linux, Apple).