The Enterprise 2.0 Life-Cycle

Over the past few years I have been collecting knowledge and growing best practices for my business area of Enterprise 2.0. I recently changed my position at Navstar to focus on this exclusively and now I am no longer the Director of Technology, I am the Director of Enterprise 2.0. (new business cards have been ordered).

With that, the past few years I have been growing our Enterprise 2.0 business at Navstar, Inc. This growth comes from my personal experience in managing communities over the past 15 years with the various tools available. As the community grows, technology is growing and evolving with or without it. Some communities embrace change, others do everything they can to resist.

With that, I have developed the Enterprise 2.0 Life-Cycle or ELC2.0

The Enterprise 2.0 Life-cycle

This life-cycle is the stages in which I have seen organizations, communities, and businesses adapt to the changing and available technologies that help their organization grow and thrive. This may ring a little familiar to those who are familiar with the Software Development Life-cycle (SDLC), the long, costly, and project creep way of doing business. In this approach, we do not wish to reinvent the wheel. We firmly believe that there are many excellent open-source solutions that are ideal for business collaboration, communication, networking, and transparency.

• Evaluation – The Enterprise 2.0 team evaluates the customer for their needs, conducting focus groups and attending meetings of those in the target community. A requirements document is developed based on the discussions and presented to management for a proposed solution.
• Enterprise Implementation – All activities and tasks are derived from capabilities, actualized by deliverables, and produced into an implementation document.
• Customization – During the pilot introduction and eventual community roll out, the Enterprise 2.0 works with customers to tweak the enterprise solutions (toolkit), to fit the communities needs. Not just an out of the box solution.
  
• User Management – An experienced Community Manager will work as a part of the larger community to bridge the technology and cultural gaps, develop guidelines, and tutorials for new users. As well as act as initial Tier 1 support until additional staff has been trained.
• Training – As you introduce new tools to your community they will replace existing business practices. With new technologies and tools, comes a bit of a learning curve for some. This is why we believe training is essential to the deployment of Enterprise solutions.
  
• Evolution – As the community comes on line with the tools replacing old business practices with new techniques, comes the desire to do more. This becomes the natural cultural evolution of the community.
  
• Revolution – The cycle continues as the revolution takes over. The community suggests new tools and new technologies on their demand bringing back the circle to evaluation, in which the Community Manager and Enterprise Architect consider the community input to take it to the next level.

Now this is not the entire strategy I am posting, but rather the highlights [excerpts from our Navstar, Inc Whitepaper on Enterprise 2.0 for Business] of the overall implementation of Enterprise 2.0 within a community, be it business in the private sector or the Government. If your business or organization would like to learn more or are looking for a company with Enterprise 2.0 experience and solutions that encompass the entire life-cycle, then feel free to reach me at my work email account [abaker at navstar-inc.com]. I would be happy to listen to your needs and open a dialog for a solution in which Navstar can help you.

Tweet This Post Delicious Digg This Post Facebook Reddit

8 Comments

• 

  By George, April 8, 2009 @ 6:50 am

  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 Craig, April 9, 2009 @ 2:00 pm

  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, April 10, 2009 @ 5:47 pm

  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 Andrea Baker, April 15, 2009 @ 6:22 pm

  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 Andrea Baker, April 15, 2009 @ 6:26 pm

  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, April 15, 2009 @ 6:28 pm

  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 PB, May 28, 2009 @ 8:40 am

  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, June 23, 2009 @ 8:06 am

  @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.

Other Links to this Post

RSS feed for comments on this post. TrackBack URI

Leave a comment