Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Software engineering - crash programs - literature on managing them?

Options
  • 21-02-2014 8:56pm
    #1
    fergalr
    Registered Users Posts: 1,922 ✭✭✭


    Sometimes when I read general technology history, e.g. on wikipedia, I come across references to engineering 'crash programs' - where people had to do a large scale engineering project, in a hurry.

    Examples might be a military context, or a cold war context - something like the Apollo program, or the Manhattan Project come to mind. But I often come across mentions of smaller crash projects too. I also have to imagine that when, say, Microsoft sold IBM a DOS they didn't actually have, they worked pretty fast to build it.

    I'd love to read a series of case studies on how people did the engineering and project management of projects like this.

    They've got to have learned a lot about working on very aggressive sciencey/researchy engineering projects.
    Ideally, someone would have written a great book of case studies about how to manage such projects.
    I've never come across anything like that, though; possibly because of the nature of those projects.

    So, its kind of a long shot - but anyone got any ideas? Good reading recommendations?
    Does my question make sense?
    (Decided to put this question up here, seeing there's a bit of discussion on software engineering on the Perfect Design thread)


Comments

  • Options
    #2
    rock22
    Registered Users Posts: 1,547 ✭✭✭rock22


    A lot of management of large project owe a lot to military logistics.. operations research followed on from that and is see a a discipline of mathematics.

    Not sure if you are only interested in software project management or if your query is more general. But there should be a lot of information on the internet on project management.


    For what it's worth, I think Apollo would have been managed very much in a military style.

    I am not really sure what you mean by "crash program". The examples you gave were planned over many years. Do you contingency planning.?


  • Options
    #3
    fergalr
    Registered Users Posts: 1,922 ✭✭✭fergalr


    rock22 wrote: »
    I am not really sure what you mean by "crash program". The examples you gave were planned over many years. Do you contingency planning.?

    By 'crash program' Im trying to refer to projects where they got a lot done in a very limited amount of time - often by throwing resources at it - but often by being single-minded about achieving the objective.

    I'm particularly interested in projects that had a large research component.


    I recently did a PhD. Its very hard to project manage research projects, as there is so much uncertainly in what's even possible - its really hard to make good estimates for components of the project.

    As a result, I think its fair to say, that in CS in academia in general, people don't really bother with project management (and largely don't know much about how to do it.) Nothing is scheduled, things just happen whenever they happen; e.g. PhDs frequently take twice the median time, or don't complete.


    There's an extent to which this is due to the fundamental uncertainty in the domain.

    However, big crash projects, where they were trying to make huge advances in short times, and trying to do both research and development on a timeline, (e.g. moonshot by end of decade) must have dealt with this sort of issue in detail.

    I'd love to know what they've learned.


    There's also a perceived wisdom in software that there's a limit to how much you can scale projects (i.e. the mythical man month law). But these large projects must have experience dealing with that.

    I know they run over budget and burn huge resources, but still.

    rock22 wrote: »
    A lot of management of large project owe a lot to military logistics.. operations research followed on from that and is see a a discipline of mathematics.

    I'm fairly enough with these basics, and know a bit about whats in operations research; I understand structuring your project as a dependency graph, doing topological sort, doing your critical path analysis, etc.

    I understand reasoning about components of the scheduling using estimated distributions to finishing time, rather than just point estimates; and being able to use this to estimate overall percentile finishing time estimates etc.

    rock22 wrote: »
    Not sure if you are only interested in software project management or if your query is more general. But there should be a lot of information on the internet on project management.

    My motivation is mainly for software, but I'm interested in projects in general as a means to this.

    I'm interested in the process of managing challenging R&D projects, and what people learned about how to accelerate them.
    rock22 wrote: »
    For what it's worth, I think Apollo would have been managed very much in a military style.
    Maybe I need to look for a book on how the military does large scale project management (if such exists).


  • Options
    #4
    amen
    Registered Users Posts: 2,781 ✭✭✭amen


    It all depends by what you mean crash project.

    There are instances of new aeroplanes being designed, built and flowm in less than 60 days in WW11.

    In these cases the general principals of flight were known so while one team might work on the design another would work on materials another on engines etc.

    In the case of the moon landing while it was a crash program is was implemented in steps such rocket launch, first orbit of earth, first space walk, first moon orbit etc.

    Of course the program was also run in parallel such that as the rocket was designed say to carry a 2 ton capsule and tested with a 2 ton weight the actual capsule team had yet to design the capsule. But that was ok as long as it didn't exceed the 2 ton limit. Same with space suits, food etc

    Design in parallel within criteria and integrate at the end of course time needs to be build into the schedule for integration :-)

    If you have just completed a PhD do you have any stats on the completion time for PhDs for those who have previously worked vs those who enter a PhD straight from under grad?


  • Options
    #5
    Sparks
    Registered Users Posts: 40,038 ✭✭✭✭Sparks


    fergalr wrote: »
    I also have to imagine that when, say, Microsoft sold IBM a DOS they didn't actually have, they worked pretty fast to build it.
    Argh, no. That's not how it happened. And what actually happened is pretty well documented in a dozen or so places.

    Also, the Manhattan project is generally agreed to have taken several times as long as was necessary, because of the military style of management that was used (particularly the compartmentalisation of information, which led to things like the uranium enrichment centers not actually knowing what to be careful of when producing U-238 or how to produce it more efficiently).
    They've got to have learned a lot about working on very aggressive sciencey/researchy engineering projects.
    You know, I don't think they did. Apollo, Manhattan, all the really big and aggressively timelined projects, when looked at in perspective, were either hugely expensive or badly managed. They achieved great things in what they produced; but how they were managed wouldn't be the same success story. They just threw more and more money and resources at things until things got done, mainly from either desperation or national pride.

    You might instead look to things like the original Lockeed-Martin Advanced Development Projects programme, aka the Skunkworks, that's pretty widely hailed as a great way to do one-off and research projects and had a long history of managing several very rapidly developed, very successful, very technologically advanced aircraft from the Lightning to the U2 to the SR-71 to the F-22.


  • Options
    #6
    fergalr
    Registered Users Posts: 1,922 ✭✭✭fergalr


    amen wrote: »
    It all depends by what you mean crash project.

    There are instances of new aeroplanes being designed, built and flowm in less than 60 days in WW11.

    In these cases the general principals of flight were known so while one team might work on the design another would work on materials another on engines etc.

    That's a perfect example.

    In fact, I watched a design documentary recently, talking about the british ww2 efforts - designing and producing planes from wood, because they had wood and carpenters available; turning toy factories into gun makers.

    I don't really want to focus on military stuff, but I would be very interested in how such fast projects were managed, and what people learned.
    amen wrote: »
    In the case of the moon landing while it was a crash program is was implemented in steps such rocket launch, first orbit of earth, first space walk, first moon orbit etc.

    Of course the program was also run in parallel such that as the rocket was designed say to carry a 2 ton capsule and tested with a 2 ton weight the actual capsule team had yet to design the capsule. But that was ok as long as it didn't exceed the 2 ton limit. Same with space suits, food etc

    Design in parallel within criteria and integrate at the end of course time needs to be build into the schedule for integration :-)
    Yes - I'd just like to read case studies from people who actually had to execute on such projects.
    amen wrote: »
    If you have just completed a PhD do you have any stats on the completion time for PhDs for those who have previously worked vs those who enter a PhD straight from under grad?

    I see what you are getting at with that comment: I had some decent software engineering industry experience before coming into a PhD program, and that helped me a lot.

    Not so sure about asking for stats on it though - going to be a lot of selection bias, and a lot of confounding variables - how do you control for the age (=> increased intellectual maturity) of people who worked in industry first? Selection biases - people who choose to leave industry to go back to a PhD program are different than those who choose to continue in academia; etc.
    Sparks wrote: »
    Argh, no. That's not how it happened. And what actually happened is pretty well documented in a dozen or so places.

    Fair enough - I am corrected - don't know the story beyond watching 'pirates of silicon valley'; I'm really just using that as an example to show that sometimes people do try and do ambitious large software projects in a hurry too; I'm not just talking about military stuff.
    Sparks wrote: »
    Also, the Manhattan project is generally agreed to have taken several times as long as was necessary, because of the military style of management that was used (particularly the compartmentalisation of information, which led to things like the uranium enrichment centers not actually knowing what to be careful of when producing U-238 or how to produce it more efficiently).
    Hmm - well, thats another issue, the military people will do certain things from a security point of view - which I'm not really interested in; I remember reading some of Feynmans stories where he talks about examples like that.

    Still, awfully easy to be critical of them in retrospect.
    Sparks wrote: »
    You know, I don't think they did. Apollo, Manhattan, all the really big and aggressively timelined projects, when looked at in perspective, were either hugely expensive or badly managed. They achieved great things in what they produced; but how they were managed wouldn't be the same success story. They just threw more and more money and resources at things until things got done, mainly from either desperation or national pride.

    They must surely have learned an awful lot about the project management. There were plenty of smart people on those projects who were employed as PMs; I find it hard to believe they didn't learn a lot.
    Sparks wrote: »
    You might instead look to things like the original Lockeed-Martin Advanced Development Projects programme, aka the Skunkworks, that's pretty widely hailed as a great way to do one-off and research projects and had a long history of managing several very rapidly developed, very successful, very technologically advanced aircraft from the Lightning to the U2 to the SR-71 to the F-22.

    That sounds useful; a good direction to look; I wonder if they've wrote about their project management.


  • Advertisement
  • Options
    #7
    fergalr
    Registered Users Posts: 1,922 ✭✭✭fergalr


    That sounds useful; a good direction to look; I wonder if they've wrote about their project management.

    This sort of thing looks useful:
    http://ftp.rta.nato.int/public/PubFullText/AGARD/CP/AGARD-CP-602/04CHAP01.pdf

    Came across a reference saying that most of their project management reports and so on are classified; which I guess is to be expected; be nice if someone had wrote non-classified synopsis of the project management stuff they learned; I'll keep looking.


  • Options
    #8
    Sparks
    Registered Users Posts: 40,038 ✭✭✭✭Sparks


    fergalr wrote: »
    Fair enough - I am corrected - don't know the story beyond watching 'pirates of silicon valley'
    Which gets it mostly right except that it glosses over Kildall knowing Gates and knowing about the IBM deal (and omits Kildall's meeting with IBM completely) and trusting that Gates wouldn't, to use his phrase, slit a friend's throat over a business deal.
    I'm really just using that as an example to show that sometimes people do try and do ambitious large software projects in a hurry too;
    Yes, but the track record there is insanely bad. As in, 68% of projects failing bad. Take a read over comp.risks sometime - if there's any evidence out there that we know today how to successfully run large projects, I've not seen it yet.
    Hmm - well, thats another issue, the military people will do certain things from a security point of view - which I'm not really interested in; I remember reading some of Feynmans stories where he talks about examples like that.
    Still, awfully easy to be critical of them in retrospect.
    Yes, but Feynman was critical of them at the time because he was in the position of being the go-between and saw more of what was going on between compartments than the others and he thought it was stupid.
    And he was a fairly smart guy, so I'd have a lot of faith in his evaluation :)
    They must surely have learned an awful lot about the project management. There were plenty of smart people on those projects who were employed as PMs; I find it hard to believe they didn't learn a lot.
    Why? History would seem to indicate the exact opposite was true.
    That sounds useful; a good direction to look; I wonder if they've wrote about their project management.
    They did, and many others did as well. Kelly Johnson's take is one you should definitely read, since he pretty much invented the idea. He had 14 rules for running the place:
    1. The Skunk Works manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher.
    2. Strong but small project offices must be provided both by the military and industry.
    3. The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems).
    4. A very simple drawing and drawing release system with great flexibility for making changes must be provided.
    5. There must be a minimum number of reports required, but important work must be recorded thoroughly.
    6. There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program.
    7. The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.
    8. The inspection system as currently used by the Skunk Works, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don't duplicate so much inspection.
    9. The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn't, he rapidly loses his competency to design other vehicles.
    10. The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended.
    11. Funding a program must be timely so that the contractor doesn't have to keep running to the bank to support government projects.
    12. There must be mutual trust between the military project organization and the contractor, the very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.
    13. Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.
    14. Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised.
    Proponents of Agile methodologies will find most of that quite familiar...


  • Options
    #9
    fergalr
    Registered Users Posts: 1,922 ✭✭✭fergalr


    Sparks wrote: »
    Yes, but the track record there is insanely bad. As in, 68% of projects failing bad. Take a read over comp.risks sometime - if there's any evidence out there that we know today how to successfully run large projects, I've not seen it yet.

    I often hear people saying N% (for some large N) of software projects fail...
    Sometimes engineers from other disciplines looking down their noses!

    But N% is not necessarily a bad thing. Depends on how hard and ambitious the projects are. Maybe 32% of large software projects succeeding is outstanding.

    After all, the software industry has clearly created many billions or trillions of dollars of value...


    Sparks wrote: »
    Yes, but Feynman was critical of them at the time because he was in the position of being the go-between and saw more of what was going on between compartments than the others and he thought it was stupid.
    And he was a fairly smart guy, so I'd have a lot of faith in his evaluation :)

    Yeah, have a lot of time for Feynman's evaluation of anything; really like his stuff on the challenger (though not everyone does.)

    Sparks wrote: »
    Why? History would seem to indicate the exact opposite was true.
    Because when smart people make mistakes they generally learn from it.
    Which doesn't mean they do it perfectly the next time - because that also depends on how hard what they are doing is.

    If many smart people are repeatedly making mistakes, in high stakes situations, I tend to believe that what they are doing is hard, and that its doubly worth listening to their experiences.


    Sparks wrote: »
    They did, and many others did as well. Kelly Johnson's take is one you should definitely read, since he pretty much invented the idea. He had 14 rules for running the place:

    Proponents of Agile methodologies will find most of that quite familiar...

    Yeah - thats good stuff, thanks - those rules were in the previous document I linked a post back, which I found based on your advice - so if that guys rules predate all the Agile stuff, then what else have those people learned?


Advertisement