Schedules are better than plans. Just blocking out the time during which you will tackle a task is more important than figuring out how you’re going to do it. We’re going with an assumption that you are motivated and competent. Everything else is logistics and being a quick study on details.
For a large project, you need to have a plan because you have multiple people involved. Even in an Agile setup, you need a project plan. “Agile” isn’t an excuse for no planning or for laziness. However, once that’s set up, it’s too easy to fall into the trap of making plans, to-do lists, and task orders—and find the work has slipped past you.
Whereas, if you are scheduled to work on a task, you will find yourself actually getting it done. For my Calliope build, the only reason I made continuous forward progress was by blocking out time. This meant that I’d always a) post an update on Tuesdays and b) spend some time at my homemade lab bench.
That I always posted at http://Science20.com on Tuesdays meant I had to have something to post about, which gave me an incentive to keep the project moving forward. Forcing myself to be at the lab bench (small as it might be—Figure 7-1) meant the satellite build always progressed.
This wouldn’t have happen if I kept reading things, making plans, strategizing, developing concepts, and similar useful—but not generative—thought work. Night is for thinking, day is for doing.
Many others have built small satellites, but (to my knowledge) always as teams, and frequently as teaching exercises. I am pushing the use of COTS (commercial off-the-shelf) parts, but that too reflects a trend that is increasing in labs everywhere.
In any project, momentum is just as useful as certainty. You build on the stuff you know and, ideally, gather up colleagues or a team so that you can solve problems as the situation gets more complex.
Some might see this as ill-planned, but it’s actually a good process when doing inventive work into unexplored terrain. I’m a a one-person basement music/art project designed to be operational—not just it flew but trying to deliver a useful product to a community.
In short, I have a plan, but the final details are in motion.
This is a good thing. If I had needed every answer, complete and set in stone, before beginning this project, it wouldn’t be novel or cutting-edge. Much of the fun of DIY (do it yourself) is learning to do it.
And as it happens, my approach is similar to the US Army troop leadership procedure. Theirs goes:
- Receive the mission.
- Issue the warning order.
- Make a tentative plan.
- Start necessary movement.
- Reconnoiter.
- Complete the plan.
- Issue the complete order.
- Supervise.
As noted in the book High Altitude Leadership, “The beauty of this system [is that] you don’t complete the plan until you’ve started the necessary movement and reconnoitered the battlefield.”
That said, having checklists of expected and indeed necessary steps from idea to rocket is helpful. The rest of this chapter provides you with the steps needed. You will have to assess how much time each step will take you and your team, given your access to tools and your skill sets.
Keep forward momentum going, and you will succeed.
You should give yourself one to two years to create your picosatellite from concept through to launch. At the same time, the actual build work could be done as quickly as two months, followed by two months of integration and testing. Reconciling these disparate numbers is the purpose of this chapter.
Starting backwards, the build will take just one semester, one summer, three short months or so. However, this step is like the stuffing in an Oreo cookie: it’s the tasty middle surrounded by the rigid cookie frames of your entire project support system.
Put another way, building is easy if you have a clear design, all the parts, a well-stocked workshop, and a chunk of time freed up to do it. To get to that point, you have to do the more unpredictable steps of research, design, team-building, and gear acquisition. After you build, you will have to do programming, integration and testing, and actually shipping your picosatellite to your launch company well in advance of the launch date.
Here is a rough schedule, assuming you are spending 10–20 hours a week on your picosatellite: