Recommended
Recommended
More Related Content
Similar to 2003 Innovation Expo: (W)e Coast Guard
Similar to 2003 Innovation Expo: (W)e Coast Guard (20)
More from dan.p.taylor
Recently uploaded
Recently uploaded (20)
2003 Innovation Expo: (W)e Coast Guard
- 1. ISD we make IT happen ALMIS Aviation Logistics Management Information System LCDR Dan Taylor USCG Aircraft Repair and Supply Center Elizabeth City, NC 252.335.6170
- 2. ISD we make IT happen Background • ARSC one of 3 USCG data centers • Support 26 Air Stations, ARSC, HITRON, staff elements • Well established business processes • Recently completed 5 year, $12.3M AC&I project to integrate two legacy apps and meet new requirements • ALMIS now a single system with four subsystems
- 3. ISD we make IT happen Organization • No system can be more integrated than the people who produce it • Close relationship between government and contractor was a must • Simple processes served us well • Values must be communicated clearly • Investment in our people paid off • Built relationships between developers and customers
- 4. ISD we make IT happen Software • Buy versus build question is not simple • User interface leveraged existing business practices • Words and colors matter • Delivered task-oriented online help • Involved customer in deployment strategy • People are subject to Darwin’s theory, not Moore’s law
- 5. ISD we make IT happen Implementation • Formed and invested in implementation team • Distant learning yields distant results • Face-to-face initial training at customer site was a must • Taught basic computer skills in many cases • Extensive real world testing prior to fleet- wide rollout • Delivered total solution: hardware, software, training, long term support
Editor's Notes
- Introduce myself. COMDT's first point yesterday was that we must aggressively apply IT to reinvented processes. I'm going to share how we've done that with ALMIS. My focus is going to be on the people whom the IT is being aggressively applied to, our customers in the field. Many changes and tools have come to folks under the banner of "e-Coast Guard." I'm going to focus on the people part of e-Coast Guard. You might think of this as a "We-Coast Guard" talk. Many of the lessons we've learned will scale up or down to larger or smaller initiatives, and as we consider the challenges that face us integrating legacy systems with new Deepwater systems, I think you'll find something in the talk that you can use. I guarantee that if you give me a chance, something I say will make you think. Some of you will hear something you can put to use on a project you're working on, some of you will think I'm wrong, and some of you will think you should have skipped it altogether to get changed for the reception aboard Taney. I'll start by providing just enough background about ALMIS so you can understand the context for our lessons, then I'll turn to our lessons learned along three dimensions, the people who built the software, the software itself, and implementation.
- -ARSC one of three CG data centers. The other 2 are FINCEN and OSC Martinsburg. -ISD customer base: 26 air stations, ARSC, HITRON, staff elements, vendors -well established business practices -5 yr, $12.3M project to satisfy four broad goals 1. -integration between two legacy applications in which many of those practices were embedded in software -2 mature, mission critical legacy applications used by 300 people -separate physical databases -separate maintenance staffs -character based -typically rely on paper entry re-keyed into computer -limited printing / analytical support 2. -source data entry and capture of information not previously captured, esp unsked mx 3. -graphical decision support or in the buzzword of the time of the RP's, an EIS 4. -integration with enterprise applications -data source for other systems including MISLE, RMS, CGINFO, ... -AC&I project completed, ALMIS now a product with four subsystems: ACMS ==> the two legacy systems which are now partially integrated, and AMMIS ==> in single physical database EAL ==> partially integrated everywhere, fully implemented at 8 Air Stations, expect fleetwide deployment beginning Jul DSS ==> using same Cognos tools you've seen from MISLE, RMS, CGINFO
- -to give you a sense of the size, ISD has 3 military, 25 gov't civilians, and 44 contractors. -My applications branch has 4 gov't and 22 contractors. -one thing that is true and will be important for upcoming software development efforts in CG logistics is that -no s/w is going to be more integrated than the team who develops it. -enormous challenges at first trying to develop software with people in three physical locations on 6 separate contracts working in 3 separate directions with 3 separate sets of standards, processes, priorities. -partly driven by ARSC redesign that was occurring at the same time that produced some physical space constraints, but partly by the initial decisions that were made about how to approach the ALMIS project as something separate from the maintenance of the legacy systems. -legacy maintenance and new development were eventually brought into same room and used same processes to get software from development through testing and into production. -simple business model in ISD: 2 processes used to track our work and measure our performance. one is an SCM tool that is used for anything that ends in CI change, other tracks our actions that support everything else. -One of the important ways we keep close to our customers is that we have many sources of feedback coming in, but everything goes into one of two processes and is tracked to completion. -that responsiveness is big part of turning customers into partners in the development process -close relationship with contractor. Having gov't and contractor's working together to solidify requirements, code, test, implement has worked wonders for us. Early in the project we had started down a documentation heavy approach that didn't work. Quickly determined that working closely together and writing only that which is needed and that which we're willing to maintain worked much better for us. That relationship with FC Business Systems produced ALMIS, and we're now in the second year of 5 year SETS contract with RSIS. -3 clear priorities reiterated over and over for division: Safety, Quality, Product (which includes time) Everyone understands that we have a system that people rely on for info that will kill them if it's wrong. -invest in people -people are going to treat customers the way they're treated -sent them to professional training and conferences -I made heavy personal investment in training team -send people to field to see how customers are using their products -instructive / humbling for developer -Everything is different in D7 -- my folks saw that. Saw D14. Saw D17....
- -Describe EAL, what it does, value proposition. Show paper stuff. Offer to buy your first drink if someone can find my name on it. -measures -immediate visibility of status or readiness -immediate visibility of operational utilization -unsched mx -labor hours -cannibalization -link operations to maintenance to supply -works from anywhere n/w reaches, including u/w -technology focused answer: go to Oracle. Heard that from a number of folks. People focus: ask why, conclude not worth the effort. Customers don't know or care that the Electronic Aircraft Logbook application is a web-based app connecting to the same Ingres database used by AMMIS or ACMS. They can see that it's the same database, but they shouldn't care whether it's brand x or brand y. No one knows or cares that our cubes are built from Ingres, MISLE from SQL Server, CGINFO from Oracle. -we couldn't afford to re-do all the work that has been done using Ingres, and really wouldn't get any value from doing so. -"It's easier to change business than software" That's not a given, not clear, and deserves a lot of thought before deciding which path to pursue. Ignores impact on people or business. -COTS is great if you have no or poor process. -Dell walked away from failed SAP implementation when they found that the software was not flexible enough to fit their business model. -we paid for a study and found that there was not tool that did all of what we needed. Nothing off the shelf could replace legacy apps and meet new requirements or tie into legacy apps and add necessary new functionality. -decided to leverage investment in Ingres, extended relationship -Once we decided that custom development was in order, question is how. -checkbook metaphor. Get volunteer to write a check. Ask about Money and Quicken users. There's a reason that those companies used a checkbook metaphor for the application. Application builds on what people already know. -do we do that in the Coast Guard? -I sat through training on one system that took about two hours that turned upside down one business process that used to be fairly simple from my perspective. I told her it seemed like the best thing I could do is forget everything I knew about doing things the old way. She said "Yes." -we chose a different approach. -Chose to leverage what people already know about using paper-based system. Any of you who have come to our booth and seen the demo might have noticed that we picked some really odd colors for EAL: Yellow / blue / pink sheets. -Why'd we do that? Read Nielsen excerpt 123 and 126. Application matches what they're used to in physical world. Good mapping between computer and mental map of info -to the maximum extent possible, we've used the same layout and naming conventions. My computer guys thought I was nuts until they saw the level of acceptance in the field. I just can't tell you enough how important that has been for us in building initial comfort with the move to an electronic tool. -I've heard "Not worth it to change colors or words," but I disagree. -Site map uses colors to orient users as well. Some other applications don't have a site map. -non technical CO / XO able to use it first try without training and get it more than half right for typical flight. The fact that they were willing to try and could figure out interface was great. -customer focused design decisions: screen size 800 x 600 vice what works on developer's 21 inch monitor. Those sort of considerations are easily overlooked but are very important. -Chose an architecture that would work with low bandwidth so it would work well underway or with slow connections. -numerous analytical tools rely on data that comes in through the three applications in ALMIS. The quality of the info depends on the system used by folks on hangar decks who get it in. We've made the investments to make it as simple as possible to use. It would be nice if you never needed help, but... -Value of electronic help? Neilsen 149. Very proud of our online help. It is task based and speaks the user's language. That doesn't happen automatically either. I've used electronic help in other systems that's clearly written by software developer and it's as though I'm reading the directions for putting together a bike that were written by someone who didn't really know English. The person who writes EAL help is a 10,000 hour pilot. His right hand man is a 30 year CWO. The two people who scour it before major releases are retired 20 year Chiefs. Neilsen is right, not many people use it. Except when they have a problem, and I've found that aviators spend a surprisingly large amount of time trying to help themselves before they call our help desk. Each time we get a call where someone can't figure out something for themselves from the online help, we look to see if there's something that needs to be changed or added. -Q: make a little, deploy a little continuously everywhere, or make and deploy at a few units, then roll whole package to fleet? How do you decide: ==> throw out the question and see if anyone mentions "Ask the users" -Our plan A. Built quick first chunk to validate approach, telephone training at three Air Stations, two weeks of testing, roll fleetwide with telephone training. Keep building chunks and rolling out everywhere until we were done. segue: -feedback from Aviation CO's conference in fall of 2000 led to high touch implementation: -decided to complete EAL, beta test at mix of units, then roll complete package -visited every Air Station for initial awareness and training on DSS tools and EAL schedule, which was then optional. -formed implementation team -kept listening and modified implementation strategy based on user feedback -moore's law / darwin's law ==> takes intentional discovery and constant willingness to adjust to figure out what organization is capable of.
- -this is really what we feel most proud of and where I think many innovations wind up selling our people short. -it's also the place where my initial assumptions about the level of effort were proven most wrong. -we often assume that technological innovation will sell itself. Couldn't be more wrong. Organizational change does not occur because of technology or through fiat. -our experience was that we had to create one believer at a time. -provided face-to-face briefing on the project and the value proposition of the change. Invited all hands, some had all hands, some had just a handful. Provided small group training on DSS tools. -I heard someone say here about the cubes: there's lots of info there for the asking. My experience is that without training it will not be used. We were lucky that when it was time for us to determine what tool we would use to meet the goal of providing a DSS / EIS, the Cognos tools were emerging as the de facto CG standard. They met our needs and we decided it would be great if people didn't have to learn how to use different tools to do the same analysis. But there's still a learning curve, and we're stepping up to the plate to teach folks to use the cubes. -cubes and reports: announced via message and e-mail, but used very little until we showed up at the units and provided initial training. By this point we had created an online tutorial that bridged the gap between nothing and the help that was included in the Cognos tools, but I found that was sufficient for only a small fraction of people. -Most needed small group, hands on training. Using same Cognos tools as FLS, MISLE, CGINFO, but the tools still have a steep learning curve before getting useful answers. -while I began visiting every Air Station, our contractor was looking for two new people to bring aboard for our implementation team. We specifically looked for people who were: -familiar with aviation business -background in training -not IT geeks -not technical -understood marketing. I was blessed with people our contractor found. 2 ATTC instructors with field experience and one who worked part time as traveling salesman. -Now that we had the people, needed to decide how to deliver the training. -there are so many new ways to deliver training these days online or with computers. There are all kinds of technology to throw at training these days. -our experience has been that distant learning provides distant results Q: how did you learn to drive? Whether a car, a ship, or an aircraft, there's no substitute for having live training from a person you can ask questions of. -in person hands on initial training for any new system should be considered a must -CBT can supplement but not replace face-to-face interaction between people -someone here at the conference summed it up very well: "You can't ask a CBT a question." -Chief: learned what she needed to know by walking around and getting status. "Came here, talked to people, and got updated. Beats reading stuff. Would never have read all of it." -Lots of folks here are building technical solutions that ignore the people really work and learn. -why don't we approach implementation of new IT systems the same way? Pause -by keeping our eyes and ears open and remaining flexible, the same CO's who wanted us to build all of it and test it somewhere else before delivering a complete package asked if we could roll out the second big chunk, which was generally the flight record. We did it with onsite training at every Air Station. -Result is that you have near real time info on operational utilization of every CG aircraft. -now that we've done in person training and built the foundation, we can roll out new parts with telephone / e-mail / other electronic training. -H65 status rollout example. -Eyes and ears in the field also led to lots of great ideas from very junior people who otherwise would not have been likely to have ideas considered. -began to see level of computer skills of average user. -saw firsthand that there were not enough computers to meet the need. We bought 171 desktops, 72 laptops and 72 printers, later more for ATTC. All SWIII. -know that people in this room are not the typical computer user. Question: How many blue suiters know what "RAS in" or "using a token" means? Ask that question in the field and you'd be amazed at how few people know. -One surprise: security is typically a balance between security and usability. -Power of security and being able to provide a login and read only access and tell someone, "Don't worry, you can't mess anything up" is huge. But they need to be told! and shown! -2 biggest mistakes / mitigation -change, even small, without adequate warning. If you swapped someone's 8 track to cassette they'd hate you if they didn't see it coming. -making small changes in application without watching users use it in real life -scheduled releases announced via message / e-mail / banner / ... -prominent version number and release notes -Implemented total solution: -increased hardware needs at Air Stations -increased hardware needs at accession points -training at units -who's gonna train the new guys? -getting it into syllabuses -working with 2 accession points into aviation -what have I given up? I could have hired a developer to build more software rather than an implementation team to ensure folks are supported. -there will be early adopters who need no more than a login to any system and they'll figure out how it works. Some of you in the room may be in that camp. Having visited every Air Station and seen people use computers, I can tell you that we tend to overestimate the familiarity with the CG standard workstation. We're starting from square 1 with many folks. There are still folks who don't know what it means to "open a browser" or to "copy and paste." -basic computer skills are a building block, like reading, and must be taught by somebody.
- We've tried to consider the human impact of our software. It has taken us a tremendous amount of intentional work to have a customer focused implementation of ALMIS. Could I have produced more software if I had hired two more developers instead of two full time training folks? Yes. Was it the right decision? Yes. Four years ago never would have dreamed of making a personal visit to every CG Air Station to provide an overview on the changes ALMIS was bringing and to train them to use browser-based reporting and OLAP tools that I figured out by myself. Looking back, that year I spent on the road half the tim was the best possible use of my time. CORNER ME ON TANEY INVITE TO BOOTH 27 in AM QUESTIONS