Embedded design projects: Challenging what the client wants
If client is king, how far should you go to respect that mantra, and at what cost to the end product?
An inherent part of embedded development is dealing with clients, their expectations, needs and quirks. It can be an enjoyable part of the job when things run smoothly and you are able to build positive relationships.
But whether you are in the initial stages of an embedded design project, or in the thick of the development phase, client input does have the potential to wreak havoc with the project plan and, crucially, its output.
Clients are difficult to find. You have done well to get as far as winning a project, so when the client starts to go off plan in any way, in the interests of the product, your reputation and professional integrity, you have to handle it well.
In our experience…
As embedded software engineers, we often work with hardware designed for a specific purpose by our clients.
Sometimes we can see that the hardware design is not hugely sympathetic to software. This means the software design would be overly complex, making it harder to develop and maintain. The result would be lower performance, or in rare instances, the hardware design simply would not achieve the overall system requirements.
In these situations we have a duty to our client to point out the potential problems and suggest improvements to the hardware design.
That can be an awkward conversation, particularly if the design has been stable for some time. The keys to making this a success are focusing on engineering objectives rather than sometimes personal, vested interests.
Re-spinning a hardware design will of course incur costs for design, lay-out, PCB production and testing. As engineers our job is to balance those against the cost savings due to simpler, smaller, and more easily maintained software.
Other benefits, such as improved performance and reliability, may be harder to quantify before making a hardware change, but can be quite powerful arguments for a re-spin if they are backed by sensible estimates or technical rationale.
In short, this comes down to having an adult discussion with the client, stating our opinions clearly but in a nurturing manner, and ensuring that all points of view are respected in the final decision.
If you are facing potential difficulties with challenging client demands, we recommend the following approach.
Take a breath!
Start by trying not to react too hastily, either way. Take a step back, and consider if the client is actually wrong. We are in the solutions business, so it is important to avoid an outright dismissal by considering what is being proposed.
Try to understand where the idea/request/change has come from. What is the business or technical driver behind what the client is asking for?
The nature of the client demand and wider project circumstances will influence how you decide to proceed. And when you get to the crux of what is being asked, it will enable you to make a professional and informed evaluation, be that agreeing with the client, or suggesting alternatives, or asserting the original plan.
For example, the request may be due to a change in lead personnel on the client side, or input from other client departments. In these scenarios, avoid becoming piggy in the middle. Convene an all-party discussion to arrive at a consensus and re-focus the project.
Make your case
If you are resolute that the client’s request is not in the best interest of the project, as the professional you should make your case.
Trouble-shooting and problem solving go hand in hand with embedded development projects, so take these instances as opportunities to showcase your abilities in offering solutions.
Be positive, respond with confidence and show your credibility. Use data, mock-ups, first hand experience and other reputable sources to back up your point.
Remain solutions-orientated, avoid being defensive or negative. You want your client to see the value you are bringing to the project.
Conceding
If you face strong persistence, and it feels like a deal-breaker, you may have little choice than to concede.
In which case, again remaining professional, be open and clear about your opinion on the impact this course of action will have on the project and its outcome – delayed launch, increased susceptibility to bugs etc etc – and ask that the client to sign off on this.
Then do your best to work with the changes.
It would only be in extreme situations where you would consider walking away. And often this is as a result of the mounting cost of excessive changes on a fixed fee project, rather than the merit of a specific change. But even then, by following the above steps, you can be certain that you have exhausted all avenues open to you.
How to avoid difficulties arising
Problems will always occur in embedded projects. The sheer complexity of the technologies involved and the highly specialist skills required play out against the client’s commercial pressures.
It should go without saying that before any development project, it’s crucial to obtain certain information to help you learn more about the project. And once you take on a project, you need to know as much as possible about it so you can hit the ground running.
But it is typically the case that even with a rock solid brief, changes will be required as the project proceeds. Your processes should allow for change requests to be managed, and the client should be made aware of these processes and what they should do as part of it. For example, assigning changes to versions or releases acts as a helpful framework. Your code methodologies should also enable changeable parts, and it is worth investing in configurability.
Communication with the client is also critical. Agree who it is you are liaising with, and when and how they want to be communicated with. Stick to it. Keep them informed.
This will also manifest in the management of the project itself through for example agile methodologies and frequent mini releases.
Regular client contact may to some sound onerous, or seem to be inviting client input, but this will enable issues or queries or ideas to be raised at the earliest possible junctures – and handled accordingly.
Regular contact can also minimise the likelihood of surprises arising, and in instances where you do push back, the client will be more aware of progress and context to understand your reasoning.
Conclusion
The harsh reality is, without clients you have no work. How you respond to client demands has considerable implications for your future – your reputation, your portfolio and your future commissions from this and other clients.
It is a difficult balance to achieve – keeping the client happy, while ensuring success of the final project output, and keeping your integrity intact.
But ultimately, the happiest client is the client with a successful output. You are the professional, so present your professional case. And while you can’t win them all, isn’t taking opportunities to add value and innovate through problem solving and technical solutions what embedded development is all about?
