Civil XLR8 Extra: Captaining the Enterprise

Home Up Project Management Enterprise MicroStation InRoads Glossary

Home
Up

Initial Implementation

The Most Import Thing Not To Forget in InRoads:

When defining an initial implementation of InRoads from a vendor or consultant, it is critical to have the "infrastructure" of the software settings to be sensible, defensible, and easily extensible.

Standards evolve.  To minimize the time-consuming "ripple effect" of changes in CADD standards,  InRoads should be delivered with Named Symbology used to their maximum extent within InRoads command Preferences.  

This is true universally, but especially for CalTrans as the new v8 Level Naming Convention has not been defined (if it has it will change significantly as the users get comfortable with v8). 

Other Areas to Properly Specify:

Command Preferences (neglecting symbology)

Design settings can generally be pulled from the Highway Design Manual.   Initial implementations seldom can accommodate the entire spectrum of issues.  Have a prioritized scope.

Have a plan for "non-default" alternatives.  Common Presentation variables (different scales, etc.) are easily accommodated by additional Command Preference Settings in InRoads.  A naming convention should be suggested and a scope defined.

Feature Styles

Feature Styles are the intelligent "object types" in InRoads.  Existing Feature Styles are usually subsets of Survey Feature Codes.  You do not need a 1:1 ratio between Survey Feature Codes and InRoads Feature Styles.  Some level of genericism is preferred early on.

Proposed Feature Styles (the things that actually result from our design efforts) can be gleaned from Pay Items.  Again, a reasonable scope can be managed by genericising the massive Pay Item list (e.g., how many Guardrail types or Dike types do you need initially?).  Note: Items displayed asymmetrically (Left Guardrail and Right Guardrail in Cross Section, for example) need separate Feature Styles.

Implementation Management Techniques

Do not expect to deliver a "fixed" implementation.  

  • This will be a fluid, feedback-intensive, long-term effort.  
  • An adaptable Plan for Change Management is perhaps the most important factor to short-and long-term success.  
  • Make sure you build an extensible architecture.
  • Get quality feedback early and continuously.

Do not try to please too many people too early.

  • Expect that no implementation can ever satisfy everybody's needs.
  • You'll never get anything done if you expect to get a supermajority or majority.
  • Be pleased if you get a strong minority consensus.
  • Be prepared to make necessary decisions that have strong minority opposition.
  • Building an Implementation is like engineering:  it's a convergence of iterations, each iteration getting closer to a final, massively-acceptable solution.  
  • Keep the heretics close.  Their needs CAN be addressed later and their energy can be very useful.

Set deadlines.  Make decisions.  Recognize that it's an incremental and inexact process.

  • Convergence is based on iterations.  Delayed decision --> delayed delivery --> delayed feedback --> delayed improvement.  
  • The "voting pool" will always enlarge.  Needs drift accordingly.  The target will move.
  • Familiarity leads to different needs.  The target will move.
  • There will be reversals in direction.  Sometimes the coin that landed on heads in February lands on tails in August.  The target will move.
  • Don't let the moving target keep you from shooting.  It's okay to deliver a solution to a problem that has shifted (that is what the next release is for).
  • The impacts are minimized if the software infrastructure is set up to handle change.

It's seldom "No."  It's more often "Not yet."

 

Additional Info

This "Captaining the Enterprise" web is something I was putting together in my spare time.  It is raw, incomplete, and probably confusing.  It's purpose was to help me connect the web of ideas involved in implementing MicroStation and InRoads in a large organization.  There is useful and pertinent information that you might find important.  My philosophy is to make empowerment a primary goal even if the cosmetics need work.  

Who am I?

I work at CalTrans now, through a Staff Augmentation contract with CH2MHill.  I was technical lead at Oklahoma DOT and Colorado DOT for what CalTrans is embarking on.  

Info about me can be found at:  civilxlr8.com/bio_jeff.htm 

Info about my professional activities can be found at civilxlr8.com

Why am I "helping"?

I have a vested interest in doing what I can to help make sure we have a good rollout.  I'm not sure what my future holds, but it will be in California and in all probability CalTrans standards will affect me for a long, long time.

 

good luck!

-jeff martin, p.e.

©2005-2006 Civil XLr8
This internal information is posted as a courtesy.  Please help maintain its confidentiality.  Thanks, -jeff  [Email Jeff].
Last updated: January 02, 2007.