![Figure 1: The two sequences for the autocorrelation of x0[n] and x0[n].](https://www.wavewalkerdsp.com/wp-content/uploads/wordpress-popular-posts/5515-featured-125x100.png)
Table of Contents
Introduction
You have been assigned a product delivery on a too-short of a deadline.
Let’s make it harder and say you just got promoted to the project lead and have a couple of junior engineers working for you. You have to build a schedule, allocate people to different tasks, report your progress to your leadership and your customer and get everything synchronized so it comes together successfully at the end.
Let’s add more.
The success of the project has implications to your career and reputation, as well as your organization. Your success may have implications to the profitability or success of your company. All eyes are on you.
Are you feeling uncomfortable yet? I know I am.
A strategy is needed to think about how to deliver a product under these conditions to keep yourself and your team emotionally centered and moving forward.
The strategy I use is called reverse engineering your product delivery plan.
More blogs on engineering mindset:
Painful Product Delivery
Here is how I’ve reacted poorly in the past when delivering products on tight time constraints:
- There’s not enough time to plan! I’m going to work as hard as I can immediately and then burn out at an important moment.
- I’m overwhelmed technically. I’ll work on my little part and not be concerned about the operation of the greater system.
- This project is too complex with too many moving parts. Hopefully someone will explain this whole thing to me one day.
- I don’t want to do this project. I’m not going to motivate myself. I’m doing the minimum every day and hope no one notices.
Ever felt like this?
You can deliver a product in painful ways but you are going to be miserable and the product is going to suffer. The best way to get through it is to lean into the problem and work through it. That first starts with a plan.
Working Backwards From the Product Delivery
Chess Grandmaster Maurice Ashley has a great talk on the value of “retrograde analysis”, or working backwards, to solve problems. We will use that same strategy to plan out the delivery of a product.
Here are some questions you need to ask yourself before starting out:
- When is the delivery date?
- What is the budget?
- What features does it need to have?
- How big or small, light or heavy can it be?
- How many do you need to make?
These don’t need to be exact, you just have to have a feel for them. Some of these may have been answered for you by your customer or your leadership.
Answered them? Great! You’ve defined the goal, let’s work backwards to see how to get there.
Emergency Reserve Time
FEMA suggests you create a preparedness kit of food, water, a flashlight and other items in case emergency. Once you have a problem it’s probably too late to get to the store to buy what you need, possibly assemble it, familiarize yourself with it and then use it. So you have to prepare ahead of time for an unforeseen emergency own the line.
Consider an example where you have 24 weeks (6 months) to deliver your product. Immediately slice 25% off the top to act as emergency time. You now have 24 weeks * 0.75 = 18 weeks (4.5 months) to build and deliver the product. You need to prepare for one or more of these problems:
- Underestimation of time needed to develop product*
- Underestimation of time needed to test product*
- Technical risk (a new algorithm didn’t work, design flaw wasn’t caught early enough in the process, final design doesn’t meet spec)*
- Supplier delays (supply chain problems, late deliveries, lost or delayed packages)*
- Parts out of stock*
- Weather (snow, hurricanes)
- Power outages
- Internet outages*
- Equipment or computer failures (blue screen of death, software versioning incompatibility, software license expiration)
- Human accidents (important tool dropped and broken, PCB killed due to static electricity, lost components, antenna bent)
- People taking vacations (including you)*
- Sick days (including sick kids and family members)
- Loss of efficiency over time due to tiredness, burn out*
- Team members leaving your project
- Sub-contractor team members leave, or sub goes out of business*
- Family emergencies
- Car problems*
- Pandemics*
- Government Shutdowns
- Literally any problem you can think of, and many others you can’t
(* Problems I personally have dealt with when delivering products.)
A larger team and longer time frame will mean dealing with one or more of these problems. Murphy’s law states they will happen at the most inopportune time.
Now that you have 25% less time to deliver, do you need to rework what’s practical for delivery in a shorted time frame? Take another look at the feature list you have before moving on.
System Dependency List
Consider you are going to design and deliver a bicycle. The bicycle is a series of systems that interact with one another. The drive train rotates the wheels and the wheels and drive train are mounted to the chassis.
You’ve now identified three systems: drive train, wheels, chassis. All three need to be completed, assembled and tested before delivery. Continue to work backwards by breaking down the systems sub-systems. In this example the systems are broken down into two levels although you may need to do additional levels depending on the complexity of your product.
The drive train is a metal chain connected to the cogset and chain rings. The wheels have a rubber tread, an inflatable tube and metal spokes. The chassis has a frame, seat, handlebars, pedals, forks and the mounting hardware for the wheels and drive train.
The system dependency list for the delivery of the product is now defined:
- Bicycle
- Drive Train
- Metal Chain
- Cogset
- Chain Rings
- Wheels
- Rubber Tread
- Inflatable Tube
- Metal Spokes
- Chassis
- Frame
- Seat
- Handlebars
- Pedals
- Forks
- Mounting Hardware
- Drive Train
Build or Buy
We’ve identified the sub-systems and their components. Which will you build and which will you buy? There’s an old saying,
any system can have 3 qualities but you only get to choose 2: low cost, high quality, or delivered quickly.
Here are some considerations ask you determine whether to build or buy:
- Cost
- Is it cheaper to build or buy?
- Do you have any parts you have already purchased at your lab that you can use?
- Consider you may need to account for overhead costs for employee time (vacation, health care, 401k) as well as time for support staff (office administration, organizational leadership and technical director costs, and logistics) in addition to your engineering cost.
- When buying you will need to consider sales tax, shipping costs and unforeseen expenses (cabling, necessary hardware add-ons or software licenses, support contracts, hidden fees). Be aware that large shipments or one-day deliveries can be exceptionally expensive!
- Time:
- Do you have enough time to build the system?
- Is your time better spent elsewhere?
- Is it faster to buy the product or build it yourself? How much faster?
- If you buy, do you have enough time to understand how to use it?
- Quality:
- Do you have the proper talent to build the system?
- How confident are you (realistically) that you can complete the system on budget and on time?
By now we’ve determined the date and cost of our delivery, created some emergency reserve time, broken down the product to sub-systems and determined which sub-systems will be bought and which will be created by your team. Now it is time to put it to a schedule.
Development Schedule
Continue working backwards to plan out the development schedule. You need to give the product to your customer, which means you will have to package the system. Software will need to be installed and hardware physically placed into a box. The user will need documentation that will describe how the product is used.
Before delivery you will want to do a final product test. In order to test the product you will need to assemble the systems. Returning to the bicycle example, before a test ride the drive train, wheels and chassis will have to be completed and assembled. Before assembly the systems themselves need to be created (or bought) and tested individually. The sub-systems of rubber tread, inflatable tube and metal spokes need to each be individually inspected and tested, and then assembled into the system of the wheel. Which sub-system is going to take the longest to build, or which will have the longest time to deliver? Continue working backwards until the system dependency list has been built out.
Working backwards, assign preliminary dates to each of the objectives. Based on the delivery date, when does the final test and packaging need to occur? Based on the final test date, when does the system need to be assembled? Based on the final assembly date, when do the sub-systems need be completed by? Based on when the sub-systems need to be completed, when do parts need to be ordered? The following list provides an example of how dates are added to the system dependency list.
- Bicycle: Delivery Date July 1
- Packaging: June 25
- Final Test: June 20
- Final Assembly: June 15
- Completed Documentation: June 13
- Drive Train: Completed June 1
- Metal Chain
- Test: May 30
- Documentation: May 28
- Inspection and Familiarization: May 15
- Delivery: May 1
- Submit Purchase Order: February 1
- Cogset: Completed May 18
- Test: May 15
- Documentation: May 12
- Fabricate: May 1 – May 10
- Design: April 1 – April 25
- Material Delivery: March 25
- Order Materials: January 15
- Chain Rings: Completed May 5
- Test: May 1
- Documentation: April 20
- Fabricate: April 1 – April 15
- Design: March 1 – March 20
- Material Delivery: Feb 15
- Order Materials: January 1
- Metal Chain
Does the schedule work? Can the delivery date be met? Be considerate of constraints such as weekends and holidays. Also avoid having one person work two different tasks on a single day (things always take longer than you expect). You may need to reallocate time to meet your delivery date, revisit your feature list or whether you are going to build or or buy sub-systems in order to make your schedule work.
Time for Testing
Your supervisor and customer is going to expect you to have a schedule with a block of time to develop and a block of time after to test. In reality testing is done as you develop. You’ll test functions and then groups of functions. Components of sub-systems will be tested and then assembled and the united tested as whole. Testing time is insurance, it’s another form of emergency reserve time in your schedule. Nothing will work completely correct the first time around and that is OK because you have testing time built into your schedule. You need more time to test than you think so you may want to add another 20% additional time than you originally allocated for your testing.
Make Another Pass Over the Delivery Plan
Everything in the delivery plan has been decided and scheduled. Is it coherent? Run through the delivery plan again and make sure nothing was overlooked. Are the sub-systems finished in the proper order? Can you get crucial parts ordered and delivered in time? Do you have some slack in your schedule? Have someone else double check your plan. Sleep on it for a night.
Conclusion
You’ve been assigned a large, complex product to develop and deliver for an important customer that can have substantial career and financial implications. You’re going to need a plan to be successful.
Reverse engineering your delivery plan is an effective strategy for thinking through all of the dependencies and risks in a project to make sure everything comes together at the end. Keep in mind that you’re going to need some emergency reserve time so you have a way to recover when something goes wrong. You’ll want to break down your product into systems and identify which will be built or bought. Working backwards in your schedule will allow you to allocate time based on the system dependency list. Remember, no schedule is perfect the first time around so you may need to cycle back through the process once or twice.
Check out part 2, Execute Your Delivery Plan!
More blogs on engineering mindset: