The program my teams and I work for, Landsat, celebrated it’s 40th anniversary last week.
More specifically, my teams are part of the development effort for Landsat 8, a continuation of the program with an expected launch date in February 2013.
One of the lessons I’ve learned from working in this environment is that trying to develop products and systems as a part of a long-standing program is difficult.
There are compromises that must be made.
When the products you make need to be consistent with historical products, there are restrictions and additional coordination with the sustaining engineering activities that are going on with the operational system.
If you don’t coordinate with the operational system properly, you end up developing something that has to be re-worked when your system is integrated into the operational system.
Have you been a part of projects like this? Are they more difficult in your opinion than purely new development?
40 Years of Continuous Earth Observation from Space
NASA put out this awesome video from 1973, one year after the first Landsat satellite began orbiting the earth and collecting remote sensing data.
This is good for a retro chuckle, but it’s also amazing to me at the same time.
My teams develop with modern programming languages and the advancements over the years are amazing, especially when I watch the video from 1973 and see all the knobs and push buttons.
And if you’d like a taste of more recent representations of the Landsat program:
It’s been said that starting a Federal program is the closest thing we have to eternal life. We have a habit of sustaining old projects for really long periods of time.
I faced this problem pretty regularly as the Chief for Defense Business Transformation in the Military Health System. My office, along with several similar offices across the DoD, were charged with implementing the Defense Department’s response to statute (10USC2222) as described in the 2005 National Defense Authorization Act (NDAA), Section 332.
We were essentially established to help the Defense Department – the Nations largest recurring federal expense – to improve the way they made investment decisions. We knew several years ago about the economic issues the nation would be facing – issues that will make the “Fiscal Cliff” look like a speed bump. We were on fire with the importance of what we were doing. We knew there are tens of Billions of dollars in bad investment decision making to be saved. In the early years, my office alone returned $200 million of $1 Billion to the Treasury due to poor or missing business cases, expired requirements, and redundancy. In my opinion, we left a lot (too much) still on the table.
The program was wildly unpopular. Eventually it was watered down and defanged. Politics worked so hard against change that even the original statute has been changed to eliminate references to things that were “too hard” – I’d say “politically inconvenient” to do.
We did come across the phenomenon you described above pretty regularly. Standards evolve. Technologies evolve. Requirements evolve. The key is to have a process that allows evolution to happen. The process requires communication, discipline, and follow up, but it is theoretically possible if the culture is cooperative. Don’t give up!
Thanks so much for sharing your experience with us David!
That sounds like a very worthwhile program, and it’s sad to see that it was marginalized. One of the tough parts is that these reductions generally mean staff will be let go – but it’s usually a necessary part of the decision. Redundancy and other work that doesn’t add value needs to be eliminated – otherwise you are doing busy work and not getting any ROI.