Showing posts with label IT systems. Show all posts
Showing posts with label IT systems. Show all posts

Monday, March 31, 2014

Comparing Federal IT Systems against Commercial Systems: JUST STOP IT!




Every week or so some pundit, politician, or professional writes an article about how the Federal government ought to acquire IT products or services like private industry does.  I believe that idea to be niaeve and irrational. It betrays these folks’ ignorance at best, or political and business motives at worst. There are too many differences between the private versus public purposes, environments and challenges to enumerate, but I’ll discuss some of them below.   

But first, these folks make the false assumption that private industry is more successful at IT projects than are the Feds.  One needs only to read the Standish Group’s annual Chaos Report http://www.csus.edu/indiv/v/veli...
It reports on IT project failure rates and problems in both the private and public sector.  But even this excellent source is dependent on the private sector to volunteer information about their failures.  The press, public and Congress don’t know how many private sector IT projects get strangled quietly in the crib, or buried without a eulogy.  No one knows how many private projects are late, over budget, under functioning or otherwise not meeting the original plan.  So these pundit types need to just stop blindly believing the propaganda and puffery from those who seek to profit from selling IT system development services to Federal agencies. The media pundits need to look for evidence supporting the claims of the ‘private-is-better’ notion.

But let’s explore that ‘private-is-better’ wonderland a bit.  Let’s assume that private industry develops their IT systems better, faster, cheaper than the Feds develop theirs.  What are these systems doing? I hear politicians mention what they apparently believe are comparable systems…. Google; Amazon; Facebook; iTunes; or … which ever.   ‘If Amazon can get your stuff to you in a few days, why can’t Obamacare let you ……blah..blah..’ 

Compared to the functions most Federal IT systems need to perform, these commercial transactions are trivial.  Not that they don’t perform their functions extraordinarily well, but they’re just trivial.  Most of their public-facing transactions are no more than some combination of: 
1.   sign in or sign up 
2.   browse or search
3.   choose from what’s listed
4.   type in a sentence or two (maybe)
5.   give credit card & address (maybe);
6.   Click DONE!  

They don’t really care who or where you REALLY are …… only that the credit card is good and a password/email pair is valid.  

If the ‘private-is-better’ crowd intends to compare private company internal IT systems (finance, HR, accounting, sales or other business functions) these systems are also trivial in comparison to the realities of (Federal) government systems.  Their systems can be built or rebuilt according to the company’s current needs and carry over whatever legacy functions they need to.  In other words, the company can redefine what it needs, jettison what it doesn’t and buy or build what they need. They can follow whatever ‘standards’ they desire (or none).  They can be as careful in handling data and security or as loose as they dare.  They can also roll out these functions at whatever pace is appropriate.  Of course they do, or don’t do these things at their own risk and peril.

In the (Federal) government sphere, agencies and program managers (PMs) have no such ‘freedoms’.  They operate under a totally different set of business rules, mostly driven by Congressionally developed and Presidentially signed legislation and the subsequent translation of the legislation into regulations and procedures… only after the public and commercial entities and lobbiests have provided their input and commentary.  

The agency PMs also operate under procurement rules wherein they can’t just PICK a contractor that the agency likes and trusts. There is a formal public process that governs advertising, specifying the need and giving the marketplace an opportunity to compete to fulfill the requirements.

Even though there are government regulations that constrain some private activities (e.g. various disclosure documents for publicly traded companies). Most private companies building systems do not have congressional actions that impinge on their technical direction and approach, nor do they typically have an unstable set of new/changing executive appointees to contend with.  Nor do they have complex rules and regulations created out of the legislative, rulemaking, legal and public input processes.

In most non-trivial transactions with the Federal government, there are many issues that private sector systems do not address, except in a limited way.  Using Social Security or Medicare or some other claims processing or tax system as a point of illustrating the unique complexities of government systems it becomes obvious that these systems are much more logic and data-centric, pulling from many different sources across organizational boundaries.  A sampling of the issues that the Fed IT world worries about that the private sector typically don’t ---are issues such as:
·      Are you who you say you are? - and how does the agency establish and verify that electronic identity with extremely high accuracy.  Or even when doing a transaction in person, depending on the size and nature of the transaction, great lengths are taken to ensure accuracy of government-known information compared to the in-person representations
·      If you are conducting a transaction for someone else, what is your relationship and legal authority to do so?
·      If you are applying for some kind of disability benefit, you need to provide medical, financial, educational, work history, and other evidence to enable the government to determine your eligibility for a benefit.  And …the government needs to be able to receive, track, validate and associate all of this information with a specific “case”/individual.
·      If you are applying for some kind of educational benefit, you need to supply statements and data about yours and your parents’ financial condition, history and income.

I’m not saying that private sector companies do not have sophisticated, complex systems.  What I’m saying is that those that do, are able to do their business OUT of the public eye (so we don’t know how successful they are), and those that don’t have sophisticated systems… even the ‘trivial’ retail systems have ties to inventory, accounting, buying and delivery systems…. But they are not typically operating across organizational boundaries.  Verizon has still not consolidated their various billing and account systems across ex-NyNEX and all of their acquisitions and business unit consolidations – and they are a ~$24 Billion enterprise  ($21B-wireless $3B-wireline revenue).

So the pundits, pols, prevaracators, just need to examine the reality of Federal IT systems…. And just STOP THE SILLY, ILL-INFORMED, HEADLINE-GRABBING RHETORIC.

Friday, December 27, 2013



Federal Contractor Games Part 3: Can an IT contractor be your PARTNER? – Estimating Level of Effort (LOE)

 This is the third posting on federal government–contractor ‘partnerships’ for IT work.  In the last few days I’ve seen more discussion and marketing of these types of relationships. President Obama’s comments on fixing the procurement system for IT are likely to spur more agencies to seek ‘partnerships’. For the agencies contemplating such a relationship I hope that they get some take-always from this series.  But more importantly, they need to seek the lessons learned from agencies that have already engaged with “partnerships”.

  In these relationships, the agency expects to get a good product at a fair price.  The primary driver of price is typically the labor content of an IT development project. Another tactic that a profit-seeking contractor may attempt to use in partnering relationships with Federal IT organizations lies in the proposed Level of Effort (LOE) for an undertaking.

Estimating effort for tasks and projects

  In a partnering relationship where there is no immediate or continuing competition wherein there is pressure for ‘honest, or bare-bones LOE estimating’, the agency needs to figure out how to independently assess a proposed level of effort for a task or project.  All contractors have their own staffing and pricing methods or models.  The agency must either have it’s own models for estimating LOE or must ensure that it can use the contractor’s model and duplicate results.

Typically these models are driven by parameters such as estimates of: complexity; function points; number of interfaces; number and type of users; response time; and the nature of the system (reporting, real-time, web-based, compute intensive, and many other types).  So, unless the agency understands the inputs to the model as well as how the model calculates the LOE, there is potential that the contractor/partner will ‘overload’ some of the parameters to bloat the LOE beyond an objective set of parameters. 
 
A good approach would include the agency having an agency person or team versed in several models which they would use to develop the agency’s own estimates of LOE.  Some of the commercial models use a database of past projects for comparison, others use algorithms that have been derived from past industry experience.  Each approach has its pros and cons, and produce differing results.  An agency should use multiple types to establish a probable RANGE of LOE, rather than a POINT estimate of LOE.  Since ALL of the parameters that drive the models are ESTIMATES, the agency needs to establish upper and lower bounds, and use that range against which it would compare the partner-contractor’s estimates.
  A ‘too low’ estimate from the partner can be more worrisome than a ‘too high’ estimate.  A low estimate probably indicates a lack of understanding of the requirements, and will lead to problems during development (e.g. corner cutting: using lower qualified/cost staff, skimping on essential steps such as testing).  A high estimate may also indicate lack of understanding but provides padding the LOE to cover the risk.  In either case, the agency itself needs to have a deep understanding of the target system’s internal technical characteristics. 

To paraphrase a friend and colleague “You can’t outsource your thinking”.

P.S. The software estimating models that we used on most projects included: SLIM, PRICE, PRICE-S, @Risk, COCOMO, but there are many others.  An agency should develop expertise in several.

Leave your email above to receive new postings

Monday, November 18, 2013

Healthcare.gov system: how could it go so badly?

Project management professionals and pundits long-ago described PHASES of projects as:

1. Wild Enthusiasm
2. Disillusionment
3. Panic and Hysteria
4. Search for the Guilty
5. Punishment of the Innocent
6. Praise and Honor for the Nonparticipants

I suspect that the CMS Healthcare.gov project is currently in phase 3, and will move to phase 4 on December 1 when we all discover if the panic & hysteria paid off with a good-enough website and adequately functioning backend subsystems that feed it.

But how could such a high-profile system (POTUS bet his presidency and legacy on it) go so wrong, with so little warning before "DAY 1"?

This blog will focus on the many, many reasons that projects…. particularly Information Technology-based projects fail so often.  The Standish Group publishes the CHAOS REPORT each year that provides insight into IT project failures in small, medium and large organizations.  The larger the organization, the higher the failure rate.  Standish has reported that ~30% of projects get cancelled before completion; ~50% overrun their budgets by ~200%; while only ~16% of projects are realized on time and on budget.

Follow this blog for more exploration of contemporary human - automated system struggles.