(Casandra) When developing a new product or tool, assessing the necessary technologies to bring your desired functionality to life can often feel like a chore. Depending on your product requirements, you may need to research and assess numerous off-the-shelf hardware and/or software solutions to incorporate into the end product. Rightley’s been kind enough to share his process for assessing technology, making this task feel organized and manageable.
So Rightley, your first tip here is to skeletonize a report before getting started. Can you elaborate on this?

(Rightley) Sure, so I think the biggest mistake that a lot of people make after they’ve decided that it’s time to actually jump in is they just get into the research and just start looking probably at the main aspect of the system which isn’t always necessarily a good place to start. So really what you want to do is skeletonize the report thinking about what outcomes do you need to actually assess in the report, what sort of things overall in the system are incorporated, and then lay those out in such a way that it seems more manageable and realizing that there are some interdependencies there and it’s where the actual beginning of your research should start. So laying out the report, skeletonizing the different subsections of all the different hardware, software, technology stacks, operating system sand so on, and putting those out, it not only makes it more manageable but it makes you think about where’s the right place to begin your research

(Casandra) Yeah that definitely does seem to make it more manageable when you break down each section like that versus just thinking of this big task at hand. So, the second tip you shared with me is creating a technology matrix or flow chart. What exactly do you mean by that?

(Rightley) So, along with when you skeletonize it, you’re going to realize, or maybe just after you’ve done a tad bit of research you start getting your feet wet, that a lot of the technologies are going to be interdependent. So when you evaluate one kind of technology you may find that that precludes going down another route later on. What you want to do is when you discover these things is lay them out in a matrix which will show you which things may preclude others. And then also ideally you want to try and lay out the research and the way you investigate things in such a way that you don’t go down a dead end path. So you want to try and start with what might be the deciding factor and then work your way down to the details. To make this concrete, in a more realistic example, if you’re selecting, let’s say you’ve got an application, a bit of software/firmware that’s going to run on a microprocessor, and you’re deciding whether or not go to with an RTOS, a Real-time Operating System, so you may want to look at different RTOSs first before you do the chip selection because what you’ll find is when you’re doing the research into the Real-time Operating Systems some of them may already have nice ports or basically a draft, if you will, of what the basic operating system needs to be for a particular microprocessor. So you don’t want to go and investigate, because there are hundreds of micros out there, you don’t want to go investigate them all and think about which ones may have the right inputs and outputs for your project, before you realize that, oh, well I could’ve maybe narrowed it down to 5-10 choices because I know that I probably want to go with this operating system. So laying things out like that and attacking it in an order that makes sense, could really be helpful and cut down the overall work.

(Casandra) Absolutely, and the third tip here that you shared is to analyze building it vs. buying it. What factors should someone take into account when they’re analyzing each of these scenarios?

(Rightley) After you’ve skeletonized your document and you’re thinking about what the different portions are of the system that you need to be investigating. You always need to ask yourself, when you’re looking at those things, “Do I want to buy something off the shelf that’s already built” – this is more so applicable to software of course, because more hardware you’re going to buy of course. But when you’re looking at the different software options do you want to build it yourself or do you want to go out and get something that’s already available. You’re not necessarily going to be able to answer the question of which one you should do in each instance, but laying out really during the technology assessment, you’re going to want to layout what things can realistically be built as opposed to being bought off the shelf and if there are any options to buy those things off the shelf. And then you’re probably going to have to enlist the help of your engineering team as well to kind of put estimates to at least very general ballparks to the effort associated with building it but you need to actually identify what can be built and what can be bought before you get down that path.

(Casandra) Ok makes sense, and then the 4th tip, you mentioned really taking into account the business aspect of product development, so you named volumes of product, time to market, current resources internally that it would take to do this. Why is this important?

(Rightley) So, this is really important because a lot of projects go down a path of allowing the perfect product to get in the way of actually getting to market. This goes hand-in-hand also with build it vs. buy it. Ideally, in very large volumes over a very long run, if you build everything yourself, and you’re not buying any software, for instance, from any other company, that’s probably going to be, yes, the lowest cost option in high volume over a long period of time. But that may not always be the best option for you because the volumes may not always be there or the time-to-market may not allow for it. So this is where in addition to, as I mentioned before, bringing in those engineering resources, you need to tap the marketing folks to find out when do we actually need to be to market in order to capture the market share that we’re looking for and try and work that backward into a timeline so you can really do a better evaluation of the whole build it versus buy it portion. As well, look at those volumes and any sort of license agreements and per piece costs that go along with any pieces that you may be buying and incorporating into your product, you need to also of course take those into account. So the main thing is you really try to by the end, strike a good balance, and it’s never going to be perfect, but a reasonable balance that allows you to get to market, with a reasonable bill of materials cost in a reasonable amount of time. So that’s where you really need to think about the business aspects, because as I may have mentioned, engineering doesn’t take place in a vacuum. Everything is trying to get a product out the door and if you lose site of that you could end up working on something that never makes it to fruition.

(Casandra) Sure, and the very last tip that you shared, and I know that I often neglect to do this. You said don’t be afraid to pick up the phone. I think that’s huge. How can we benefit from a simple call versus say just emailing for support or using the support chat on a website?

(Rightley) Yeah, even emailing support and the support chat are still steps beyond what a lot of folks, being an engineer myself, that you kind of have to get yourself out of your shell and realize that there are other people on the other end of the line and if you just call them up, tell them what you’re doing. Tell them you’re doing a technology assessment, you’re looking at a couple of different options, you noticed their RTOS or their software stack, or their thing, whatever it is that you have to be interested in during your research, just talk to them. You never know what you’re going to learn by actually talking to another human being. Obviously their job is to try and sell you something, but they’re also there generally, they want to tell you about their product they want to tell you what it does and how it can save you time. And you will often learn things that you didn’t expect to just by picking up the phone and talking to these folks because they may also have a lot of things coming down the pike that aren’t necessarily on their website yet or they might have support options that are not readily available or advertised on their page. So when you talk to them you can kind of get a better feel for what’s really what it would be like to go with their option. Furthermore sometimes when you get people on the phone you can get a little more than the best pricing that may be on their website. Or if you explain what you’re looking at they may have another option that’s not necessarily listed and it could really change your pricing. Because a lot of times the pricing and information you see on their website are for 1 piece, 2 piece, bare minimum quantities, if you talk to someone and tell them what you’re thinking they can tell you where the price breaks are can give you a more realistic idea for your actual application. Again, don’t be afraid to pick up the phone and talk to somebody, you never know what you might learn.

(Casandra) You never know what you can learn from a conversation.

(Rightley) Yes, and it doesn’t cost anything, just a little bit of time.

(Casandra) So I’m seeing here that you have a bonus here, a bonus tip. And you just said, prepare for the unexpected.

(Rightley) Yeah, so this is also, don’t think of this technology assessment you’re doing as a finalized piece of information. Once you’re done with this, things are going to come up. There are going to be unrealized or unknowns that pop up that might mean you have to include another piece of software another piece of hardware. Something else may come up that you just didn’t anticipate and there’s always those market demands that come out of left field, you know, partially through, or once you’ve started the project. So, don’t think of your research as a once and done endeavor, think of it as a living document, it gives you something to go back to, it gives you a place to put those contacts that you may have made, or those little tidbits of information that you might have to go back and revisit. And sometimes you have to dig a little deeper, add a section to it, but never expect that once you’re done an evaluation that you won’t go back and touch it anymore, it should be a knowledge base or resource that you can go back to. So that’s really the biggest thing about expecting the unexpected.

(Casandra) And I think also, something that just came to mind was, this document, you have this document, it might be for a specific product, or a specific project, but I’m sure that you can use this information in future projects, or in future builds down the line. So really being thorough about it initially can really save time later on.

(Rightley) Absolutely, so as you’ll probably find as you do product development. Very rarely is one product completely different then the last, and even if it is, for a completely different purpose a lot of the underlying technologies are still there. So as fast as technology may change, software and real-time operating systems, and stacks for protocols and what not are slowly evolving so the research you do now is still probably going to be relevant it might just need to be retouched in a year or two or a couple months down the road. So keep a hold of these things after you do them, they could be useful like you said.

(Casandra) Absolutely. So, tanks Rightley for your time and sharing these 5 tips on performing a technology assessment. For those of you viewing this video, we hope you found this helpful, I certainly found this helpful. If you have any questions or if we can be of assistance, please don’t hesitate to contact PSI.