Information Technology Group Project Rationalization

United States Coast Guard Auxiliary
Information Technology Group (IT)
Software Engineering Projects Rationalization
1 November 2010

 The U.S. Coast Guard Auxiliary’s Information Technology Department has the responsibility to review, recommend, oversee and/or implement software products and processes that further the goals of the Auxiliary, and contribute to the simplification of its processes and procedures. However, considering that virtually all of its resources consist of volunteer “labor”, whose commitments and participation can vary widely over the life of a project, it is crucial to rationalize the type of projects that may be needed or encountered with the software engineering resources available or required for implementation.

The Auxiliary can anticipate at least four (4) types of software engineering projects:

• Heavyweight Projects, Planned – One or more of: long planning cycles; significant requirements specification; complex interfaces to other major new or entrenched systems; long product life-cycle; multi-departmental requirements; hundreds of thousands of lines of code; full-time developers; high security requirements; interface with Coast Guard Systems; multiple, full-time software engineers; critical deadlines; etc. Examples: AuxData, AuxInfo, POMS.
• Lightweight Projects, Planned – Most, if not all of : goals, objectives, features, and benefits can be described on one page; Web-based application; adaptation of open source; short time to proof of concept; iterative development with concurrent user feedback (open beta testing); single engineer. Example: NTC2
• Contributed Projects, Unplanned – Significant software with widespread applicability spontaneously developed and contributed by a member or members; not on any project plan or request list. Member may or may not be on the IT staff.  Example: AuxOfficer.
• Grass Roots Projects, Adapted – Developed by units (district, division, or flotilla) or department for their own use, but subsequently contributed by the developer and adapted for use nationally. Contributor is not on IT staff; adapter may or may not be. Example: Webforms

In addition, projects can be planned or undertaken with three different “service levels”:

• Scheduled Project – Developer(s) have enough technical visibility (as engineers) and personal visibility (as an unpaid volunteer) to commit to a firm product delivery schedule.
• Best Effort Project – Developer gives the project a high, personal priority, and a “best effort” execution, but performance to any but the broadest of schedules cannot be guaranteed, if that.
• Research Project – Researcher has a reasonable expectation of some positive outcome, but unexpected procedural, technical, or even personal issues (e.g., not enough time) could generate a negative result.  Example: Fully-automated Everbridge/AIMS reconciliation to AuxData.

Finally, many projects can be developed with one of two development strategies:

• Use mostly open source software; adapt to fit our need. This can serve to make certain “heavyweight” projects in to “lightweight”, if a nearly-conforming application exists.
• Use mostly in-house developed code (with a smattering to none of open source).

From these descriptions, and due to the nature of an all-volunteer organization with a diverse membership, the following observations can be made:

• The implementation of Heavyweight, planned software development projects by volunteer labor from our members, whether in the IT Group or not, is a fantasy. Paid, outside contractors, and  funding sources in the tens- to hundreds-of-thousands of dollars will be required.  The IT Department’s role will be to drive the development of the specification with stakeholders, manage the contractors to a service-level agreement, and to coordinate the QA testing and acceptance or rejection of the deliverables by the stakeholders. Exception: projects where a nearly-conforming open source application exists.
• Most Lightweight Projects will be “best effort” rather than scheduled, due to volunteer uncertainties, even within our National IT staff. That notwithstanding, both scheduled and best-effort projects can and will be prioritized within the IT group to best meet the needs of our stakeholders and users, and progress will be reported, to provide transparency.
• Users and stakeholders should expect to participate in an iterative development process where users are asked to use, critique, and suggest improvements to prototype software in actual use, where the feedback may actually drive the ultimate feature set and course of development.  This is the process by which most user-facing Web applications are developed on the Internet today. Our 7029 Webform has been developed this way.
• Contributed Projects, Grass Roots Projects, and Research Projects must be encouraged and actively supported, as they can contribute to unexpected leaps forward in our capabilities (e.g., AuxOfficer). Contributors, including IT group members, who as unpaid volunteers are not willing to take on a scheduled or a best-effort project, but continue to refine an existing product, or go off in an entirely new direction that interests them, remain a key resource to our organization.
• Open Source Software compatible with our standard programming platform must be our first response to any new software development request. Open source software is typically the most reliable software available, often has broad and growing feature sets, and above all is free. An example: our new Help Desk/Knowledge Base system.

Bruce L. Miller, DNACO-S, Chief Information Officer