Philosophical Keynote Address

1
Philosophical Keynote Address

• On Change

2
Defining it isnt as easy as you might think...
If change is just inconsistency, maybe its a bad
thing.
2
3
There is more than one kind.
Brother can you spare a dime.
3
4
Change is not a new thing.
4
5
Change isnt always welcome or good.
5
6
Change is often expensive.
6
7
In other words, if you dont know what youre
signing up for, it may.
7
8
--BUT It pays the bills If nothing ever
changed most if not all of us would be out of
work.
Of course some people make a better living off
change than others.
8
9
Disclaimer Not intended as a political statement
one way or the other. Just talking about change.
Change doesnt always have to be defined to be
popular.
When it is defined it wont be popular with
everyone.
9
10
A real agent of change.
11
Not the preferred method.
10
12
In order to determine the value of a change we
really need to know
what will change, how it will change and at what
cost.
Maybe for you.
If its a boy you better be quick about it.
--and how will the change impact me?
11
Even a decision not to change can result in a
change in satisfaction.
13
The World is Changing Around Us Most Popular
Cartoon Today

• 2005 Pulcinella Awards Best Action/Adventure TV
  Series
• Best TV Series
• 2007 Genesis Awards Outstanding Children's
  Programming (Appa's Lost Days)
• 2008 Kid's Choice Awards Favorite Cartoon

12
14
Influences

• Explicitly stated influences include Chinese art
  and history, Japanese anime, Hinduism (India),
  Taoism (China), Buddhism (India), and Yoga
  (India).
• The production staff employs a cultural
  consultant, to review scripts.

13
15
Back in The Day / Influences

• Sailors
• Hunters Rabbits

14
16
Reasons not to change

• Its hard.
• Its uncomfortable.
• It costs a lot.
• Its no fun.
• Its a lot of work.
• Fatigue, change is constant.
• If it aint broke, dont fix it.

15
17
Why Cant Things Stay Simple?
16
18
Good chart. The numbers may be flawed but we
all know on-going maintenance and enhancement
costs are high.
17
19
Reasons to Change TrnsPort

• Older software higher maintenance costs.
• Finding RTF expertise is tough and it gets
  tougher every day. They dont teach it in
  college.
• TrnsPort doesnt include CRLMS functionality
  today.
• Cant easily pass data back forth to/from
  contractors consultants with the existing
  legacy CS systems.
• TrnsPort is all about, keeping our software
  up-to-date, thats why were here.

18
20
Reasons to Change TrnsPort

• Older software higher maintenance costs.
• Finding PowerBuilder expertise is tough and it
  gets tougher every day. They dont teach it in
  college and the training you can get is pricy.
• Its going to take several years to get this
  developed so if we want a replacement in this
  lifetime we need to start working on it now.
• At some point TrnsPort has to change or it will
  become extinct.

19
21
We have changed.
Ten short years ago
20
22
Today
21
23
TTF Cant do this alone.
24
23
25
Middle Management
24
26
We will change what how is up to you.
25
27
Heres what you should never do.
26
28
Case Study

• CIO Insight
• Behind the Census Bureaus Mobile SNAFUBy Jean
  Thilmany 05-20-2008
• The U.S. Census Bureaus flub of a large-scale
  mobile implementationthe latest in a long line
  of government IT disasterssets modernization
  back a decade.

27
29
Census Bureau Case Study

• In April, Census Bureau Director Steve Murdock
  testified before Congress on this matter. He
  acknowledged that the bureau did not effectively
  convey the complexity of census operations to the
  contractor, and said problems arose in part
  because of ineffective communicationsincluding
  information about IT requirementsbetween the
  bureau and Harris Corp.

28
30
Census Bureau Case Study

• Once these detailed requirements were completely
  delineated, we had serious concerns about rising
  costs and our ability to complete a successful
  2010 census if we continued developing the
  program as planned, Murdock told the House
  Information Policy, Census and National Archives
  Subcommittee of the Committee on Oversight and
  Government Reform.

29
31
Census Bureau Case Study

• Those detailed requirements were indeed a
  problem. The initial contract contained roughly
  600 requirements, and the bureau later added 418
  more, says David Powner, GAO director of IT
  management issues. What happened with the Census
  Bureau is a case study of why federal government
  IT implementations often go wrong, according to
  Powner, who came to government service after
  spending years overseeing large-scale IT
  implementations in the private sector. (The
  government spends 70 billion annually on nearly
  900 IT projects.)

30
32
Census Bureau Case Study

• Step one in an escalating chain of errors that
  went uncorrected The contractor presented a
  poorly calculated estimate. Federal entities
  dont require the same rigorous up-front cost
  estimates as their nongovernmental counterparts
  do.

31
33
Census Bureau Case Study

• To complicate things, that poor cost estimate was
  compounded by requirements creep the tendency
  for clients to add more features to their wish
  list long after theyve signed off on the
  original requirements. Those of us who define
  requirements for systems know it isnt easy, but
  you need a validated set of requirements up
  front, and government doesnt often do that
  up-front work, Powner says.

32
34
Census Bureau Case Study

• Adding to the woes was the lack of oversight of
  the contractor. It seems that the Census Bureau
  didnt lean hard enough on Harris to provide
  continued implementation updates, but Murdocks
  testimony doesnt directly address such
  activities.

33
35
Census Bureau Case Study

• Another problem is the result of the relative
  newness of the mobile technology. The bureau has
  ventured into a new territory with technology
  that is not fully mature and doesnt come with an
  implementation road map, says Philippe Winthrop,
  research director for wireless and mobility at
  the IT analysis firm Aberdeen Group.

34
36
Census Bureau Case Study

• The Census Bureau probably didnt take market
  immaturity into account when signing the
  contract, surmises Sheldon Needle, president of
  CTS, which evaluates software for midsize
  companies. Mobile is still a fairly raw
  technology so they should have had their antennas
  up from the beginning, he says. If the bureau
  was in it two years ago, it was even rawer.

35
37
Census Bureau Case Study

• If I were running such a job and the vendor
  couldnt give me a couple of referrals of
  large-scale sites theyd done, I wouldnt even
  talk to them. What happened sounds improbable,
  but this kind of stuff goes on all the time with
  huge-scale implementations.

36
38
Census Bureau Case Study

• Finally, implementations of mobile technology
  can be very complex. The systems encompass
  multiple components, carriers, devices, operating
  systems and applications that need to be agreed
  upon well before the systems are installed. CIOs
  also need to ensure that all parts of the system
  can be integrated.
• A need also exists to develop business rules for
  each of these multiple components. Were in new
  territory here, Aberdeen Groups Winthrop says.

37
39
Bottom Line

• Change is risky enough when its well defined no
  point in attempting to develop the unknown.

38
40
Changing Horses Is Never Easy

• Old horses are slow.
• Its hard to teach an old horse new tricks.
• Old horses tend to do less with more.
• Old horses die.
• Horses need big graves.
• Best to switch before the grave digging starts.

39
41
It wont be easy.
40
42
So what should we do?
41
43
We got off to a slow start.
42
44
Take control of your future, participate in
fruitful meetings!
43
45
Goal Setting Helps

• 1st you must know what you want,
• Compromise is required when two are more people
  are involved,
• Cant be successful with conflicting goals,
• Goals define requirements,
• When you cant see the final destination
  milestones help make sure you dont get lost
  along the way,
• But always keep and eye on the overall goal to
  make sure you dont get off track.

44
46
Break it Down

• Once you start the trip, changing direction
  really slows down progress.
• In other words once you decide to swim across the
  big lake to avoid failure / sinking / drowning /
  death
• you should know which direction to go in
• take the straight path / dont change direction
• Change in and of itself is a oxymoron because
  commitment and consistency are required to
  accomplish goals and change.

45
47
Be specific about what you want or prepare for
less...
46
48
How do we succeed?

• Clear requirements with managed change
• Well calculated estimates
• Oversight
• Effective communications at all levels
• Keep it as simple as possible
• Break it down to component parts
• Develop the application
• Provide an implementation roadmap.

47
49
Courage Be strong dont be ruled by fear Be
calm dont freak out when things go wrong Be
clear develop and communicate a plan Be careful
dont take unnecessary risk
The End.
48