I’m an avid home movie maker.  I’m also known to pinch pennies so until two months ago, I was doing my home movie editing with a software package that was seven years old.  I’ve paid for upgrades a few times to get some additional functionality, but stopped doing that when one upgrade made my home computer (which until recently was eight years old) operate so slowly I had to roll back to the previous version.

My “personal technology gap” had widened to the point where it was impacting my family (“Dad – The computer froze again and I can’t finish my homework!”) so I bit the bullet and bought a new state-of-the-art home computer (family happy!).  Now it was time to finally upgrade my video editing software.

I did what any good penny pincher would do.  I thought carefully about my requirements.  I found a website that reviewed all of the leading video editing packages, comparing features and prices side by side.  I learned about newer features to determine which I’d really use.  I downloaded evaluation copies and tried them out.  Convinced I had found the most inexpensive software that met my requirements, I went ahead and purchased it (now I was happy!).

But after actually using this software for months and not just running through test evaluations, I’ve uncovered a lot of limitations.  The review website put checks in boxes for some of my most important features, but the actual performance of those features in the package I bought is so limited it makes me believe the software company just mocked something up to pass the review.  Now that I’m more familiar with this generation of software, I also recognize that other features I considered optional are really necessary for the types of movies I want to make.

I was past the time limit for returning the software so my options were limited.  I could either live with software that really didn’t fit my needs, find workarounds, or accept producing poor quality videos.  Or, I’d have to bite another bullet and purchase the more flexible software package I should have bought in the first place.  Neither option was enticing.  Buying the other package would mean I’d have to recognize a complete loss on the first package I bought.  Producing poor quality family movies would clearly have an even greater long term cost, although putting numbers to it is hard.

So I decided to come up with a third option.  I called the company that made the software I had already purchased and gave them a list of the things I wanted them to fix and add to the product.  The customer support rep I spoke to said she would forward my list on to their product management group.  That wasn’t good enough as I needed to quickly make a decision as to whether I would throw their software out and buy the other package so I pressed further.  I asked the rep if she could get me a price quote and timeline for making my full list of changes.  After an awkward pause, the unfortunate support rep had to inform me that their company wasn’t in the business of making specialized software just for one customer’s needs, and if they were, the costs to do it would be orders of magnitude greater than the $99 I had already paid.

I certainly didn’t want to shell out thousands of dollars on a fix so I went ahead and bought the other software package.  I sure hope it fits my current list of needs and I don’t come up with any additional ones that might make me need to purchase yet another software package.

So what does the government have to do with this? 

I explained the details of my purchasing story the way I did because it is the exact same approach the Federal government uses to purchase multi-million dollar software systems.  The Government’s track record with these purchases is very poor and things aren’t getting any better.  The problem lies with the Government’s approach to acquiring software.

The Federal Government buys software the same way it buys tanks, construction materials, or any other physical goods.  When you’re buying something physical, it is much easier to evaluate it against a long list of criteria.  It is also easier to project likely additional needs and anticipate additional costs.

But software is a different animal entirely.  Software applications at the heart of core government processes are very complex.  Knowing which of many possible features are required to meet current needs is a challenge.  I’m sure many government workers are like me and my video editing software.  They are using technology that’s so old they don’t know what’s possible and what they really need until they get to start using newer technology.

Technical evaluations are equally challenging.  Most capabilities defy a simple check box.  Each capability has unique ways it must be graded.  That creates execution challenges for contracting officers (CO) and contracting officer technical representatives (COTR).  Even if they do their jobs exceedingly well, new requirements can emerge after the software has been acquired and installed.  Now the Government is faced with the same options I had with my video editing software, except that when they call the company that made the software, they get a price quote for the changes they want… and it is almost always exceedingly high as the software company knows the customer is stuck and this is their chance to make up for what may have been an aggressively low initial bid.

What’s the result?

A survey I conducted recently of Federal acquisition professionals found that 60% have requested changes to their contract writing systems only to decide against them when they got a price quote from the software company.  They are living with disappointment and finding manual workarounds to gaps in their software.  And some portion of the rest did pay the exorbitant prices to get the customizations they needed.  Neither is a good outcome.  The irony here is that the acquisition evaluation in all cases led to the selection of a system that was deemed to meet all core needs at a low price.  Clearly the Government’s acquisition process did not lead to the best value and lowest overall long term cost.

How can the Government get better results in software acquisitions?

Albert Einstein is noted for saying, “Insanity is doing the same thing over and over again and expecting different results.”  As long as the government continues to approach software acquisition the same way it approaches physical goods acquisition, it should continue to expect poor outcomes and unanticipated costs.

The answer is to adopt a new set of criteria for software purchases.  Vendors should be evaluated on their current functionality as well as the flexibility of their software to economically adapt to changes, even at the core logic level.  This can be accomplished by COTRs adding a set of typical changes to the software functionality at a surface, mid, and deep functionality level and requiring bidders to explain how they would make the changes in what period of time and at what cost.  COs must make this a part of RFIs and RFPs.  These estimates need to be factored into the final evaluation.  The longer the anticipated life cycle of the application, and the more dynamic the business of the organization that will own it, the more weighting should be given to the core flexibility of the application and the cost of change.

To learn more about highly flexible software technology for acquisition and contract writing systems, please download my new white paper, “What Federal Acquisition Professionals Need to Know About the New IT Landscape.”

Evan McDonnell

Here’s what brought this analogy to my head.  I just finished taping an interview with Chris Dorobek of the DorobekINSIDER on GovLoop.com about my newest white paper titled, “What Federal Acquisition Professionals Need to Know About the New IT Landscape.”  I wrote this paper because it’s become clear that acquisition professionals don’t understand there is a new generation of technology available for acquisition and contract writing systems.  My paper explains the new technology and provides guidance on how to structure an evaluation process to include options using this technology.

At one point in the interview, Chris asked why I thought government agencies continually buy software that doesn’t fit their needs well.  The answer is that they have been making the best choice they can, but options that can really fit the individual needs of each agency haven’t existed before.  New technology allows for cost-effective, ideal fit systems.  In that light, agencies that still purchase commercial off-the-shelf (COTS) or government off-the-shelf (GOTS) acquisition and contract writing systems need to recognize they are no longer choosing the best solution.  Instead, continuing to buy COTS/GOTS software is the equivalent of forcing round pegs into square holes.

The result of this action isn’t pretty.  At the surface, you have government agencies with poorly performing software.  This leads contracting officers to have to use manual approaches and work outside the application to get specific acquisition steps done.  Can’t the software be customized to fit their needs?  Of course it can.  Software vendors creating COTS products will never turn down customization requests, they will just price them extremely high.  A recent survey I sent out to a diverse set of Federal acquisition professionals showed that sixty percent had requested changes to their acquisition software, only to decide against doing them when they got the cost estimate, meaning they surrendered to a state where they use software that doesn’t fit their needs.  Seventy-two percent of survey respondents said their organizations would be significantly more productive if they could modify their acquisition software at low or no cost.

Software that doesn’t perform well causes work inefficiencies and ultimately has a short operating life.  These COTS applications are not cheap.  Combine their cost with impaired contracting officer efficiency and you have millions of dollars wasted.  But the costs of continuing to rely on inferior technology runs into the billions when you step back and recognize that problems with an acquisition system can lead to poor acquisition outcomes and higher prices for the government.  With the volume the Federal government buys, and some of the multi-billion dollar systems it purchases, the acquisition process gaps stemming from poor fitting IT systems (“round pegs in square holes”) can lead to unthorough processes and a failure to attract the maximum number of bidders possible.  The result is billions of tax payer dollars wasted.

Let’s stop letting our money be used to buy IT systems that are “round pegs in square holes.”  And it’s not as simple as just finding square pegs for square holes.  The shape of the holes will change over time as needs change, agency missions evolve, and new FAR regulations are released.  Now that new options exist, there is no excuse for government agencies to not have IT systems that can be easily and inexpensively adjusted as their needs change over time.

To learn more about the new technology available for acquisition and contract writing systems, please download my new white paper, “What Federal Acquisition Professionals Need to Know About the New IT Landscape.”

Evan McDonnell

Appian’s position is that BPM software is crucial for improving government procurement operations. Our partner SI Systems Technologies LLC (one of the 12 small business awardees) agrees, and will use the Appian BPM Suite as a strategic asset in its NETCENTS-2 bids.

In a Defense Systems Magazine article from June of last year, Maj. Gen. Wendy Masiello talked about NETCENTS-2 as “a strategic ordering vehicle” that will allow USAF to reach more contractors, including more small businesses, to increase competition while improving how acquisition contracts are managed and executed. “The concept,” she said, “is to pre-vet the contractors that will be providing IT solutions or products to the Air Force so we can manage those contractors like a program.”

NETCENTS-2 will provide a wide range of IT Network-centric and Telephony products, services and solutions to support vital USAF operations and support the USAF warfighter. NETCENTS-2 has a stated goal to support the re-engineering and modernization of legacy systems through the rapid, incremental delivery of network-centric solutions. In spirit if not in letter, this has “Appipan BPM” written all over it: fast, codeless composition of flexible solutions that provide a modern overlay of native mobile access and social collaboration across a wide range of disparate legacy systems. The Application Services Small Business companion provides a streamlined, enterprise-supported contract vehicle to consolidate many existing contracts that are currently separately managed and tracked.

The benefits of NETCENTS-2 should be dramatic. More competition means better prices for USAF (using, of course, our tax dollars for payment), and increased accountability placed on the contractors delivering services and solutions. SI Systems Technologies is looking at Appian as a platform to help them be more competitive in rapidly delivering innovative, cost-effective and highly-flexible USAF application services.

David J. Doherty, Program Manager at SI Systems Technologies, said, “Advanced business process management software presents a faster, more cost-effective means for developing government IT solutions than traditional software development. The flexibility, zero-coding design and modern mobility and social collaboration capabilities of the Appian platform will be a strategic asset in our NETCENTS-2 contract bids.”

NETCENTS-2 has the hallmarks of a more efficient and effective way for federal agencies to manage acquisition of the IT services their employees and constituents require. But having forward-thinking contractors like SI Systems Technologies using BPM software to those ends is really only half the battle. USAF and other federal bodies need to embrace BPM in their own internal operations as well. Remarks from Maj. Gen. Masiello support this:

“I think it bears repeating that under our better buying practices we need to relearn some skills that have perhaps atrophied over the years. And that includes understanding how to implement incentive structures in our contracts, digging into the actual prices that we are paying for weapon systems or services with more knowledge and understanding, and building that type of expertise and experience into the workforce. We have a young workforce. They are less experienced and less skilled, and many of their seniors who are coaching them don’t have those incentive experiences either, so this is a whole workforce educational opportunity.”

I read this as 1) increasing visibility into what’s going on, 2) having the right data to make more informed decisions about how things are progressing and 3) institutionalizing related best practices (ie., optimal business processes) and enforcing them across the workforce. To learn more about why these all scream out for BPM, read about the Appian Acquisition Business Management solution.

Ben Farrell

The same general approach also applies when evaluating multi-million dollar software investments that you hope will be the backbone of your operations for the next 10 or 15 years.  But the factors for consideration are very different in technology-based purchases.  It’s imperative to get this process right if you want to have a system that fits your needs, provides the highest benefit, and has the lowest lifecycle cost of ownership.  There are two common mistake areas in TCO analysis that everyone should note and avoid.

Mistake #1 – Using Only Hard Cost Input Numbers

A TCO model for a large software purchase almost always ends with an Excel spreadsheet comparing well-crunched numbers side by side.  With that end in mind, buyers set off with a focus on hard numbers they can enter into their models.  The first mistake they make is limiting their scope to upfront cost, annual maintenance, and expected upgrade purchase costs from the vendor.

This is a mistake because it leaves so much out of the picture.  For starters, how well does the software package fit the needs of the intended users?  If it is commercial off-the-shelf, how easily can it be adjusted to meet new requirements?  Software that enables faster work, more collaboration, and better management visibility can have a dramatic impact on a company’s bottom line, yielding benefits that are often many multiples of the software’s costs.  Choosing a software application because its costs are easier to define and appear lower without regards to fit can lead to fiasco.

Evaluating how software can make an organization more effective can be straight forward in some cases (e.g. new production management software that increases daily output by 10%).  But it is frequently not a hard number exercise.  Compare two software packages, one that follows traditional design and  keeps project information within a department vs. another that has built-in social communication around process events that can break down silos.  How much more productive would your organization be if decision times could be cut in half (like CME Group experienced)?  What’s the value of the competitive advantage that would create?  While specific numbers may be hard to generate, these benefits have to be included in an evaluation.  Forward thinking business and government leaders are driving their organizations to think this way.

Mistake #2 – Not Planning Ahead for Unexpected Change 

One of the things I love about financial analysis in Excel is that everything lines up neatly.  The sense of order that comes from seeing factors displayed and calculated builds comfort and satisfaction.  But often this is a false sense of comfort.  Reality is full of disruptions and unplanned events.  It’s hard to fit those neatly into rows, columns, and cells so analysts tend to ignore them to the organization’s peril.  The longer the time horizon for analysis, the greater the impact this mistake has.

While working as a business strategy consultant in the early 1990’s, I distinctly remember a colleague telling me he just heard about this thing called the “world wide web.”  Talk about a disruption!  Any financial model I created for a client at that time that went out more than five years was flawed because it didn’t account for the explosive growth of the internet.  The same is true for any financial analysis built within the past five years that didn’t account for the explosive growth of mobile communication and social networks.

How do you incorporate unplanned events into your TCO model?  History teaches us that disruptive events in your business will happen.  You will either incur the costs to adapt your software or incur the organizational costs of not having software that meets your needs.  (It’s not pretty when organizations find their software isn’t flexible.  It spawns manual processes outside of the application which has a negative impact on every type of metric.)  Recognize that your software will have to be adapted to meet new conditions.  The longer the planning horizon, the more adaptations you’ll require.  Ask these questions – Can this particular software be adapted?  By whom?  At what cost?  Probe to get example costs for changes that seem easy as well as ones involving core logic changes.

The Right Way to Build a TCO Model

Here’s what a TCO model that avoids these mistakes and accounts for all costs and benefits looks like:

Application start-up costs:

• Software licenses expense – be sure to estimate any overage charge if the license isn’t a per-user model
• Server and infrastructure costs – required only if the application is not in the cloud
• Required customization to meet initial needs – this is easy to scope as part of an evaluation process (but you must account for a shortened application lifecycle if customizations prevent upgrades to the base product)
• Professional services for installation – just to get the software functional in your environment
• Cost of training users – this can be high if the application logic doesn’t match your organization’s work logic
• Costs to enable users if access requires anything other than a standard web browser (e.g. a thin client on the desktop)

On-going application support costs

• Annual software maintenance costs to the vendor
• Internal costs of supporting the application
• Expected costs of full vendor upgrades to get enhanced functionality (usually every 2-3 years)

Costs of adapting the software to meet changed conditions

• Who can adapt the application – you the client, a class of third-party developers, or only the software vendor?
• Expected frequency of changes – both minor (e.g. workflow, input variables) and major (changes to core logic)
• Expected cost per change (be sure to ask vendors for rough orders of magnitude for a range of changes)

Organizational Benefits

• Improved productivity of direct users (e.g. 20% more transactions processed per day)
• Better insights for management through easily tailored reporting
• Built-in mobile apps to allow process participation from mobile devices (iOS, Android, Blackberry)
• Improved communication and decision making across departmental boundaries (only applies if the application has built-in social collaboration around process event feeds)
• Speeding of information and decisions across departmental boundaries
• Improved management control

There’s one more factor that defies quantification for a TCO, but experienced managers find a way to account for in the process.   That’s the trajectory of the vendor behind the software application.  If your planning cycle requires you to view this purchase as a 10-15 year investment, then part of your purchase is a bet on the vendor’s continued innovation and expansion of the core application.  Be sure to find a way to account for this in your analysis.

Failed IT investments are common news in the business press.  The Federal government has had several that recently gained a lot of publicity.  There are usually many factors that account for big scope, long term projects getting derailed.  The seeds of failure are often planted early.  A complete and proper TCO analysis can help avoid these early sources of project failure.

Evan McDonnell

What’s the antidote for the spell that good sales people put on you?  Ask for a copy of their end user license agreement (EULA).  Here you’ll find all the caveats and disclaimers that will bring you back down from Cloud 9 and let you see reality for what it is.

I recently read through the EULA for a commercial off-the-shelf (COTS) software package for Federal acquisitions (yes, I have a very exciting life!).  Their marketing collateral promotes how they are a flexible solution that you can easily adapt to your agency’s specific needs by modifying application workflow, but their EULA reveals they are still a traditional COTS application with limitations that have frustrated Federal contract management staff for years.

Here are the key facts potential buyers need to know with references to specific language in this EULA.

If you don’t purchase upgrades, you will lose support.  This vendor’s maintenance agreement only includes “dot” updates (e.g. 2.6), not full releases (e.g. 3.0).  With this vendor, your ability to evolve is contingent upon buying a steady stream of upgrades.

• “By purchasing [vendor]‘s Maintenance, the Customer will receive all Software Versions and Service Packs (but not Releases) that [vendor] issues during the subscription period…”
• “Our policy is that we will de-support an older version of our software eighteen (18) months subsequent to the release of the newer version. De-supporting an older version of our product means that we will not be releasing any service packs for that version subsequent to the de-support date, nor will help desk support or bug fixes be provided for the de-supported software version.”

Appian customers paying annual maintenance get all updates and future releases at no charge.  For example, when Appian introduced built-in social collaboration and native mobile clients on iOS, Android, and Blackberry nearly two years ago, every one of our active maintenance customers with named user licenses got that additional functionality for free.

If you make any agency-specific modifications, you can’t install service packs until the vendor folds your modification into the core code, which happens only 1-2 times per year.  Same goes for little “fixes” you request to improve user experience.  You’ll likely have to wait 6-12 months to get them.  And those changes… yeah, they are going to cost you since the COTS vendor has to do them. 

• “When an agency orders a new customization or pays to have specific fixes included in [the software] version, [vendor] will create a new, temporary branch of the [software] code for that customer and will make the changes to that version of [software].  Once the agency accepts the changes, the agency specific branch will be scheduled for inclusion in the next enhancement release.  Until the agency specific branch is merged into the enhancement release, the agency cannot install any service packs.”
• “[Vendor] provides one or two Enhancement Releases per year.  Enhancement Releases contain changes that might affect the general user experience, such as:
• New COTS enhancements developed by [vendor];
• Customer-funded enhancements that are being merged into [software] COTS and become part of the supported product;
• Software fixes developed by [vendor] to address user experience issues reported by customers”

With Appian, you are in full control of your application.  Your team can make whatever changes you want and put them live at your leisure.

Any “defects” you discover will only be fixed subject to the decision of the vendor’s Change Control Board.  This highlights an inherent weakness in COTS software.  It’s impossible for a COTS vendor to make all the changes every customer wants so their “review boards” have to decide which customers to disappoint.

• “In some cases, a software defect will be discovered through the ticket analysis process.  If this occurs, the [vendor]’s Service Desk will log a Software Change Request (SCR) in our Software Call Tracking System for further analysis and potential code fix. Each week, [vendor’s] Change Control Board (CCB) will review all new reported SCRs and give them each a priority rating.”

With Appian, there is no review board.  You have full control of your application.

You can’t change anything or share modifications without the vendor’s consent and any enhancements you jointly develop become the property of the vendor.

• “Customer shall not develop any modification to the Software without [vendor]’s express, written consent.  The Customer agrees that such modification will be used solely in connection with Customer operations, and that such modification will not be marketed, licensed or sublicensed, sold, assigned, or otherwise transferred or made available to any third party or other entity, without the express prior written consent of [vendor], which consent shall be within the sole discretion of [vendor].”
• “In the event [vendor] jointly develops any modification to the licensed Software [with the Customer], such modification will be the exclusive property of [vendor], and licensed to the Customer under the applicable license terms of the GSA schedule; however, the Customer shall receive such limited data rights to such modifications as defined under the schedule contract.”

Appian couldn’t be more different.  It’s easy to export the models you build with our product and share them with other users on our vibrant online forums.  We encourage our customers to share and leverage each other’s work.

The Chief Information Officers of the Federal Government recognize that software licenses like this are part of the main reason why the government’s IT investments have performed so poorly.  The need for true flexibility in acquisition software is being clearly expressed by Federal acquisition staffs.  All vendors want to show that their products can be ultimately flexible.  It’s up to buyers to get past the spell of a good sales presentation and see the reality of the product they will actually be buying.  For that, there’s no substitute for reading the EULA.

Evan McDonnell

So much positive news in the space of a week had me feeling optimistic that we are on a path to stop wasting tax payer money and bring effective IT systems to government.  But my good mood ended when an e-mail hit my inbox with fresh evidence of some of the thinking and behaviors that have caused the Federal government’s IT investments to significantly underperform.

Here’s some background.  The first Federal CIO, Vivek Kundra, introduced a 25 Point Plan to Reform Federal Information Technology Management in 2010 because of the sorry state of affairs that existed with government IT systems.  Kundra noted in the introduction to the plan, “despite spending more than $600 billion on information technology over the past decade, the Federal Government has achieved little of the productivity improvements that private industry has realized from IT.”

The uncertainty around Federal contracting rules is one reason for this poor performance.  Both government officials and vendors have been unclear as to what type of communication is sanctioned and what is not.  This has kept government IT leaders’ knowledge of latest technologies and adoption strategies behind the times.  The attention brought by the 25 point plan has spurred other parts of the government to rally and help.  Ms. Field’s memo titled, “Myth-Busting 2: Addressing Misconceptions and Further Improving Communication During the Acquisition Process” is one example.   Ms. Field notes in the memo, “Early, frequent, and constructive engagement with industry leads to better acquisition outcomes, which is why it is one of the key tenets of the Office of Management and Budget’s 25 Point Implementation Plan to Reform Federal IT Management.“  Ms. Field went on to say further that, “Agencies appreciate industry’s valuable input into their acquisition strategies and solicitation packages because it may result in a better solution to their requirements. Suggesting detailed solutions to your concerns is even more valuable.”

The e-mail that turned my excitement to mush contained a newly released pre-RFP for a major Federal IT system.  The buyer sent out the pre-RFP to learn as much as possible about commercial best practices so it could adopt the best strategy to convert its legacy information systems environment into an agile and flexible operation.  I thought, “Great!  Here’s an agency that really wants to learn and is being proactive ahead of a major purchase.”  But my heart sank when I continued reading and found this sentence, “The agency has determined that the best approach for systems modernization is to use a commercial off-the-shelf (COTS) solution rather than transforming its legacy systems.”  By specifying COTS, the agency had greatly restricted the field of possible solutions.

Things actually got worse from there.  The pre-RFP goes on to detail lots of specific functionality that the buyer says must be already available in the solution.  This sounds like a logical approach to purchasing, but it is way behind the times for IT systems selection.  By following this approach, the buyer is falling into an all-too-common trap that’s been a significant contributor to the $600B of ineffective government IT spending.

Let me explain.  The problem with the approach of limiting choices to COTS applications and evaluating them based on specific functionalities is that to have a successful selection, you need to document every known requirement and predict future requirements.  Not only does this require lots of work, it’s really an impossible task.  Users of IT systems often don’t know what they want (or what’s possible) until they get to start using new technology.  They really need hands-on experience before they can identify their most important requirements.  Evaluating COTS vendors based on specific functionality has shown to be equally flawed.  A full evaluation could determine that certain features are present in a particular product (allowing it to get a “check in the box”), only to have users realize six months after implementation that they didn’t ask for what they really wanted.  Now they are stuck.

So I’m going to accept Ms. Field’s invitation and begin my education for Federal IT buyers right here and now.  There’s one thing I can say that I believe will radically change the performance of Federal IT systems and it’s this:  Stop the COTS madness!

Leading private sector companies like Amazon.com, CME Group, and Crawford have already awoken to the fact that COTS products are attractive because they seem to do all or most of what you need, but in reality they fall short.  What looked good in a demo often has great limitations in practice.  I can hear what’s going through your head right now, “So you just ask the vendor to make a change to the product to fit your needs.”  Good luck.  Buyers of COTS applications all wake up to the fact that they are just one of many customers, each of whom wants changes to fit their needs.  What’s a typical COTS vendor, who has to look out for the interests of its shareholders, going to do?  They have to make hard choices about which customers to make happy and which to leave to find their own solutions.  How do I know?  Because I’ve worked for a number of COTS companies and I’ve seen this play out many times.  I was even the leader of Product Management at some of these companies and it was my job to make the hard decisions.

Instead of coming to an RFP with a COTS mentality and a long list of requirements to check off, Federal IT buyers need to create their RFPs around these principles:

• Ease of adapting a technology to fit evolving needs outweighs any list of current functionality
• You must get economies of scale from any purchase so you can avoid additional software license costs for your next set of needs and give your users the benefits of working from one platform
• Your organization, not the vendor, must have the ability to make adaptations on their own
• Easy movement between cloud and on-premise deployment is a must-have
• Built-in native mobile functionality on all major platforms is a requirement so the need for separate mobile applications can be eliminated
• Social collaboration must also be built-in to help shorten process cycle times

These principles support the goals of the 25 point Federal IT reform plan.  When Federal buyers adopt these principles, they will find themselves drawn towards business process management technology (BPM).  Over 35 Federal agencies are already experiencing great success with Appian’s BPM software, including the Defense Information Systems Agency, FDIC, Office of the Comptroller of the Currency, FDA, FEMA, The Library of Congress, and Defense Acquisition University.  It’s time to stop the COTS madness and join them.

Want to learn more about the challenges of COTS software?  Read my white paper titled, “Don’t License Another Software Application Until You Read This!”

Evan McDonnell

Federal CIO Steven Van Roekel wants federal agency CIOs to embrace precisely that same lesson. Earlier this month, he announced finalization of the Federal IT Shared Services Strategy. This is big news, and BPM software can play a big role in helping government IT become “good sharers.”

The finalization of this strategy gives new directives (and new powers) to government CIOs to find new ways to leverage existing IT assets and programs across agencies. The essence of the goal, in Van Roekel’s words, is “to root out waste and duplication across the Federal IT portfolio.”

An IT shared service is defined as “an information technology function that is provided for consumption by multiple organizations within or between Federal Agencies.” There are three general categories: commodity, support, and mission.

CIOs have been directed to focus on commodity IT services first. This includes things like acquisition and identity/access management. Appian has government solution frameworks already available in both these areas (and others as well) that accelerate solution deployment while allowing easy configuration to fit the unique needs of individual agencies.

Even in the absence of pre-built frameworks, Appian offers a far-superior approach to that of packaged applications in establishing cross-agency services. For starters, Appian offers secure, fully functional deployment in the cloud (with easy migration on premise as needed), which is a key enabler of effective service sharing. In addition, Appian’s “configure, don’t code” approach gives agencies much greater flexibility in adapting the software as their needs evolve over time. For more on this, read our “Don’t License Another Software Application Until You Read This!” white paper.

Federal CIOs are required to act quickly on the IT Shared Services Strategy. By the end of August, each agency must submit an enterprise roadmap showing their plan to consolidate commodity IT services. As they start looking at this closely, the challenges associated with supporting multiple customers for the same service will emerge. Commercial shared services organizations and business process outsourcing companies have already encountered this in spades. Read “The Five Characteristics of Highly Successful BPM Deployments in Shared Services and BPO” for some proven best practices.

It’s always interesting to reflect on how childhood lessons like “learn to share” continue to ripple through our adult and professional lives. Now if only BPM could automate the “clean up your room” process…

Ben Farrell

The particular conference presentation highlight for me was Richard Ginman’s presentation on Defense Procurement and Acquisition Policy (DPAP) Initiatives and Efficiencies Priorities. I was already a big fan of DPAP given their recent efforts on the Procurement Data Standard (PDS) and the DoD Clause Logic service. Hearing Mr. Ginman speak just solidified my view that DPAP really understands the problems facing acquisition and is providing excellent guidance, support, and services to the DoD acquisition community.

Given the impending retirement of the Standard Procurement System (SPS), it wasn’t too surprising to hear Mr. Ginman talk about contract writing systems for a good portion of his presentation. He clearly articulated his position on SPS, calling a single contract writing system is “unworkable.” The example he provided was using your smart phone to pull down every single app available when you really only need some to do your job. He went on to explain that while there are certainly many common processes between acquisition groups, there are also many unique functions that groups perform depending on the type of acquisition work they’re doing. Mr. Ginman is less concerned about how many contract    writing systems there are, but rather about Data Standards, Internal Controls, Internal Validation, and Clause Logic.

Mr. Ginman’s views on contract writing systems match what Appian has been hearing from so many of the DoD acquisition shops we’ve been working with over the past several years. DoD contracting professionals are tired of trying to fit their processes into SPS and other rigid acquisition products they’ve been forced to use. So many times they’ve been told their contracting needs are not unique and they must conform to one system for the sake of    standardization.  But what needs to be standardized is the data, not necessarily all of the processes. DPAP realizes this and created the Procurement Data Standard (PDS) for that very reason.

Appian fully embraces the message of data standardization combined with process flexibility. Our Acquisition Business Management solution natively consumes the PDS structure and stores data in PDS format for easy reporting and sharing across government acquisition systems. And since ABM is built on Appian’s powerful Business Process Management (BPM) suite, we provide unparalleled process flexibility along with process audit, control, and validation. We understand that not all acquisitions are the same and not everyone needs to follow the exact same processes. ABM allows different groups to have different process flows while still collecting and maintaining standard data.  While some traditional acquisition products claim to have such flexibility, the simple fact is an Appian BPM based approach allows us to configure the solution to specific contracting needs in much less time and at far less expense than traditional procurement applications.

The next few years will be an exciting time for DoD acquisition systems. DPAP has laid the ground work for data standardization and paved the way for flexible solutions in the post SPS era. No one wants to see the same SPS mistakes made again by using a similar software approach under a new name. If you didn’t get a chance to see us at the eBusiness conference, we would welcome the opportunity to come speak with you and show you our solution.

-Ben Allen, Appian Professional Services

Appian is participating in two important federal procurement events in the near future: ACT-IAC Acquisition Excellence 2012 (March 29 in Washington, DC) and the Defense Procurement eBusiness Conference (April 10-12 in Atlanta).

At both events, we will be illustrating Appian’s critical value for key procurement standards, systems and trends, including:

Procurement Data Standard
- See how Appian’s product consumes and uses the PDS with no coding required.

SAM, it’s almost here
- The System for Award Management (SAM) is scheduled to be available in the first half of 2012.  Learn about Appian’s integration framework and how easy it is to add new web services to your acquisition processes.

Mobile Acquisition
- See how native Mobile BPM apps for Blackberry, iPhone, iPad, and Android allow you to access your acquisition application on the go.

Stop by our booth to learn more, and to hear about Cloud BPM for federal procurement, along with Appian DoD customer demos and use cases.

Ben Farrell

As Appian’s VP of Sales Chris O’Connell writes on AOL Government, “Nowhere is the need for improvement and reform greater than in the federal procurement process.” Chris is well-versed on the this topic, as he has been instrumental in the deployment of Appian’s Acquisition Business Management solution for customers including DISA, the U.S. Marines, the GSA and more.

The problem today, Chris continues, is that federal procurement teams “are hamstrung from being able to answer even the most basic Federal Acquisition Regulation (FAR) audit questions, in terms of the procurement and delivery of services.”

The article goes on to outline the five most crucial challenges that face federal procurement pros. Transparency and speed in the procurement process are both on the list, of course, but so are issues like ensuring that procurement processes and systems spur competition in contract bids, and using modern systems as a lure for the next generation of dedicated federal contracting employees.

The article closes with some real-world success stories of how Appian federal customers are transforming their procurement systems with BPM software.

Check out Chris’ full article.

Ben Farrell