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

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

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

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

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

We didn’t have much to share beyond what had already been shared on this blog about how we intended to deliver CG-LIMS as a very small project that made the most of organic Coast Guard resources.

For those who are new to the project, the posts I shared are great background for you.

Here’s what I shared on the wiki’s Questions and Answers Page:

Q. Can you give us an update on what’s going on with CG-LIMS? You haven’t said much in the wiki since the end of the REBOOT study.

A. We provided an update on the wiki before we released the RFQ for the COTS software. Since then, we’ve used the project blog (exported regularly to WordPress) to keep everyone updated. The five best posts to read today to understand the nature of CG-LIMS as a small project that will be delivered in small chunks with as small a team as possible are:

• 23 May 2011: Start. Small.
• 20 June 2011: Changes
• 18 July 2011: Balancing Act.
• 2 Aug 2011: Training. Ourselves.
• 17 Aug 2011: Alignment Check
• 19 Dec 2011: Plan Big. Start Small.

For those interested in competing for contracts related to configuration, I shared in the 20 June post that “This will be a MUCH SMALLER CONTRACT than the RFP for the whole system we put together last fall. It may take longer to get contract awarded than to award a task order on APLES, but we are still aiming for as simple a contract as possible to quickly deliver using the SDLC process.” This will be a small contract to get subject matter expertise in the selected COTS tool not already organic to the Coast Guard.

I can’t share FY 13 budget details until it is released in the President’s Budget. But I shared in the 18 July post that “One of the common (and obvious) themes is that every part of the organization is dealing with the reality of a declining budget environment. None of us have enough resources to deliver the service we want to. Everyone is making tough tradeoffs among competing demands.” Don’t expect the FY 13-17 plan to be the same as the FY 12-17 funding plan.

As we adjust to a more austere budget, I shared on 2 August that “We need to figure out how we’re going to do training in a severely constrained budget environment… how we’ll do ‘good enough’ with less. We also need to figure out whether we’ll use existing resources from the PMO or SDA / SSA or whether we need to contract for it.” The contracted effort may be smaller than folks imagined under a less constrained budget environment a few years ago.

photo credit: Thomas Hawk

As we plan the first segment, please start thinking in terms of fixed schedule and variable scope.

Today I want to expand a bit on something you may have read in the 1 Dec PM IPT Minutes:

Taylor – Think in terms of fixed schedule and variable scope. If we find that we cannot deliver what we plan to in each sprint or release, we will prioritize and adjust scope. I will communicate what we *CAN* deliver in first six months if it is something other than our current plan. We will not think in terms of infinitely expandable timelines to the right.

As we plan the first segment, think in terms of what can be delivered in a series of sprints over six months.

By the three month mark, I will ask our Executive Oversight Council to confirm that what we think we can deliver — based on actual cost and progress — is a worthwhile investment from their perspective.

Jim and I are available to help the team think through any further prioritization needed for the first segment requirements. If we can’t deliver everything in the product backlog in the first six months, we’ll prioritize. I am willing to sell that to leadership.

Think in terms of prioritizing what we *can* do. Don’t focus your energy on what you *cannot* do. Can’t do everything? That’s okay. Let’s be clear on what we can do.

“We thought we could do x in six months, but based on the experience we just gained, it turns out we can only do the most valuable 75% of x in six months. We’ll have a product that we can field for the HC-144 at that point. We’ll prioritize the remaining 25% of the requirements into the next release.”

I can sell that.

It is a shift toward an Agile approach that will serve us well in the long run.

I’m willing to take a smaller step in the right direction than we thought was possible when we knew less.

If this becomes harder than we thought at first, we will take smaller steps.

I’m not willing to ask for more time for the initial delivery.

I’m not willing to deliver the message that things are just taking longer than we thought and we’re not going to have anything that can potentially be fielded until some number of months later than we planned.

I won’t ask executive leadership for more time. I’ll ask the team for more prioritization.

We will keep prioritizing until we define a product that can be shipped and deliver value in six months.

Please make the shift to thinking in terms of fixed time, variable scope. This will be a significant mind-shift for some of us, and will be hard for some. Be kind to one another as we make that shift.

My confidence that we can succeed in this way of thinking comes from a place of trust in the core development team. I have seen you work together and shipping both a custom application and a COTS tools on timelines similar to what we’re trying to approach with CG-LIMS. You are ready for this challenge. You know it won’t be easy. That’s what makes it so satisfying.

I recently heard talk of increasing staff to update and maintain architecture representations in SA.  Before we get too far down the road of growing the staff, I want to remind everyone of a perspective many of heard directly from the Enterprise Architect in 2009, and share a new discovery that someone brought to my attention after the COTS tool selection earlier this month.

Back in February 2009, many of us met the new Enterprise Architect and heard directly from him on some of the guiding principles he wanted to bring to the Coast Guard’s approach to EA. I remember hs caution that if we’re not mindful of perspective and relevance, the architecture is just an inventory exercise and will become shelfware. He cautioned us to stop one step before it becomes irrelevant. That makes sense. Like any artifact, we should know the goal and stop when we meet it.

As part of the Requirements IPT, we created the initial architectural views that represent the high level requirements. Before charging forward and capturing the lowest levels of detail that can be captured and and maintained in SA, we need to get familiar with process modeling capabilities inherent in the COTS tool we’ve chosen. If modeling the detailed processes is a part of the natural design process within the COTS software, we have to be clear about the cost and benefit served to also do it in SA. If it feels like we’re trying to create and maintain the truth in two places, we should have a really good reason to do so. That’s a synchronization and verification burden I don’t want to take on if it can be avoided. If  process modeling is an inherent part of the configuration process, I’d much rather maintain those artifacts as part of a self-documenting design process than create and maintain a second version in SA.

My point here isn’t to dictate a solution.  I simply want to open the group’s eyes to the possibility that details that *could* be in SA may *fit better* in the COTS tool. It opens the potential for moving more directly to working software, with less design artifacts to create, maintain, and (please no!) keep in sync.  We want to find the most direct path to delivering software that meets the user’s need.

photo credit: PA2 Bill Colclough

Short version: because the System Development Agent (SDA) is already using Agile scrum and it works.

Longer version: The Reconsider Best OptiOns (REBOOT) study developed a possible way forward as a fully funded major system acquisition. That strategy included a technology demonstration with many goals, one of which was to validate that an Agile methodology could work for a COTS EAM implementation. When budget realities led us to further reconsider what could be done with far less funding, an important part of the strategy to execute as a non-major acquisition included leveraging the existing SDA and SSA.

I shared some of that with you back in March when the Executive Oversight Council approved the way forward. I shared some of the key success factors in that post:

• Leverage existing people, processes, technology
• Organic OSC and ALC subject matter expertise
• Find what is working and do more of it
• Involve users early
• Mission support personnel from all asset types
• Decisions must reflect value of speed and simplicity
• Provide governance appropriate to investment

I knew we couldn’t deliver CG-LIMS quickly without tapping into the expertise at ALC and OSC. The processes I was talking about were the development processes. Whatever they were doing, it was working, and I wanted to do more of it. People trust their software with their lives. We no longer needed to do a tech demonstration just to validate that Agile scrum worked. Instead, I was happy to leverage whatever was working for them at that time to deliver working software.

Once the decision was made to leverage ALC and their development processes, I didn’t say a whole lot about Agile. I wanted to use what was working.  I didn’t want to be the HQ guy trying to “help.”

It wasn’t until September that I new ALC had started to bring an Agile scrum methodology into one of their teams. Soon after I found out, I shared it with you.

… As budgets shrank, scope decreased, and strategy was refined, our plan changed to relying on the existing processes at ALC and OSC. Rather than dictate a methodology, we will leverage what is working. As those mature organizations evolve, we welcome their movement toward Agile, but the PMO can’t direct it. Carl told us at the 8 Sep PM IPT that ALC as using Agile for the rework of the Preflight and Servicing portion of the Electronic Asset Logbook. I think that’s great, and I’ll do everything I can to help move in that direction.

I welcome the discipline, forced ordering, user involvement, and integrated testing that come with Agile.

I’ve also been pushing the folks in the PMO to adopt Agile principles to the way we execute our work. We’re not delivering working code, but many of the principles still apply.

Emil’s reply pointed me to a book that’s guiding the ALC team. Based on that recommendation, there are now at least two well worn and marked up copies being passed around the PMO.

So why are we usign Agile scrum? Because it’s the methodology ALC thinks will work based on their experience using it. Have they been doing it for years and years? Nope. They’re just starting, learning lessons, and making adjustments.

I’m excited to learn right along with them.

photo credit e-magic

What we did

We took an important step last week. “Think big, plan big, start small, deliver quickly.” We know it’s true. But it’s mighty hard to plan big enough but keep the initial steps small enough to succeed. You’ve done it.

We planned big. We awarded a competitive BPA based on enterprise requirements that fulfill a need first identified over five years ago with the MNS for the “Enterprise Transformation of Coast Guard Logistics” written by the Logistics Management Transformation Office (LMTO) in May 2005. We awarded a BPA for software that provides sufficient ceiling to meet all plans within the CG-LIMS acquisition project and for the rest of the Coast Guard enterprise.

We’re starting small. We made a decision. We led the stakeholders through a competitive decision that will benefit the Coast Guard for many years. The first delivery order will provide enough licenses to support the initial configuration. We’ve structured the project to support the incremental investment of resources. We won’t need more licenses until we’ve configured a segment that meets requirements and is field-able. This incremental, risk-based commmittment of resources is the way we should do business.

How we did it

We borrowed smart people. We were blessed to have the expertise of the best fifteen men and women available to judge the COTS software offerings. The real smart folks who understand the present state and are smart enough to think out-of-the-box about the future are always in demand. I feel so fortunate that we were able to commit the time needed to serve on the source selection team. We had technical people, usability experts, and experts in logistics and financial business processes. Most importantly we had key folks from ALC and OSC who were selecting a product that they would have the privelege of implementing. We hand-picked the best.

We were transparent. Throughout the process, we have been as transparent as the law allows with each other in the Coast Guard and with industry. The project has changed in scope and approach several times since it was chartered. We conducted the REBOOT study with total transparency. Our requirements in the CONOP and ORD have been public for over two years. We take it for granted now, but that level of transparency was a BIG DEAL when we first decided to share.

Five thoughts on the work ahead

Stay connected to the users. We’re delivering tools they’ll to use to accomplish a mission. Now that we’ve selected the software and committed to delivering something in six months, this becomes much more real for them. They’ll want to be engaged. Engage them.

Remember, this is COTS. If we find ourselves stopping outside of what the COTS tool can be configured to do, it should feel VERY UNCOMFORTABLE. We’re not as unique as we think.

Keep it small. Do everything possible to keep size and complexity from creeping into the project. Document only as much as needed to deliver and know the goal of the documentation. Some documents only exist to support development and can be thrown away once they have served their purpose. If we’re documenting something and intent to maitain it in order to maintain the the system, make sure it’s really needed by the folks who will be maintaining the system.

Fight complexity. Don’t let others convince you to add complexity. The user probably doesn’t care, and we can’t afford it.

Stay transparent. There should be total transparency between the PMO / ALC / OSC and with any other part of the organization that has a stake in what we’re doing. We want everything we do to be available for continuous review by users and investors. As we’re forced to consider whether we’ll keep using CG Portal, my number one requirement is to have a way to collaborate transparently using whatever platform is most consistent with the enterprise’s long term vision. It’s unfortunate that we’re not using the same system for collaboration that’s being used to plan the optimization of the Core Accounting System.

Feel great about what you’ve accomplished, and be excited about delivering something users will value in six months!

Now the floor is yours… I invite any of you to add a comment to share your thoughts on what we did, how we did it, and how we should approach the work ahead.