Is your CFO running your project?

Consumer device innovation seems to happen at a brutal pace day by day. Take one of the most recent examples of a new gadget, the Samsung Memoir Digital Camera Phone, which again pushes the envelope of usability and connectivity.

If you have product responsibilities for consumer devices and you present your 2010 holiday season product vision, hwoever chances are that your CFO does not really care today. Your well thought out ideas and plans, which three months ago seemed to be close to getting started, now seem to be in the very distant future.

Welcome to the cost-driven economy! Short-term returns, low-risk projects, predictable success, lower growth at much lower expenses. Is your CFO making the product design decisions for you?

The reality is yes! The CFO makes that call. Your CFO looks at your historic product development costs. He or she will see a “cost cone,” starting with little investment in product research, sometimes called pre-development, followed by huge chunks of money once a product becomes committed to detailed chip design and software application development.

Even worse, the history of design projects will show a fair amount of false starts or late redesign requirements, which either kill the revenue or blow up the cost, or both. The only way your CFO is going to get the cost under control is to allow less of these expensive development projects.

If you have only one silver bullet for your 2010 product line, what should it be? Are you specifying a more conservative product because you don’t think engineering will be able to handle the higher risk with the more ambitious product specification? Are you sandbagging your performance margins as an engineering manager because you don’t know if you can squeeze it out of your back-end design process with acceptable risk? Regardless of which side you are on, the cost-driven economy puts you in a big decision dilemma.

Fortunately, you can turn to your software and hardware architect experts. Really? Embrace yourself for a big “maybe” about the product performance. Are you planning to integrate a hot new piece of software or hardware IP into your platform? Will it differentiate your product like you expect?

How much overrun in schedule (and cost) will it cause you because it’s difficult to get it to work in your new platform? The more you discuss your plan, the more questions pop up, and you have not even started implementing anything. The hardware team is already knocking at your door with the need to get started. Meanwhile, the software team keeps on polishing their software for a platform that’s unknown!

In a cost-driven economy, you can choose to keep on doing what you have been doing. Nobody will complain, because taking the same approach is considered as not taking a risk. Unfortunately, you realize that continuing in the same old fashion is actually very high risk, but at least you can not be blamed for it.

The choice to change
Or, you make the choice to change – to change now, because of the cost-driven economy, not in spite of it. Because of the cost pressure, you decide to make an extra investment of time and money which is spent up front in your design process. You do this because you are convinced that more effort spent in the early stages of a design will generate fewer headaches down the line in the detailed implementation of hardware and software.

What are you going to invest in? First, you want to get mileage from your existing IP investment. With modern IP blocks containing hundreds of parameters, and your specification including dozens of applications and use cases, it is imperative to study the performance of your architecture in a systematic way, specifically under the influence of dynamic workloads. You don’t want architects to model dynamic behavior of your architecture with adhoc methods.

You prefer a reliable, repeatable approach, which is as solid as your favorite RTL-to-GDSII design flow. You want a server farm exploring your architecture performance by doing massive amounts of scenario simulations and automated analyses of the results from these simulations.

After you are done with your architectural decisions, you can launch your RTL implementation team, but what about the software team? Can you afford to have them not working on your new project while they wait for RTL in an emulator or an FPGA to become available? Again, it is up to you to invest into a new methodology to save project costs and reduce risk through schedule acceleration.

Let some of those hardware architects work with the software team to quickly come up with a first, high-level model of the new architecture. Equipped with a systematic modeling methodology and with IP models from your IP vendors that fit into a standards-based modeling approach, your team will be able to bring up a virtual hardware platform in less than a month. This is enough to get the software team started with driver development for operating system porting.

By the time you are 6 months into the project, you not only have a solid hardware architecture that you know and that will deliver the performance you expect, you also have a number of software applications running on your virtual platform models. Equipped with a solid spec and demonstrable software applications, it will be much easier for you to win that design socket.

When this cost-driven economy picks up again, you will be ahead of your competitors, not only because your project is ahead of theirs but because you have made an investment that secures your continued competitive edge. In a cost-driven economy, you can take the lead in design cost reduction–and win. Your CFO will thank you for that.