Statement of Work example for a hardware engineering project - Page 1
Forum section: electronics / projects

author: skipbery
author_rank: Newbie
timestamp: June 08, 2017, 03:23:16 pm
content: .

author: AndyC_772
author_rank: Super Contributor
timestamp: June 08, 2017, 04:03:10 pm
content: An observation...If you ask for 'good/better/best' options, then what you'll actually get are:- the way the hardware team genuinely believes represents the optimum trade-off between cost, complexity, time and so on;- a worse way that they've had to come up with in order to fill a box in a matrix, and- an even worse way.Start with your customer's requirements. Invite one or two of your top hardware engineers to meet with the customer, face to face. Let them ask the questions that really matter from an implementation viewpoint, and suggest what *they* think the trade-offs should be.Insisting that they come up with a matrix, which gives the illusion (only) of someone "higher-up" making the decision, is a mistake, IMHO.

author: Siwastaja
author_rank: Super Contributor
timestamp: June 08, 2017, 04:49:40 pm
content: What Andy said, plus:Instead of focusing on the written, formal plan, focus on trying to find the right people, who are skillful enough and work well together, so that their experience and intuition can be trusted. Then let them make the decisions, because they know what they are doing, let them communicate directly with the customer as much as possible, and offer a supportive role so that all this can happen.HW engineers sometimes feel a bit socially awkward around the customer. Any boss can see this issue; a poor boss "solves" it by removing or minimizing the customer-engineer interaction, working in the middle instead, which is often a total catastrophe because the boss does not have the relevant technical skills (even when they think they do!) to ask the right questions and relay the right data. The good boss, on the other hand, is there for both, to make the interactions happen frequently enough so that the engineers can acquire therealcustomer spec, or what the customer actually wants -- which, as you probably know very well, often is totally different from what the customer specifies on paper.This direct communiation process is especially important in HW design, because some customer requirements that reside on the paper due to miscommunication, but are actually unimportant for the customer, end up being eithercompletely impossibleto satisfy, or they may be several orders of magnitude too expensive to provide. In the software world, it's always easier to come up with some quick hack that enables you to tick the "done" box, but with HW design, you want to minimize the uncertainty since there is less iteration in the process.

author: Tomorokoshi
author_rank: Super Contributor
timestamp: June 08, 2017, 05:06:52 pm
content: This is a bit of a hit and run, but if you haven't read these yet they may be useful:"The Mythical Man-Month" by Frederick Brooks, second edition."Peopleware" by DeMarco and Lister, third edition."The Design of Design", also by Frederick Brooks.

author: jbb
author_rank: Super Contributor
timestamp: June 08, 2017, 07:45:50 pm
content: As Andy C and Swiastaja point out, you need to get a HW engineer's input.The fundamental task is to get a good brief which can be turned into a specification. It will take some time - which may not be chargeable to the client. Resist the urge to wing it.As you have probably experienced yourself, seemingly 'minor' changes can wreak havoc. E.g. operating temperatures, file system corruption on unexpected power loss.Additionally, you need to consider surprise timing problems e.g. will some other project steal your engineers? What about holidays? Will Chinese New Year be an issue?