Some project management philosophies | General | Forum

With all the talk going on recently about the need for extensive project management, I wanted to offer some ideas on management approaches which I think are better suited to our size and general methodology.

I think we should seriously consider looking at something like the agile software development philosophy for inspiration.  Admittedly we are doing much more than software work here, but plans for physical hardware are, before construction actually begins, much like software in that they are quite malleable.

In particular, agile software's focus on being able to adapt to regularly changing customer requirements might be be considered as a way to help us adapt to changing engineering requirements – changing not because the actual nature of the project changes but because another set of requirements is locked down.

The ultimate aim of our management techniques should be to avoid getting in the way of and artificially slowing down actual engineering.  The exception to this should be for for things where requirements really are serious business, e.g. atmospheric reentry from orbital velocities or higher.  With things like temperature, acceleration, vibration etc. tolerances for OHKLA avionics, the simple fact that many other teams before us have stuck relatively generic consumer hardware on rocket projects without apparent problems suggests that most things will probably be able to handle the conditions involved and, while we should certainly check things as we go, it is not like we need to first come up a complete list of requirements and choose our hardware very carefully.  It would be different if only 10% of consumer electronics items were up to the task so we had to carefully consider our options, but I think it is more likely that 90%+ will be fit for our purposes.

I feel like the following entry from the Armadillo Aerospace FAQ is extremely relevant here:

How is your approach to building rockets different from government space programs?
We approach rocket design much like software design – build many different incremental designs that we can test constantly and work out all the kinks as we go. Build, test, fix, then test again.

Following a typical Big Aerospace design approach would be like programming a software design for months or years without ever being able to compile and test your code. And then getting only one chance to let 'er rip, crossing your fingers and hoping all your mountains of paper studies will pay off and nothing will go wrong the first time out. NASA has shown that such an approach can work, but at such great cost and time that a great many of its projects never move beyond the paper study stage. We'd rather actually fly everything we design, and see in the real world what works and what doesn't, so we can build off that first-hand experience on future designs.

Obviously there are some things where "Build, test, fix, then test again" can't work due to expense, but there are places where it will work, and where it will I think that in those cases we should absolutely do it.  We are trying to be simple and innovative here, we don't want to fall into the established habits of big bureaucracies where we can avoid it.

I think coming up with some kind of system based around fairly independent, self-managed teams which have a central meeting or report every month or something, with the understanding that the most active members in each team keep an eye on what the other teams are doing by virtue of these monthly centralisations, and make sure things are progressing in harmony, might be a good move for now.

I am absolutely not suggesting we take the "Cowboy coding" approach.  As you would have seen, Agile development is often confused with Cowboy coding but is actually different.  I agree there should be some structure, not a free-for-all, I just don't want too much, stifling structure.

I realise that requirements themselves will not change per se, what I meant (and I admit I was not very clear) is the requirements will "change" when new, static requirements are discovered (e.g. somebody finally figures out what our maximum temperature for OHKLA will be).