FY 13 Budget Request

Today the President’s Budget was released. This is one of the first public steps in the process that ends with a FY 13 Appropriation.

I want to highlight two things relevant to everyone with a stake in CG-LIMS.

This project is important. I recommend everyone read the one-page fact sheet on the Coast Guard’s Fiscal 2013 President’s Budget. Read the whole thing. You’ll see CG-LIMS is specifically called out as part of the as part of the $1.2B AC&I budget request to “responsibly rebuild the Coast Guard.” You can also see the details of the budget request for CG-LIMS in the Congressional Justification. Skip right to page 159-160 and you’ll see CG-LIMS listed as part of the “Other” AC&I sub appropriation.

The CG-LIMS budget will remain small. The CJ you are used to seeing is on page 215 through 217. The Fy 13 request is $2.5M.  The CJ includes the funding history of $20.9M going back to 2008 when we began the transition from ICGS. Page 166 includes the Five Year Capital Investment Plan (CIP), where you’ll see the out-year funding remaining consistent until 2017. I know many of you were aware of that plan, but it had not been released publicly until today in the President’s Budget. Add the past and the future plan together and you arrive at the $40.9 total that led us last Spring to change what we could deliver (ORD Segment 1 through 3 for ALMIS assets) and how we delivered it (non-major project, in-house, CG as integrator).

So how do I feel about the planned funding being decreased for both FY 13 and for the out years? I feel great. It tells me that the Coast Guard thinks it’s important enough to keep it small enough to succeed. We will not be able to afford to customize the COTS tool, or even over-configure it. Limited resources and a focus on serving customers’ real needs will keep us from delivering any more than is absolutely necessary. We will create no more documentation, no more PowerPoint, and no more software than is absolutely necessary to accomplish the mission.  We can’t afford to. That’s a good place to be. Perhaps in FY 14, after a year of successful configuration and implementation of the first segment, the Coast Guard may be in a position to make trades with other projects to accelerate the funding so we can accelerate delivery. But that’s a post for next year.

If you want to see how the Coast Guard budget fits into DHS’s priorities, I’d encourage you to take a look at the DHS Budget in Brief or Congressional Budget Justification FY 2013, both available on the Department of Homeland Security Budget page.

photo credit: Cathy Arkle

Self help

Today I have a quick addendum to the 9 Jan post. That post reiterated to everyone that CG-LIMS is going to be a small project that leverages in-house resources.

After the post, we added more clarification on the Questions and Answer Page to say that the message was a genuine official message from the Contracting Officer, not just the ramblings of a PM who lost his mind.

I repeat the message here to make sure everyone hears loud and clear that there is no big System Integrator solicitation coming. The Contracting Officer wrote:

While this wiki is not “official,” and has been used as a forum for idea germination, Captain Taylor’s posting above is all quite true; the ideas are not seedlings, but fully grown. Our budget is projected to shrink significantly, and CG-LIMS is becoming a do-it-yourself project, unlike what was envisioned a few years ago. The technology demonstrator discussed last winter is no longer part of the plan. Having made our software selection, we will now move directly into system development, conducted by the Aviation Logistics Center (ALC) as System Development Agent. We are preparing a solicitation for a small amount of integration support service to augment that in-house effort, but have not yet determined the contracting strategy (GSA, EAGLE, stand-alone, 8(a), set-aside, etc, – it’s all still fluid). The Advance Acquisition Plan may be found on the DHS Acquisition Planning Forecast System (APFS) under AAP Number 201170930. As soon as the contracting strategy for the implementation support service has been established, we will share that information with industry. There will not be a contract for the integration itself as that effort will be performed by ALC personnel. Signed: Laura Q. Spillane, Contracting Officer, CG-LIMS project.

photo credit:  U.S. Coast Guard photo by Petty Officer 2nd Class Charly Hengen

Kickoff

Another high point for our team last week was a kickoff meeting with the technical folks who will do the initial installation of the software we just licensed. It was a great opportunity to bring together the key folks from OSC, ALC, Oracle, and the PMO. I’m elated that we ended the meeting with a plan to establish a demo environment at OSC during the week of Valentine’s Day.

The meeting was also a chance to reinforce for everyone involved that the Coast Guard is the System Integrator. We will be contracting for the technical support for the configuration, but we will not be turning the configuration and implementation over to a system integrator.

In today’s post, I will share with everyone the three thoughts I covered at the start of the meeting:

1. We will keep it small. Our budget is constrained. We will be adding just a few Oracle experts to the development team. This may be the fastest, least expensive implementation Oracle has seen. We’re okay with that.  We’ll gladly accept the challenge of implementing a system that provides the greatest value to the business with the fewest resources.

2. We will keep it COTS. This is a technology refresh of legacy ALMIS using COTS software to meet enterprise requirements. We we keep the system as out-of-the-box (OOTB) as possible. We’ll use OOTB language as much as possible to deliver quickly and cheaply. Don’t be fooled into thinking this is a custom development effort designed independently of the constraints of the COTS tool. We will make the most of the COTS software. We’re paying the cost. Let’s get the benefit.

3. We will be Agile. We will use an OOTB Agile Scrum methodology as much as possible.  That’s what’s working for ALC, so that’s what we’ll do.  We’ll use ALC’s two week sprints. We will work with six month (or less) release windows to provide shippable products that add value to the business. We welcome the prioritization that will have to be done to meet that rhythm. If we cannot deliver value in six month increments, we can expect the project to be stopped. The government has seen too many failed implementations of big systems like this. We must show it can be done quickly in small segments.

We covered plenty more ground during the meeting and in the breakout sessions afterward. The complete minutes are in CG Portal. My point today was simply to reinforce the message that to succeed, we need to keep it small, keep it COTS, and keep it Agile.

photo credit: johnwilliamsphd

Learning

One of my high points last week was attending a training workshop on Agile System Development. The workshop focused on executing projects in the federal space.

It was wonderful to see some old friends from ALC and to meet folks on the development team I hadn’t worked with before.

Today I’ll share my three biggest takeaways and invite others to do the same in the comments.

1. We’re approaching the basics right. The day started with a basic overview of the Agile approach to delivering software. It left me feeling like we’re doing the basics right. I was pleased that they covered the INVEST acronym to describe what makes good requirements. That’s been on my list of things to share in the blog since I first heard it from the leader of the DHS group developing an Agile approach to Level 1 and 2 Acquisitions. I know it’s commonly used in Agile circles, but I hadn’t heard it used within our team. I was pleased that the requirements manager from ALC was familiar with and supported the notion that that good requirements should be Independent, Negotiable, Verifiable, Estimated (or Estimable), Small, and Testable.

2. We’re fortunate we can leverage existing contracts and in-house talent. Much of the extra overhead and extra work in executing Agile development in the federal space comes from the fact that the requirements development and system development are often separate efforts done by separate organizations and separate contracts whose communications are restricted by OCI concerns. We’re fortunate that at this point, our Sponsor’s requirements are defined and approved. The rest of the requirements definition will happen within the context of the system development team. This is consistent with what one of the speakers said about typical development in the commercial space, where there is less separation between the requirements team and the development team.

3. We’re fortunate to have tools to rapidly prototype and get user feedback. We heard about the notion of using “pre-visualization” to create code free prototypes as an intermediate step in requirements elicitation and refinement. It was good food for thought and led to some side conversations with folks with experience doing it. Fortunately for us, the two main ways we’ll deliver capability–configured COTS and changes to EAL–lend themselves to rapid prototyping with the user *without* the intermediate step of code free pre-visualizion using a separate software environment. On the COTS side, within two weeks we should have a demo environment established that we can use to show the basic interface and work alongside users to prototype ideas within the constraints of the COTS software. In time, we’ll also have a development environment we can use for iterative configuration. At some point, that becomes an environment we can use to work with end users. I can see us going from whiteboard to modeling environment within the COTS tool (which we’ll soon learn much more about) to seeing the results on screen without using an intermediate code free pre-vis environment as described in the workshop. For changes to EAL, we’re fortunate to have well established UI and team of people who grew up doing prototyping with live apps the way Ryan Singer of 37Signals describes in a 2010 talk at the “Future of Web Apps” conference in London.

Those were my big three takeaways that apply directly to CG-LIMS. Here’s one more thing I heard that’s so true: “Great things come out of people whom you allow to think.” Indeed.

What did you take from the experience? I’d love to hear from anyone who was there!

photo credit: Martin_Heigan

Tomato Tomahto

I can’t join the team to watch the demo Monday morning, but I watched it right after award and have a few thoughts to share.

After watching it, I was excited about the opportunity we have to deliver something great. My hat’s off to the source selection team for (a) sitting through many of these demos and (b) choosing software that offers what we need to succeed.

It confirmed my thinking that we want the out of the box user interface as much as possible. I’ve been cautioned by people who have done implementations like ours that “over configuration” can be as bad as over-customizing it.

If you’ve assumed that we have to change all the vernacular in Oracle to CG-speak, I’d ask you to consider the value of using Oracle taxonomy where it makes sense. If a “non-routine” is another word for unplanned maintenance, it might make sense for us to just call it a “non-routine.” If an inter organization transfer is the same as a parts pool, it’s worth considering using the Oracle (and many times the standard industry) descriptions. They call a “visit” any opportunity to do maintenance. I don’t think we have any similar term. I’d offer for consideration that maybe adopting the term “visit” could be helpful for us.

I know this comes from a guy who preached the value of having EAL development map to the analog world of yellow, blue, and pink sheets. It was the right thing to do then as we moved folks from an analog world to a digital world. But at the same time, we kept Cognos as out of the box as possible. That was the right thing to do too.

As we make the transition from character-based ACMS and AMMIS to a COTS implementation of Oracle E Business in short sprints, we need to consider the cost/benefit of each change we make to the “out of the box” conventions, especially in the early sprints when we’re trying to get a shippable product up and running.

If we want to take advantage of the COTS capability we’ll need to be flexible. We’re not trying to make this look and feel like ACMS. We’re building a COTs foundation that we can build on. If we keep it as “out of the box” as possible to start, users can make informed decisions later on whether the best way to deliver value in the next release is through delivering more functionality or making the nomenclature more CG specific. Start small.

I’m guessing (and that’s all it is right now is a guess) that we’ll be better positioned to take advantage of things like the CCB approval workflow processes that are already seeded out of the box if we are sticking to the basic conventions and terminology Oracle expects.

Please don’t take these as final edicts from a guy who has never led an Oracle E Business implementation. I know this is just the beginning of the conversation on the approach to COTS configuration. But this is some of the stuff we’d no doubt talk about during the breaks if I were there with you. Since I can’t be there with you, I wanted to share the thoughts this way to spark conversation.

photo credit: jacki-dee