When you work on a project, inevitably there will be times when something goes wrong. Usually this isn’t a big deal; as I said, problems are pretty much inevitable in any sufficiently complex system. Sometimes however they can indicate deeper issues that may affect your project in unanticipated ways. Here are some of the things we look out for in projects, and how we’ve dealt with them.
Project constraints can be a major source of problems. Sometimes they can even look quite innocent to start with. For example, several projects I have worked on had to fit into cases with predetermined dimensions. In a few instances we identified very early in the project that the cases were small enough to cause issues, fed that back to our clients, and agreed with them on a resolution. If you don’t catch this sort of thing early, you can find problems snowballing; your board runs hot because of the lack of space, so you add cooling systems which eat into the space available. To fit into the even smaller space you use more expensive components with smaller footprints, and before you know it your build cost has ballooned and the board still runs hotter than you would like. That’s an extreme example, but it emphasises how important it is to examine constraints right from the start of the design process.
Of course even the most brilliant designers aren’t infallible. Unanticipated problems can (and usually will) show up at the most inconvenient times. In one project, a third-party software component we had been asked to use suddenly sprouted a need for 1Mb of buffer space. Since the processor in that device only had 1Mb RAM total, this left the client with the choice of dropping the (highly desired) software component or redesigning the project from scratch. We did look at some possible mitigations, but the likely costs in components and code complexity ruled them out. A change this big is quite rare, but never assume it can’t happen to you!
The big red flag, of course, is feature creep. The most terrifying words any project manager can hear are “Can we just…?” (There is no such thing as a trivial change, so the only technically correct answer to such a question is “No.” Questions beginning “Can we…?” are of course entirely different.) If you are getting a lot of new feature requests and they are getting hard to fend off, perhaps it’s time to consider whether you are building the right product. If your marketing people argue convincingly that your product must have a particular feature to get anywhere in the marketplace, you should take a long, hard look at the consequences. If extra hardware is needed, will it fit on the existing PCB and what’s the cost of re-laying it out? If extra software is needed, can it be added without taking a machete to the existing design? How much longer is it going to take you to get to market? How much pain are you letting yourself in for in terms of maintenance? You may well decide that it’s better to get to market now without the feature and add it later (possibly through an entirely different project) rather than wait the extra time for the feature to be designed, implemented and tested.
You may have noticed that the common thread in all of the above is communication. Whenever something crops up that seriously affects the costs or timescale of a project, we consider it part of our job to understand the problem and potential solutions, and communicate the situation back to the client. The absolute worst thing we could do would be to leave our clients with unrealistic expectations; we want them to be able to make informed decisions, and they can’t do that without information. Most of the time we will be presenting a way forward — often several — and the choice for the client is a matter of the best fit to their business plan.
True showstoppers, issues that call the viability of a project into question, are incredibly rare. Even issues of the sort of seriousness we have talked about above are uncommon. 99% of unexpected problems get solved by engineers as part of day-to-day development. When you come across the 1%, however, it is absolutely essential that you communicate.