Systems Engineering in the Entrepreneurial Space Industry

If any of you have ever worked in a "garage works" type aerospace startup (and I hope you have because it's an eye-opening experience!) you will have been exposed to a staple of entrepreneurial, rapid engineering development which I like to call "design by email". Small groups of smart minds generally don't like being slowed down in expressing their creativity by formal design processes - and neither should they. One of the key reasons that entrepreneurial aerospace has gotten a leg up on the establishment is this ability for nimble, creative, and rapid development. The company culture within these small and highly productive aerospace companies - who have now become the new hope of the Obama space policy initiative - prides itself on getting things done quickly and at lower cost than the establishment ever could. In the entrepreneurial mindset, the term "system engineering" is a dirty word; it describes a way of doing things that is overly burdened by formal processes; dominated by endless meetings with configuration control committees, attended by suits who blabber on about "six sigma this" and "house of quality that" and wouldn't know lefty-loosy/righty-tighty if you shoved a screwdriver right up their collective you-know-whats.

It's fun being the underdog, and cultivating this in-your-face attitude of showing the big boys how to do it right makes your work that much more enjoyable. However, as a startup becomes increasingly successful and grows the size of its technology team, this approach will start to show its limitations. Engineers who get 100+ emails a day will read the ones important to them, which aren't necessarily those important to overall project success. Even worse, as there is no centralized technical interface for your customer to interact with, the technical team gets increasingly bombarded with requests for information by the customer, slowing them down in their important design work and often returning inconsistent messages ("yes, our payload interface can deal with a 5% increase in payload mass" vs. "current vehicle performance projections will allow for a 3% growth in payload"). Once an aerospace organization reaches this point, a critical transition is about to take place. The challenge is to overcome the existing bias against systems engineering (there's that dirty word again), and introduce an effective yet lightweight set of processes, which will meet the team's needs without killing that innovative edge and agility that has served them so well to get here in the first place.

The first step in that process is to clearly identify the problems faced by the team on a daily basis, and make it clear how judicially implemented systems engineering could improve the situation. The term "systems engineering" can mean very different things to different people. For a small startup trying to overcome the growing pains of transitioning to the mainstream, systems engineering generally has two dominant functions: (1) aligning the work across all contributors in the technical team, and (2) successfully capturing and communicating customer input. Once you've succeeded in bringing an understanding to the team that systems engineering will reduce their overhead burden and let them get back to what they like best (focusing on technical development), the battle is pretty much won. From here on, you just have to deliver on that promise, and focus your implementation of systems engineering tools and practices very precisely on their specific identified needs.

So let's talk specifics then; implementing some new systems engineering process usually implies introducing a specialized tool - while "systems engineering by spreadsheet" is possible, it won't get you much further than "design by email". In a small startup where cost is an issue and technical team members are quickly turned off by "enterprise level" solutions, I look first and foremost to Free Open Source Software (FOSS) solutions. Not only is the cost and time to implementation attractive, but any aerospace engineer agile enough to thrive in an entrepreneurial startup will have enough IT skills to tweak the code until the it works exactly the way you want. The first function your team will ache for is distributed / configuration controlled file access. When you work with a team of eccentric individualists, who put in hours at any time day or night and at any location from private boats to coffee shops, a web based document management system is pretty much your only choice. Rather than going with Microsoft's behemoth (and expensive) Sharepoint services, consider excellent free offerings like Owl Intranet Knowledgebase (http://owl.anytimecomm.com/). No VPN needed, but SSL security and unlimited growth with a minimal Linux based server hardware are strong selling points.

To achieve the functions of "team alignment" and "customer input capture" you'll need a requirements management tool. When choosing your tool, the most important rule is to select a tool that accommodates how you want to work, not a tool that forces you to accommodate how it works. Aerospace industry mainstays such as IBM's Rational DOORS software are not only ridiculously expensive, but have evolved over many years to cater to their largest clients - using exactly the kind of overly formal practices you are trying to avoid. Instead, consider web interface driven tools which evolved from the people who know software best (the software development industry). Jama Software's Contour tool (http://www.jamasoftware.com/) is my first choice, exceptionally capable at enabling a team of engineers to stay in synch, while also giving your customer real-time insight into how their input drives your efforts. It acts as the direly needed inbox-filter for teams suffering from "design by email" without placing any extra levels of bureaucracy between the technical team and the result of their labor. In addition, it is highly flexible to your way of doing things, and all but guarantees that no customer input will ever fall through the cracks again.

Having made the transition from "garage-works" to "company" a couple of times myself, I've learned that the biggest success factor is acceptance by the technical team. Choosing your tools carefully, and implementing systems engineering practices in a sparse incremental fashion will make all the difference between project success vs. open revolt and subsequent mission failure.