February 22, 2010

New State Health Information Exchange (HIE) Toolkit Released

The State Health Information Exchange Leadership Forum, lead by the AHIMA Foundation with sponsorship from the Office of the National Coordinator for Health IT, has developed a comprehensive State Health Information Exchange (SHIE) Toolkit to support State HIE grantees during the planning and implementation of their statewide interoperability projects.  The Toolkit is regularly updated to include guidance, state examples, and lessons learned in the areas of Planning, Governance, Technical Infrastructure, Finance, Nationwide Health Information Network, and Grants Management.  The Toolkit will also be updated to provide sample strategic and operational plans as plans become available.

To access the SHIE Toolkit, visit: http://statehieresources.org/

If you would like some help learning how to use the toolkit please contact us at info@pubknow.com.

February 21, 2010

Can Independent Verification and Validation (IV&V) be too rigorous?

Each proposal you receive for Independent Verification and Validation (IV&V) of a software project will state the vendor’s approach is “rigorous”.  Vendors fight to explain how their methodology is more “rigorous” than a competitor.  This is what you want right?  Isn’t rigor a good thing?  Maybe, but not when rigor:

Takes over for experience. Vendors will try and bury you in details about how rigorous their process is so you’ll hopefully overlook the fact they are staffing your project with individuals that have barely used software let alone written it, performed quality assurance on it, or managed it’s development.   The truth is effective and efficient IV&V is art as much as science.  You need qualified consultants as much as rigorous process.  Make sure you examine who will staff your project very closely, asked to see the results of each individual’s previous IV&V efforts.

Is used as marketing hype.  Vendors will try and convince you they are “scientists” or “engineers” performing science or engineering on your projects/software. After all, V&V was pioneered by NASA and, for software IV&V, the base standard is defined by the IEEE (Rocket Scientists and Engineers) so who better to perform it?  IV&V is, conceptually, pretty simple:

  • Identify the products and processes to undergo verification and validation (preferably before or in the early stages of development),
  • Determine the criteria with which each of those products and processes can be evaluated (starting with standards where available e.g. the IEEE-1012-2004 standard for software verification and validation),
  • Assess the products/processes while in production and upon completion to verify they meet the predefined criteria and note where they don’t,
  • Re-assess products/processes when deficiencies have been addressed.

IV&V is hard work that takes expertise (there are many nuances in developing criteria and evaluating products etc), independence, and yes a degree of rigor.  But it’s not “Rocket Science”.  We’ve seen a significant amount of rigor added to an IV&V process that adds little value to the client and seems to be there to convince the client that IV&V is engineering and they are hiring the best “engineer”.  There is no professional certification of IV&V “engineers” like there is for electrical or civil engineers.  Don’t buy into the hype that this line of reasoning purports.  Understand you need competent, experienced professionals but this is not a mystical art.

Is used as an excuse for lack of social and political savvy of vendor staff. Beyond competence in performing IV&V your consultants need communications skills and an understanding of the political landscape public sector projects face.  We’ve actually witnessed an IV&V vendor reporting to a state legislature stating strictly facts (“the project is 2.3 months behind schedule” and “523 out of 1232 test cases failed”) without explaining context (“critical features were added” and “we’re only a quarter of the way through testing”).  The poor agency receiving the “benefit” of IV&V spent the next month trying to keep funding for what was a thoroughly successful project.  When called on the carpet about this the IV&V vendor explained that their rigorous methodology required they describe only the facts not the context of those facts.  Just what you need, Joe Friday (“Just the facts ma’am”).

Creates unnecessary bureaucracy that just wastes your money. Sign-offs of intermediate IV&V products, large review meetings, and repeated reviews of materials provide you with little value.  Often this “rigor” is applied not for your benefit but for the consultants, to ensure their rear is covered (“but you approved the interim deliverable”) or to enhance consultant cash flow (“you approved the first interim IV&V checklist so we can bill you”).  This unnecessary bureaucracy simply costs you time and money.

IV&V helps your software projects succeed and should be rigorous – meaning thorough, focused, and disciplined.  However, be aware “rigor” can be used for the wrong reasons.  When working with your IV&V consultant or the next time you’re reviewing an IV&V proposal keep in mind excess “rigor” provides little if any value; is used to cover a vendor’s weaknesses or benefits the vendor not you; and unnecessarily raises the costs of IV&V services.

February 12, 2010

Why Do Public Sector Software Development Projects Fail – Part 2?

Part 2 – Apparent Causes

In this second part of our series on why public sector IT projects fail we’re going to discuss who or what commonly gets blamed for failure.  In our unfortunately all too many postmortems of failed IT projects here’s what we typically find people saying:

Technology

Technology failed us. ”We didn’t have the right tools, We needed different software/hardware/network/programming language and we would have been ok.”  The assumption here is there is some magic technology bullet that would have pushed us over the threshold of success.  It’s possible but highly unlikely in our experience.

Methodology

Our methodology failed us ”We used ABC (insert CASE, SCRUM, Agile, Waterfall, Information Engineering – we’re old enough to have seen them all) system development and XYZ method of project management. If only we had used 123 project management and 456 system development methodology we would have been okay.”  Similar to technology the idea is that there was some magic technique that if followed would have guaranteed success.  This is usually a specious claim as most projects follow little or no real methodological discipline.  Even if followed to the letter a methodology won’t save a project that’s destined to fail.

Staff

The staff failed us. “ We used contract staff instead of state staff. If only we had used our own staff we would have been okay” or “our staff just don’t have what it takes to do a big project like this.”  Most developers are, in our experience and with good hiring practices, very competent.  Same holds for program staff.  Though there are occasions when a slick salesman provides bad resources these are usually weeded out quickly by competent management.

Vendor/Consultant

The vendor/consultant failed us.  “They said they could build a rocket ship but it turns out they couldn’t”.  OK Vendor’s do over commit.  They are in business to make money and will often promise more than they can deliver.  Was this the cause of a projects failure?  Possible but unlikely, the root of the problem was in place well before the consultant was hired.

Senior Leadership/Politics

Our own leadership sabotaged us.  “They never supported this project from the beginning!” or “The political winds were blowing against the project so they case us adrift.”  In our post mortems we’ve simply never found this the case.

The Project Manager

The project manager didn’t understand technology.  ”The manager really didn’t get the consequence of the decisions s/he was making, if only someone technical was in charge!”  or “S/he micro-managed us the whole time!”  Our reviews of failed projects have revealed many a PM who wasn’t a good project manager – but we’ve yet to see a project fail because the manager wasn’t technical enough or spent too much time with the project.

Oddly enough we rarely hear “our Quality Assurance vendor (QA) failed us.”  QA has failed on these projects.  However, their contribution to failure is rarely recognized, after all it was QA that pointed out the failure in the first place.  However, as a buyer of Quality Assurance services you need to ask where was the QA vendor BEFORE failure began, why didn’t they recognize the seed of the problem before it sprouted?…but that’s a topic for a different time.

You’ve probably guessed by now we don’t believe any of these are the root cause of project failure.  At best they might be contributory.  No matter what they are certainly a diversion from finding the real cause and instituting practices that will save the next project.

Next we’ll give you a few ideas about what the real cause of failure might be.

This is the second in a multi-part series of posts analyzing the causes of failures in public sector IT projects and proposing some pragmatic solutions.

Part 1 – Overview

February 3, 2010

Why Do Public Sector Software Development Projects Fail?

Part 1 – Overview

All major public sector enterprises have an increasing investment in software (and IT in general) and a growing need to earn a better return on their investment.  Recent studies have shown that software projects are often over budget and behind schedule.  Although studies come up with differing numbers, generally statistics show that:

  • Over half of all medium and large software projects do not deliver their expected benefit, and exceed their schedule and budget.
  • Over half of the medium and large software projects either fail completely (management pulls the plug) or require big recovery efforts to get them to completion.

Software projects, due to their scale and scope present special problems.  Management often over estimates the business improvements with optimistic delivery dates before there is a good understanding of the cost and time it will take to complete the project. User needs change, staff members move on, and the scope, schedule and budget begin to grow. The software development project soon becomes a black hole, into which the organization pours dollars and people. Agency management hears nothing but good news from project management and contractors until it is too late.  The problems start to surface and “blame game” begins; management blames the project staff, the project staff blames the contractor and the contractor blames the project staff.  The end result is a software project that is over budget, delivered late, and the business needs and quality expectations are not met.

So what to do?

This is the first in a multi-part series of posts analyzing the causes of  failures in public sector software projects and proposing some pragmatic solutions.

January 25, 2010

Now that you don’t have money you can get something done

Should budget shortfalls mean you cancel that project you’ve been planning? Counter intuitively (and with a few conditions) we say no. In our experience lack of funds actually leads to more successful projects. Without money you:

Focus on simplicity – you’re not likely to look for the “Cadillac” solution, you can’t afford it. Simple solutions tend to be easier to implement.

Encourage staff participation – you won’t be able to afford, nor will you need, an army of consultants to implement your simple solution. Your staff will have to take on added project responsibility to get things done. There’s nothing like having skin in the game to make your staff fight for success.

Use the wisdom of your own people – you can’t buy your way out of the problem so your approach likely has to be home grown. You’ll be relying on the creativity that exists within your organization to complete this project. When solutions are home grown they are easier to sell internally and generally a better fit for your needs.

Better utilize the funds that do exist – when resources are scarce you pay greater attention to them. You are forced to track every dollar spent on the project which in turn means you are likely to spend your money where it will do the most good.

Of course lack of funds will limit the kinds/size of projects you take on. You’re not likely to re-engineer your entire Medicaid system. But…what about rewriting those out-of-date procedures manuals? How about revisiting your policies? What if you could re-engineer a few of those inefficient processes? Lack of funding, while not ideal, is the reality we all now face. It shouldn’t stop your projects and can even help them to be successful.

January 13, 2010

Playing Fast and Loose with Independence on IV&V Projects.

More States are recognizing the value of having an unbiased, outside, opinion expressed about their systems development projects.  Independent Verification and Validation (IV&V – for more information reference the IEEE-1012-2004 specification) is a standardized approach to providing these opinions that States are beginning to request contractor’s use. A key tenet of IV&V is “Independence”.  That is the ability for your IV&V contractor to give you an opinion about your systems project without being biased or unduly influenced.

We have seen many “IV&V” contractors play a game with Independence.  They avoid procurement conflict of interest rules by partnering with a systems integration (SI) vendor in one State on the construction or implementation of a project and bid in another State to provide IV&V over the same SI vendor.  Technically they aren’t working for the systems integration contractor in your State but in the larger picture they do receive money from the contractor they are charged with overseeing on your behalf.  This, obviously, negates the independence they profess to bring to your project.

IV&V vendors do need to remain technically smart about system integrators, system developers, software solution vendors, and fiscal agents offerings so we’re not suggesting there be no communication.  Just that no financial relationships exists between your IV&V vendor and these entities.

So what do you need? You need a consultant who does not contract with or have an obligation to system integrators, system developers, software solution vendors, and fiscal agents that will likely bid on your projects.   You need language in your IV&V procurements that guarantees this independence.

State Budget Crisis: Perspectives from Around the Nation

Last night’s New Hour show on PBS had an excellent segment on the budget issues facing a diverse range of states.  This is worth the 10 minutes it will take to view: http://www.pbs.org/newshour/bb/business/jan-june10/budgets_01-12.html.

The video shows a few things: States ended up with budget shortfalls from similar causes and solutions involve draconian cuts to services.

Read More →