Who Needs a Schedule Anyway?
My photo, Google’s wall, yes a real board room.
Right? At the end of a long line of processes, why is it that we're always responsible for the date and why is it always a panic-driven week at the end? To begin with, we've got a team of Electrical Engineers; power management, signal integrity, memory, more memory, RF - with all of the related sub-functions you can think of, baseband, NFC, WIFI, Bluetooth, GPS, USB, PCIe and so on.
Then, there's the display, the audio, the keyboard, the trackpad, the cameras and random sensors, each with their specialist; and probably a flex too. Ask any of them, and they’ll say that their particular specialty is the one that matters most. Now, we've got the mechanical team with their form/fit/functional needs. Thermal management, battery life, drop tests, in-circuit tests, packaging, connectors and an innate need to make it all beautiful. How are we going to herd all of these cats, these prima donnas, these brilliant engineers who want nothing more than to keep on engineering? It's what we do.
Enter Management. Engineering leads, Project Managers, Program Managers and up a chain of shot callers – each doing a harder job. At the highest levels, they're managing risk from the real Boardroom. Just below that, strategic decisions are made that involve unfathomable amounts of money. Unfathomable. Those decisions are passed down through VPs, Directors and so on until they get to us; the polygon pushers, the Tetris and connect-the-dots experts. Their question: "Why does layout take so long?"
Image credit: Rochester Institute of Technology - typical Gant chart illustrating the timeline of a project
Fair question. About the only way to answer it is to do enough record keeping that you have a knowledge base vast enough to draw on for similar situations. What we want to know is how much time the job will take if nothing goes wrong. If you can predict that 1000 parts are going to take two weeks to place and a month to route, you've got a start.
Just as no two snowflakes are alike, every board is a different deal. It's not a perfect world, and there's never a perfect layout execution. You know that there will be setbacks. You just don't know the exact nature or impact. The Component Engineer might disqualify a part. The Regulatory Engineer may want another shield. The fab shop may not be able to hold a critical tolerance. Something is going to go wrong. So, do we add a 20% fudge factor to the schedule guesses? Maybe even 50%? Nope. None.
Image credit: Universal Pictures - Doc Brown about to send us Back to the Future!
So, every job is going to start out with the idea that nothing will go wrong this time? That's the plan. The folks in the C-suite are counting on you. Actually, we're planning on you doing the best you can to help us hit the "market window" while "managing global expectations" – in calm, rational terms. The ultimate goal is to distill the schedule down to the critical path, setting aside delays for the unforeseen. Comparing an idealized reality to the original expectations will help set more accurate future expectations.
Enter data. No two are exactly alike but, every job has a comparable one, particularly in terms of riding the bleeding edge. Someone else is fighting the same fight you are, and they're not alone either. Co-development is usually the biggest time sink so subtracting out that variable by noting time spent on rework efforts goes a long way towards finding the time spent on the actual design. That's the relevant number even if it's never the way things go. Your clock should only be ticking when you're on task. The rest of the time is ECO time, and one of your coworkers owns that part of the schedule.
Sensible Data Collection, Scaled to the Job Size and Complexity is Paramount.
Sensible means it does not become the process itself but keeps score. Sensible data will help the next person come up to speed, especially if that person is you. Scaled to the job size and complexity means that the number of mileposts scheduled and number of functions tracked should be appropriate for the job. A four-layer, through-hole, low-tech board with nothing to speak of in terms of DFX issues wouldn't need a Lessons Learned package.
Some Jobs will. Some will take months to do and end up using multiple vendors to ensure that you'll get some boards ASAP. Those jobs involve a fair amount of documentation but also some tribal knowledge that should be captured and archived with the rest of the design collateral. The communication between the fab shops–or at least a summary–should be curated and sorted by the vendor then added to the archive. Those DFM waivers and everything that is different between the tape-out and the as-built really should be captured.
That's a lot of data points. That's why the original schedule spreadsheet can have all the extra tabs and links. By cataloging the good, the bad and the ugly, you avoid the last two next time around. You'll learn what works best for your thing. In doing the record keeping, you have a chance to define the goals and orchestrate the inputs from the teams. Being diligent and focussed on who to pull in to get the most out of everyone's time seems obvious. The folks who come in out of turn will just have to get used to the sight of you pulling out your lab book and entering some cold, hard facts.
Pre-scheduling meetings for your major milestones raises awareness. Knowing that the line between placement and routing is both wide and fuzzy helps. Make it a mini-celebration anyway! Someone smarter than me coined the expression, "Failing to plan is tantamount to planning to fail." Now that you have your historical data and your play-by-play of the just-finished process handy, you can explain why and how the project landed the way it did. Or you can wait for the top dawg to decide to outsource. Now, get on there and start filling out that spreadsheet. We're counting on you.
References.
http://edge.rit.edu/edge/P16261/public/Build%20%26%20Test%20Prep