Category Archives: Project Management

A Letter to Start-Ups on Technical Development

Lower your Development Costs by as much as 50%

There is a perfection in getting your product into the marketplace as soon as possible so that it can evolve organically rather than waiting for it to achieve perfection.

Dear Start-Up:

Get to a “Minimum Viable Product” as quickly as possible. Whether your “product” is hardware, software, a combination of the two, or some kind of service, not only will you save money, the sooner you get something operating that people can use, the faster they will be able to provide you with useful insight, and the sooner you will have opportunities to refine and, in some cases, redefine you approach. Do not fear mistakes and false starts, as you will get past them and into a position of having happy customers and growing your new customer base.

As its name suggests, a Minimum Viable Product, or “MVP,” has just enough features and functionality to be useful. The bells and whistles can come later, once you have the core product well defined. As easy as this sounds, you may be hard pressed to find a true minimum set of features because you might second guess yourself by thinking that this or that feature, by not being included, could handicap the critical initial release and prevent it from being accepted.

But moving right to a MVP does not mean you start coding today. There is an important planning step that can save you from a tremendous amount of grief and possible failure. This step is the writing of a good technical product specification that will help you decide on the minimum set of features so that your MVP is developed as quickly and as close to your vision as possible.

Listen up: Do not skip this step, even if you think your MVP is not “rocket science.” It may not be, but it is often your young company’s first technical cornerstone, setting forth its basic system architecture and, as such, it needs to provide a strong foundation for what is to come.

Why you Need a Specification

Chances are good that you will need outside developers. If one of your founders is a developer, he’ll probably be too busy with other start-up related issues to be able to dedicate enough of his time to managing all of the development. Besides, if your product is to get out in a timely fashion, it may need more short-term talent … so it’s time to call in some professional developers.

As developers prepare quotations for you, they will ask you for a number of technical items to help them gauge the effort, to neither overshoot nor undershoot your requirements. Examples of such items are technical write-ups, screenshots, mock ups, demonstration videos, sample code, proof-of-concepts, “lab curiosities,” the technical section of your business plan, to name a few typical items which are, by the way, best provided or shown under a non-disclosure agreement. Be mindful of not delivering materials that are focused only in one area, such as the end-user experience, because they may not provide enough detail by themselves to cover the full range of your MVP’s features and functions.

Developers are at their best they receive a high quality technical product development specification against which they can then provide exacting quotations. Besides serving other purposes such as helping you to intelligently determine the MVP’s feature set and establishing your budget, this specification becomes a technical document that liaises between you and your developers. It tells them in no uncertain terms what the product will look like, how it will behave, and what “under the hood” considerations need to be made. It eliminates guesswork on the part of the technicians and programmers. It prevents unpleasant surprises during the course of development when, for example, you and your developer suddenly realize there has been a difference in assumption on some aspect of the product; to resolve this now apparent and unfortunately discrepancy, the development path has to change, the deployment delayed, and the budget revised higher.

Please don’t think that a product specification will take long. We’ve done them in as quickly as a few days and certainly not longer than a few weeks for more complicated projects. Depending on the kind of product or service, a typical specification runs from between 10 and 50 pages. During the writing of the specification, several important issues usually come to light that are best addressed before development is actually begun. These issues are not necessarily technical; they can be related to the business model, customer requirements, and government regulation, among many other factors.

Also, do not think of the time to have a specification prepared as being “lost.” The clarity that the specification will bring to the table will actually allow your product to be developed more quickly overall. Also, some degree of technical research and development work is performed during the preparation of a technical specification, much of which finds its way into the final MVP. Occasionally, there may be multiple technological approaches that need to be evaluated in light of the project’s desired goals. All in all, this engineering-driven specification process with some built-in R&D has the effect of significantly lowering your overall development costs, in our experience by as much as 50%.

Some questions may come to mind…

What will my specification look like? What will it contain? It will be a comprehensive report having, among other things, every feature, every function and every user interface screen of your MVP defined. It has sections of standards, guidance, goals, assumptions, checklists and definitions. it covers all of the MVP’s functional requirements, and some non-functional requirements as well. It deals not only with the software layers but also with what hardware will be used, even if it’s cloud-based, and how it is configured, made secure and has built-in redundancy and backups. It will incorporate your business intelligence, philosophy, personality and value proposition. To the extent of relevance, it will identify vendors, manufacturing processes, and intellectual property considerations. It will contain a proposed development schedule along with an estimated budget.

What does a specification do for me? With proper care, your specification evolves into a “living” guide for the technical side of your business. It becomes an important asset of your company, thereby increasing the value of your company. It can be leveraged to add significant value to your business plan and to your patent filings, and it also becomes a cornerstone for your trade secrets. It can be used to solicit exacting quotations from not only the technical advisory firm who may have helped you develop the specification in the first place but also from a number of other competing firms as well if you so choose.

Should I pay for the specification? Shouldn’t developers do it as part of their quote? Most developers provide free quotes when given a reasonably good specification of what it is they are being asked to do. In lieu of their receiving enough technical material, developers may suggest that you have a technical specification prepared as the very next step. You can do that yourselves or have a qualified engineering team do it for you. Since your MVP’s specification is custom work which has no market other than you, and since it will increase the valuation of your young company, the developers are entitled to just compensation for this preliminary effort. Also, the adage, “you get what you pay for” is very applicable here — you want a solid, engineering document upon which your future can rely. You really do not need a bare bones, short-term “punch list” that will be essentially obsolete a few changes later.

Once you have a properly designed specification for the MVP, your project manager can “shop it around” for maximum cost savings without giving up much in the way of quality. You may choose to break it up into sections so as to help minimize the exposure of your intellectual property and trade secrets. Once one or more developers have been engaged, your project manager will then monitor the project’s progress, providing you with updates and flagging any important issues that need your attention.

As part of the technology strategy consulting that DataPlex provides, our engineers can develop your product specification, act as your project manager, and undertake key portions or possibly all of the technical development to ensure that trade-offs are properly considered and your MVP is developed quickly and to your liking. We can help you develop “customer profiles” and “use cases” that serve to bring closer the real-world to your product’s development. Feel free to contact us to find out how in your particular case we may be best able to help.

The Advantages and Pitfalls of Updating Old Electronic Designs

What is an Old Design?

By “old,” we mean systems that were designed more than a generation of technology ago. “Generations of technology” are usually indicated when the class of the components are superseded by a new one. Here are some examples:

  • Microprocessor controlled hardware replacing hard-wired circuits. (There are many advantages for doing so; the resulting design is often less expensive and more flexible.)
  • Digital analog to digital converters (ADCs) and digital to analog converters (DACs) replacing analog circuits. (Typically, a microcontroller site between ADCs and DACs to provide digital processing of the digital version of the signals.)
  • HCT Series CMOS superseding LS Series TTL for driver and interface circuits. (CMOS has faster switching, lower power and can be made smaller.)

A particular hardware circuit is comprised by different sections, and each section may be different numbers of generations old, so a weighted analysis can be used to explore trade-offs of a design upgrade.

For lack of any other measure, an electronic design can be considered old if it is more than ten years old. The electronics industry as a whole advances quickly, and few electronic components are used in the same way ten years later.

One useful question to ponder: If a qualified engineer were to design a circuit today for the same application, how would it be different? The answer helps to point us in the right direction. A new electronics design will utilize parts that are currently available and have a complete yet cost effective feature set. If the design were to be significantly different, then that is a strong argument for not perpetuating the approach of old design, although.

That said, an engineer might still choose to perpetuate an old design based on economic, compatibility and political factors. He may wish to use up existing supplies of old parts, or continue to provide products which meet with customer expectations. Something more technically modernbut significantly different may be perceived by customers as inferior or undesirable. Other technical reasons relate to support and repair and intellectual property issues.

How an Old Design is Updated – The Nine Step Process

Once the decision is made to update an old design, the update process is straightforward. Here is the general process we use at DataPlex:

Step 1
Locate or Develop a Specification of the Current Design

If it was not the first step to break inertia, this should be the easiest step. Old manuals and product datasheets are often useful references.

Step 2
Identify the Key Features of the Current Design

A bit more challenging, identifying key features requires an understanding of the products and, not only how it is used by customers, but also how is it not used. Features that are under-utilized but require significant ongoing support may need to be dropped.

Step 3
Develop a List of New Features, Ordered by Priority and Usefulness

Probably the most difficult step, choosing which features remain and what new features need to be developed has to take into account what are the expectations of the marketplace and weigh them against the up-front engineering expense, the per-unit production cost, and what alternatives provides and what competitors are doing.

Step 4
Research Components and Design Approaches

The design team researches components and explores overall design approaches that seem to optimize between cost, reliability, serviceability and an appropriate feature set. For economic and development schedule reasons, not all features will make the cut (hence the need to order them).

Step 5
Begin Design Approaches

Begin to develop in a top-down approach several different designs to see how then begin to flow. Often one design will leap ahead of the rest as a better or less expensive way. Pick it as the primary design.

Step 6
Review the Designs

Explore the designs with management and (very important) also with key customers to see how well their feature sets fit with their actual needs and requirements.

Step 7
Iterate the Design

At this point, a design team may iterate back to an earlier step should, with management and customer feedback, it become obvious that none of the design alternative sufficiently meet expectations.

Step 8
Start the Primary Design Phase

Once a design seems to be acceptable, the actual primary design phase begins. While it may feel as though the actual design work is a long time in coming, actually most of the difficult decisions have already been made, the complete function set is known, and it is just a matter of implementation. Backup designs can also be begun now or held off for a later time. Also, the design team should work with management to prepare contingency plans should something go wrong.

Step 9
Don’t be Afraid to Go Back

While the main design phase is underway, should any new information indicate that the results may not meet expectations, management should decide which earlier steps should be reviewed to make the necessary adjustments to bring the design back in line. In some occasions, an alternate design replaces the originally preferred design based on the new information. Within reason, it is much better to take some extra time to develop a product that is right for the marketplace rather than push throw with one that is known to be inferior.

When the Design is Complete

When the design is complete, we move on to prototyping and testing.

What Can Go Wrong?

Updating an old electronics design is still an electronics design process and can derail for any number of reasons. For updating a design, a design team must be sure to meet the important targets of feature set, backwards compatibility, production rates, delivery schedule and price points.

It is especially important to get one or more prototypes ready as soon as possible so that the targets can be evaluated by different groups such as management and key customers. These prototypes can also be used for showing to potential customers and demonstrating trade shows while production ramps up. At all times, be vigilant for discrepancies between the prototype and the marketplace’s expectations and acceptance and review Step 9 if necessary.

Should something go wrong — say, production doesn’t ramp up quickly enough to meet the delivery schedule – there is no need to panic. Management should have already developed contingencies such as using more expensive vendors but ones that can fill in the production schedule as necessary.

One area that is particular debilitating is so vast that is deserves its own section…

Intellectual Property Legal Issues

While we do not practice law or offer legal advice, this article would not be complete without a discussion about intellectual property, both developing it and being sure not to step on others.

If it comes to your attention that you are stepping on someone’s intellectual property, you might see what it will take to license it. If the patent assignee’s (owner) is not a direct competitor, you should find a warm reception since you will potentially be providing a new revenue stream.

Or, if you think the updated design improves on the current state-of-the-art for the product class in a novel and unobvious way, you might explore applying for a patent. We won’t tell you that patents are easy — they are not, but should you get one, you will have a government sanctioned monopoly on the invention disclosed in the patent for close to 20 years, hindering competitors and providing a cash flow from licensing.

Note Well: There are ongoing changes to both domestic and international patent law, and you need to be informed about the precise process you will have to follow. For example, as of this writing, a United States invention must have its patent filed before it is first offered for sale lest it jeopardizes its international validity.

In any case, should you feel that you are in such an industry or have a product that requires or steps on intellectual property, gather your design team and consult your patent lawyer.

What to Do if You Have an Old Design

Please consider DataPlex as your one-stop design team. Our products can be found in many different industries and chances our experience staff and proprietary design tools can get you a redesign in quick order. Also, with our being technical and having been successful in written what are now issued patents, we can help you document any new inventiveness so that you can more readily apply for intellectual property.

For more information, please visit:

Maintaining High Reliability for New Electronic Designs Intended for Harsh Environments

Volume 3, Number 2

The Issues of Harsh Environments

Designing a piece of electronic hardware such that it works reliably from the get-go is a challenge, especially if it has to work outdoors or in extreme environments where temperature, humidity, vibration and radiation are the enemies of electronics.

Unfortunately, while a growing number of new electronic designs are destined to be used outdoors, the art of designing for harsh environments is not typically part of an engineering school’s curriculum. As a result, most engineers make the erroneous assumption that designing for a harsh environment is very much like designing for hospitable one but with a greater emphasis on testing and improving the design empirically, addressing the observed failure modes. Although this approach is certainly along the recommended path, it should not be the only extra consideration; otherwise, the deployment could fail.

What is a Harsh Environment?

A quick definition of a harsh environment would be anywhere not “indoors,” although this definition is incomplete. Any condition of extremes relative to the human condition applies, so that includes temperature, humidity, atmosphere (including pressure), radiation and shock, whether indoors or not. While one can easy to see that sitting outside at the south pole with minus 50 degrees winds blowing at 80% humidity easily meets the requirement, it isn’t readily apparent to him that a handheld device that could be dropped five feet also meets the requirement.

A simple test is asking the question, “if this device were a human being (scaled up or down as appropriate) and subjected to the conditions of its environment — the highest and lowest temperatures, the amount of pressure, or amount of shock, would it be expected to survive?” A cellphone operates in a harsh environment, indoors, because it can be dropped, and the amount of force it can hit a tile floor would be terminal to an appropriately scaled human being. (It often is to the cellphone too depending on the height of the drop and the quality of its design.)

The Engineering Approach

Addressing the harsh environment begins before the design phase, in the R&D phase. Knowing that the design includes a harsh environment, an engineer sets the research parameters and, later, the product specifications accordingly. Paramount of concern to him are meeting the minimum and maximum storage and operating condition limits.

To maintain high-reliability for a new design, the engineering approach must:

  • list the extreme storage and operating conditions
  • set the design specifications accordingly
  • select components that meet the specifications and reject others
  • be mindful of circuit board physics, e.g. trace lengths, component mounting methods
  • explore conformal coating and heating and cooling elements, as appropriate
  • ensure that the fabrication drawing is consistent with the harsh environment design
  • select appropriate mounting hardware, cabling and enclosure
  • test the sensor inputs and software over the complete range of operating conditions

“Testing over the complete range of operating conditions” is easy to write, but could be very difficult in actual practice, owing to the exponential increase of possibilities over an increasing number of parameters and ranges. We have found that Monte Carlo Simulation and linear programming are two very useful aids for analyzing the effects of different parameter combinations.

Post-Design & Post-Installation

No design for harsh environment is complete without a plan for follow-up during the implementation or deployment phase. A well-designed circuit may allow additional or alternative components to allow for tweaking the final design after production. For example, in one DataPlex design, a standard delay line circuit slowed down so much in cold temperature that an alternate delay circuit was automatically switched in, and the switch point was controlled by a variable resistance that could be easily changed in the field.

Software is Affected Too

It may not be obvious at all, but software can be affected by harsh environments as well. We are thinking here less of the actual computing hardware that runs the software — that is still covered by the hardware related issues discussed above — and more of the way that the software has been designed and tested in a warm, cozy lab. Software that received sensor data such as values from analog to digital converters (ADCs) may find itself attempting to deal with extreme values that it did not encounter in the lab, and that usually leads to bugs and possible failure.

Taming Harshness

In this article, we explored the nature of harsh environments, what constitutes a quality engineering approach to design a piece of gear for those environments, and the importance of follow-up in order to make adjustments and preempt out-of-spec operation or catastrophic failures.

If you have a requirement for a harsh environment design, we invite you to consider the experience of DataPlex’s staff with difficult environmental conditions and how our refined approach to R&D and engineering can mitigate certain risks for brand-new designs. Please contact us to discuss your project.

For more information, please visit:

DataPlex Complete Feasibility Studies

DataPlex completed two technical feasibility studies for digital entertainment media clients centered around the current landscape of digital media streaming services. DataPlex has a finely-tuned process for conducting comprehensive research and delivering exceptionally accurate reports to clients considering new businesses or products.

DataPlex Implements Web Database for Charitable Organization

DataPlex project managed and implemented a full-scale web database for tracking a charitable organization’s membership and activities. The charity’s executives can securely access the database through standard HTML pages anywhere in the world, and instantly download filtered lists to Microsoft Office products including Word and Excel.The database is implemented using MySQL, the server-based language is PHP, the client-based language is JavaScript, and the HTML pages are sources from templates that are maintained directly by the charity’s staff.