Comments on: The Enterprise 2.0 Life-Cycle

By: Andrea Baker

Andrea Baker — Tue, 23 Jun 2009 15:06:33 +0000

@PB I don’t erase or discount that there is a development process layer to take in account. I look at this from a managerial perspective and take into account my experience as both a developer and a PM in both agile and non agile methodologies. A follow up post to this thought should be published by the end of today.

By: PB

PB — Thu, 28 May 2009 15:40:09 +0000

ELC2.0 is a nice model for high level presentation of an enterprise system evolution. But I believe that “the long, costly, and project creep way of doing business” as you put it, is the real grunt work and underlies all higher level presentation models. At some time, somebody needs to design and code all of the open source solutions that are needed. And that must go through a controlled development process, else disaster is imminent. The need to evolve with technology requires non-trivial code changes.

By: Andrea Baker

Andrea Baker — Thu, 16 Apr 2009 01:28:08 +0000

George

I am with you. This does not replace the actual SLDC, but it more of a supplemental approach not only for the project manager, but for the community to understand the adoption of the culture shift.

By: Andrea Baker

Andrea Baker — Thu, 16 Apr 2009 01:26:25 +0000

Craig,

I do not disagree with your opinion here. What I am presenting is not a change for change sake, but replacing existing processes with more collaborative and transparent ones. If its not broke, you don’t have to fix it, but you can improve it over time. This cycle is not one in stone either I should say, that is the beauty of E2.0. They can overlap to be sure to accomplish the mission. Customization will probably occur more than once in the life-cycle. However, in the evaluation, as I have observed, you pick the tool whether open source or COTS and you make the adjusted customizations after you pick the pilot software. You won’t know what you need until your customers tell you what you need. Not the other way around.

By: Andrea Baker

Andrea Baker — Thu, 16 Apr 2009 01:22:29 +0000

I am personally not aware of these programs and their subsequent disasters. I have not worked with either agency in any official capacity. However, I have been a guest speaker at NGA in the past.

By: George

George — Sat, 11 Apr 2009 00:47:32 +0000

Two major programs that have used new development methodologies are NGA’s Geoscout program and the NRO’s FIA program. Both of these resulted in disaster and could be used as case studies in any Program Management training.

By: Craig

Craig — Thu, 09 Apr 2009 21:00:14 +0000

Let me stick up for tried-and-true methods of software development for a second. New software does not always require new methodologies. That just leads to trouble. I will argue that the SDLC, and others like it, do not cause scope creep. Bad project managers and washy customers cause scope creep. A good manager will make it work with nearly any established methodology. Be careful of changing for change’s sake.

Finally, if I am to read this chronologically, the “Customize” stage seems to serve as an invitation for scope creep before the system is delivered and users are trained. I believe the customization would have to come at the “Evaluation” phase the next time around the cycle.

By: George

George — Wed, 08 Apr 2009 13:50:35 +0000