Agile Scope Management

Insurance company uses agile methods to limit scope of software requirements and then increases frequency of releases to build out the appropriate business capabilities, giving IT's customers an opportunity to iteratively describe their key requirements. ...

... "Keith Young, IT director at Standard Life, oversees approximately 500 programmers, and said the agile approach minimises the risk of an application not meeting business requirements. " ...

Via ComputerWeekly: Agile software development

Portfolio Management: Lessons from the Super Bowl, Continued

If you are going to make investments from the high risk, high return segment of your portfolio, you better have the stomach for it. ...

Adoption Risks with Innovation Projects

Whether you are implementing a fundamental new innovation or providing a new way to do things, cultural adoption is a risk you can't overlook. Considering your change management strategy? Do you promote methods that drive addiction or use Frankenstein to your advantage? Read on for some insights. ...

... "Great innovations have foundered over human stubbornness. ... Resistance to technology is an omnipresent risk for every innovator. " ...

Via New York Times: Risk

Project Business Case: Shock and Awe with Value

Enhance your business case with a compelling story and value statements in the language of your business. While the solution is important, keep the technical details to a minimum. ...

... "Decision makers don't want to hear about bits and bytes. IT managers need to talk to them in terms of achieving business value and reducing risk, said John Cash ... " ...

Via IT Business, Canada: Project Approval Process

Resource Planning for Project Success

IT services organization, Parity, sees resource planning as an opportunity to position projects for success. Their whitepaper offers advice that includes a thorough planning period, setting appropriate resource durations to support sourcing arrangements, and a disciplined approach to recruiting project talent. They see shortages in skilled IT resources as a strategic challenge confronting the IT space. ...

... "Failure to get IT resource requirements mapped out adequately is undermining the chances of IT projects succeeding and raises the risk of projects going over time and budget warns Parity ... " ...

Via Parity: Inadequate resource planning puts projects at risk

Project Transparency and Oversight

High-risk government IT projects are on the rise as federal project managers share the facts on their projects. This is a good thing as there's significant investment at risk. ...

... "OMB attributed the increase to better oversight of the projects and better reporting. " ...

Via FederalTimes: Project Management

Project Team Event: Museum Field Trip

Here's an interesting museum you can take your virtual team to. See any familiar items? ...



Pocket Protector Collection

Real World Project Management

There's a good interview on Projects@Work with Susan Snedaker, author of How to Cheat at IT Project Management.

Some key points (paraphrased):

• At status meetings, focus on outcomes instead of endless discussions on issues.
• To insure risks aren't overlooked, appoint a "risk management" person on your project team and/or specify checkpoint milestones on your project.
• To control scope, use past lessons to remind stakeholders of the potential impact of scope creep.
• If you don't like dealing with people ---- well, get out of project management (or at least take a more specialized role on projects).

All good points! Here's the interview...

http://www.projectsatwork.com/content/Articles/236152.cfm

Project Business Case: Watch List

Feds make progress in managing down project gaps as watch list volume decreases. ...

... "The management watch list highlights weak business cases for hundreds of government IT projects. The projects are considered at risk because of deficient acquisition strategies, poor data security measures or flawed design plans. " ...

Via Federal Times: Project Business Case and Watch List

IT Project: Cutover Preparation

Mergers and acquisitions are common in today's markets. These corporate marriages often come with consolidation and integration. Eventually, information systems are consolidated. When systems touch customers, our risk antennae should perk up and we should prepare to minimize business impact. Preparation includes planning, temporary resources, a command center, practice through rehearsing, etc. Read about USAirways post-acquisition preparation for cutover to its common reservation system. ...

... "US Airways has been prepping for the mammoth IT project since the America West-US Airways merger closed in September 2005. " ...

Via Arizona Republic: US Airways IT Integration

Update: Via Bloomberg: USAirways Cutover Issues: "US Airways' kiosks at Charlotte and four regional hubs couldn't communicate with the reservation network for several hours after the systems were unified ... "

Project Management and Driving: Staying Tuned In

It had occured to me the other day that project planning is a lot like driving a car. If you constantly look down at the road in front of you, you won't be prepared if traffic suddenly stops or changes pattern. It's better to look out at the near horizon.

And if you listen to the radio for the traffic reports, you'll be able to avoid problems before you even see them.

It's the same with project management. We need to focus on the current planning horizon as far as we can reasonably see (usually we can only see three-to-six months out with any degree of accuracy). And it's equally important to stay "tuned in" through networking, reading what's happening in your organization and the world, visiting your customers and stakeholders, and practicing MBWA (Management By Wandering Around).

The more we're tuned in to internal and external activities that could impact the success of our projects, the better position we'll be in to address problems proactively and head off a traffic jam or a change in pattern.

Project Management Quotations

Here's a Wiki Quote site with a number of project management quotations. Despite some tired and well worn ones, there are a few gems in there, such as:

"The bitterness of poor quality last long after the sweetness of making a date is forgotten."

"Some projects finish on time in spite of project management best practices."

"The more ridiculous the deadline the more money will be wasted trying to meet it."

"The most valuable and least used phrase in a project manager's vocabulary is "I don't know"."

"The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression."

"The project would not have been started if the truth had been told about the cost and timescale."

"You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it."

"All project managers face problems on Monday mornings - good project managers are working on next Monday's problems."

"At the heart of every large project is a small project trying to get out."

"Everyone asks for a strong project manager - when they get him they don't want him."

"Good project managers know when not to manage a project."

"If you don't attack the risks, the risks will attack you."

Enjoy...

http://en.wikiquote.org/wiki/Project_management

Project Management Imperatives: Ten Keys to Success

Someone recently asked me what I felt the critical success factors were for any project (i.e. what were the top "must do's"). Although I can think of many more, here were what I felt were the top ten:

1) Get the roles right. (Insure accountability; use a RACI chart or Responsibility Matrix so roles are clearly defined. Insuring people understand their commitments up front will avoid problems later.)

2) Get the goals right. (Make sure all the key stakeholders agree on the goals. I've seen more projects go wrong for this reason than any other. Time spent here will pay dividends later.)

3) Get the current scope right. (I say "current scope," because change should be expected. Projects by default contain change because they are unique in nature. It's not whether you'll experience change, it's how you analyze the potential impacts and manage the approval of the change that counts. Agreed-upon and approved scope changes are perfectly acceptable, with one caveat: It's often wise to set a limit to the number of times scope can be changed for the current product release, and defer some changes to a subsequent release, else value gets delayed.).

4) Obtain commitment from the business, customers, and other stakeholders as to their part in the success of the project. (Many projects derail because the customer doesn't live up to their side of the bargain, doesn't understand their side of the bargain, or some other necessary constituent isn't cooperating for various reasons. Obtain the right commitment up front, starting with senior management.)

5) Determine the critical success factors and risks. (Critical success factors and risks go hand in hand. Many people ignore this or sweep it under the rug, and accept any related risks as a given. The critical success factors will identify related risks and help set expectations).

6) Set expectations. (This is frequently overlooked and is a key cause of failure. The sponsor, customers, and anyone impacted by the project must be given realistic expectations for what is needed from them, how long the project will take, how much it will cost, what the uncertainty factor is, what the available resources are, and anything else necessary to avoid surprises and/or an under-equipped effort.)

7) Beware of conflicting directives. (I call this the "Robocop Syndrome." In the film, Robocop, the titular robotic policeman goes on full tilt when he encounters directives that conflict with his primary directive. I see this happen often in organizations where a project sponsor demands something that is in conflict with other key stakeholders' wishes and/or top organizational directives. This could be covered under "goals" or "expectations," but it's so important that it warrants its own point. The project manager must head this off at the pass before the project goes down a rat hole it won't recover from.)

8) Plan Collaboratively. (The act of planning is not an isolated exercise. It's a collaborative exercise and should be done with the project core team and subject matter experts via some sort of facilitated brainstorming session---possibly with sticky labels on a wall.)

9) Beware of unilateral and granular "one-size-fits-all" solutions. (This is often ineffective, both as a project management methodology and a process implementation policy. Look at the big picture, and the potential variations. Keeping a framework high-level can allow for greatest flexibility and adaptability. Aim for principles over rules wherever possible. Use rules when safety is involved, regulatory requirements exist, or exact accuracy is needed---per Marcus Buckingham's guidelines from "First Break All the Rules.")

10) Don't let rank set you off course. (Often, a senior manager pulls rank and makes requests that are either detrimental, unwise, or in direct conflict with organizational goals. When this happens, see rules 6 and 7. It is the project manager's responsibility to set the right expectations, warn of potential risks, and head off potential conflicting directives at the pass.)

There it is. My list of "must do's." Project management isn't rocket science. In fact it's not a science at all. It's more of an art. Hopefully, the guidelines above can serve as a useful palette.

Business Results: IT Strategy

Today's IT career path requires evolving your role into a challenging place - the potential to impact business results - which comes with its set of risks. However, standing still increases the risk of outsourcing, or worse yet, irrelevance. ...

... "If they're not in the decision-making stream, playing some role that's accountable for real results from IT strategy, even on a very local, project level, they're at greater risk both to outsourcing and stalling wages. They need to work themselves into a position that's closer to business results and end customers. " ...

Via InformationWeek Weblog: Read

Olympic IT Project: Risk Management Challenge

Atos project team will manage the Olympics IT project for Vancouver games. It manages risks by leveraging accumulated knowledge and experience forward. Lesson learned, knowledge transfer, sustaining core team members, and scaling high-performance teams are all ingredients of successful Olympic technology events. ...

... "In June 2006, only months after completion of the Torino 2006 Winter Games, Atos Origin dispatched IT managers and engineers to already start working on the Vancouver project. Currently the size of the Atos Origin IT team in Vancouver is around 15 but the team will grow rapidly over the next couple of years. During the 2010 Winter Games, Atos Origin will manage the technology consortium team estimated at 2,000 staff, including 400 Atos Origin experts, made up of locally hired staff, local volunteers and overseas Olympic Games technology experts.

The complex, massive IT infrastructure of the Olympic Games is deployed by large teams of people into different cities in different countries every other year. Such a major task is all about risk management capitalizing on the knowledge gained from previous Games Operations. This knowledge and experience transfer is critical in keeping costs down and in lowering the risk of future Olympic Games. " ...

Via Atos Origin: Atos Origin IT Team already in place for the Vancouver 2010 Olympic and Paralympic Winter Games

Project Management Training: Foundation For Success

With federal IT investment slated to increase, info technology professionals in government would be well-served by training in a foundation of project management basics. ...

... "officials interviewed for the study said their teams lacked or may lack sufficient training to effectively estimate costs, identify risks and develop baselines from which to plan project costs, schedules and technical requirements. " ...

Via Federal Times: Link

Brainstorming Power: Apples and Ideas

George Bernard Shaw once said:

"If you have an apple and I have an apple and we exchange these apples, then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas."

This illustrates the power of using brainstorming techiques to generate ideas. For example, using the "Crawford Slip" technique, let's say we had ten people in a room and asked each to take one minute to answer, "What are the top three risks on our project?" Then we ask the same people to take another minute to answer the same question, except they can't reuse the same answers.

Let's say we did this for ten full minutes. We'd generate 300 potential ideas in ten minutes! Sure, there'd be some overlap and sure people might run out of ideas after a few rounds, but still there'd be well over 100 ideas in ten minutes.

Now imagine the magnitude of power when each person in the group learns about all the group's collective ideas for potential risks and then considers them on future projects. The power of brainstorming is exponential.

Project Risk Management

Oil production company, Venture Production PLC, uses risk management software to model project scenarios to select optimum schedule while balancing risks, costs, and time performance. This seems a worthwhile approach, when large investment is at stake and time to value is critical. ...

... "Using Pertmaster, Venture's project management team was able to add a risk dimension to plans built in its Primavera P3 scheduling solution. Venture then analysed the schedule-risk of multiple scenario options to look at the most probable outcomes of each, in terms of both timescales and costs. This enabled the best options to be highlighted when considered from both likelihood of risk occurrence and degree of impact and enabled management to take well-informed decisions. " ...

Pertmaster Helps Bring Venture's New Oil Field On Stream ...

Venture Operated Goosander Field On Stream: "Goosander has been developed as a sub-sea tieback to the Venture operated Kittiwake platform utilising two subsea flowline bundles totalling 12 kilometres in length. The bundles were manufactured and installed by Subsea7 from their construction site in Wick and have been designed and engineered to accommodate future production and water injection wells and the potential for re-use on future subsea tie-backs. "

Major Project Failure: Lessons Learned

There's a good article in Computerworld from Michael Hugos about lessons learned from a major failure.

Three key takeaways from the article (which happen to ring true with what I've been preaching for years) are:

1) Have clearly defined goals and measurable objectives
2) Be sure to have one single leader driving the project
3) Implement in fixed iterations to assure quick wins, earlier benefits, and reduced risks

Here's the full article...

Lessons learned from a major failure

Einstein Project Management Tip #5: Imagination Counts

Our next project management tip from our Einstein series regards the need to challenge the status quo----to think out of the box. Consider this quote:

"To raise new questions, new possibilities, to regard old problems from a new angle, requires creative imagination and marks real advances in science."

Of course, Einstein also famously said, "Imagination is more important than knowledge." To a project manager, who's typically focused on things like scheduling, monitoring, reporting, and driving the team to completion, this can be a particular challenge. But it's important nonetheless.

Imagination is required in many situations, including (but not limited to):

• Achieving success when the odds are against you
• Conceptualizing ways to achieve the objectives more effectively
• Brainstorming solution ideas and possible risks
• Overcoming barriers, whether political, technical, or physical
• Improving the cusotmer experience

For some practical advice on building the right team for innovation, see my blog series on Tom Kelley's The Ten Faces of Innovation.

More to come.

Einstein Project Management Tip #2: Think Flexible

In keeping with our Einstein theme, here's our next project management tip from the great thinker himself.

"As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality."

While Albert Einstein was referring to the laws of mathematics, surely this applies equally to project plans. We lay out in fine detail what we think is the ultimate plan that supposedly reflects reality. We make what we think are valid assumptions. Then, the minute it is published, things change. Life has a habit of doing that, despite our best intentions.

But we still need to go through the act of planning if we are to think through the risks and have a good chance at success.

Therein lies the paradox. We need to plan, and then we need to constantly revise the plan to match reality. Then we need to plan again. It's a continuous iterative process of course-correction. Perhaps it's why Eisenhower said, "Plans are nothing. Planning is everything."

For most projects, the old adage,"Plan the work and work the plan" should be taken in a different context than its original intention. We need to plan the work, and then we need to "work the plan" (meaning "continuously adjust the plan so that it remains adaptable") , as opposed to merely working "to" the plan.

Stay tuned for more Einstein project management tips.

Strange Project Risks: Mystery Woodpecker Halts $320 Million Project

Here's one that probably won't turn up on anyone's project risk template. The $320 Million Grand Prairie Irrigation Project, being led by the Army Corps of Engineers in Arkansas, has just been put to a halt by a federal judge because a rare, thought-to-be-extinct (and maybe still extinct) woodpecker was allegedly sighted two years ago.

The ivory-billed woodpecker was apparently spotted by a kayaker in 2004, which triggered a series of petitions and lawsuits by environmentalists to stop the project. The bird hasn't been seen since. Of course, I'm sure there are environmental issues beyond just the woodpecker, but the woodpecker seems to be the driver behind the decision.

According to the Houston Chronicle, about $80 Million has been spent so far, with a goal of delivering water to farmers by 2010 or 2011.

Here's the story...

Woodpecker Halts Ark. Irrigation Project - NEWS - US NATIONAL - Comcast.net

Project Management Lessons from Mars

Brian Muirhead, the project manager for the Mars Pathfinder program, had some good tips to share with Projects@Work this week.

Some key learnings, extrapolated from the interview:

• Innovation and bold ideas are often necessary to meet what often seems like an impossible challenge. The trick is to balance the cost and time savings with the risks.
• A diverse team is key. It's better to have people that are different, with complementary skills, than have a bunch of people who think and act the same way.
• A small core team that can share issues, problems, and resolutions, with one person at the helm, is an effective way to run a project.
• Trust, honesty, and personal committment are traits that need to be prevalent throughout the team.
• Test, test, and then test again. Don't rely on luck. If you can't test using the exact situation, then simulate it as best you can, testing as much as is possible.
• A team is only as good as it's weakest link. It's up to the project leader to identify those people that aren't up to the task and remove them or find an area that suits them better.
• Ensure team members have opportunities to make personal connections and grow.
• A project manager must simultaneously provide the glue (keeping the team cohesive and focused) and the grease (removing barriers).
  
  Here's the full interview...
  
  http://www.projectsatwork.com/content/Articles/232113.cfm

One-Page Project Status Report; Keeping it Brief

There's a great writeup in Projects@Work about project status reports, including tips on meeting format and frequency as well as a format for a one-page status report.

According to the article, there are 5 Project Status Best Practices:

1. Consistency — The status process should be basically the same for large and small projects, and consistent with their measures of success
2. Escalation — The status process provides a mechanism for escalation of key issues.
3. Simple — One page with the ability to drill down for details when necessary
4. Public — Status is available to all (as appropriate) in order to communicate issues, risks and corrective action measures
5. Inclusive — All projects are required to provide status on a consistent set of metrics

For busy managers who see loads of project status reports, it's much easier to have a consistent, brief summary of what's really happening on each project. They don't need a dissertation on all the details, nor will they get a clear picture just looking at performance metrics. Much like on a business case, most just want the executive summary. Simpler is better. Less is more.

For those looking to improve their status reports (and their credibility with management), read on...

http://www.projectsatwork.com/content/Articles/231704.cfm

Project Risks; Let's Talk About the Weather

When doing risk planning for your project, don't forget about seemingly off-topic risks, such as the weather, or the season of the year. It's an obvious concern if you're in the construction or farming industry, but in many other organizations, timing your project rollout to avoid quarterly closes, the company's peak season, or any other major seasonal events, can make or break your project.

I've heard of one popular confection organization that couldn't ship candy during Halloween because of a problem with their new SAP implementation. Bad timing. Another company that dealt with agriculture had to have a project completed before the summer growing season. They were smart enough to list that as a constraint.

The seasonal elements didn't just affect Napoleon in his failed Russian campaign (and many before and after him). It can affect those of us in business as well.

Project Management Lesson from Carpenters

No, not the brother and sister duet, I'm talking about real carpenters. There's an age-old axiom used by carpenters: "Measure twice, cut once." Experienced carpenters know that there's no turning back if you made a mistake measuring once the wood is cut.

This is good advice for project managers as well. Many errors, and many hours of rework, can be avoided if you take the time up front to do the proper research, planning, and risk analysis. It's well worth checking your plan twice, even though circumstances are likely to cause you to deviate from the plan. But even those risks can be mitigated with proper research and meditation up front.

Just like carpentry, the later mistakes are caught, the more costly and devastating they are likely to be. It's better to spend a little extra time up front on your projects to increase the overall speed and success of the project.

Join the Project Management Revolution; The SOPM Model Takes Shape

OK, I've been fleshing out the Service-Oriented Project Management (SOPM)™ model, and have come up with a more memorable and catchy representation of the four steps, although the actual content is pretty much the same.

The acronym for the four phases is UP-IT (which can symbolize "upping" the level of customer service, saying "up yours" to old ways of doing things, or "upping" the success rates of IT projects---in which case the "it" stands for "IT").

Ready??? Drum roll please......

The four phases are:

• Understand
• Prepare
• Iterate
• Transform

Here's a revision of my previous post on the topic...

1) UNDERSTAND ... Develop an understanding of the problem being addressed, the goals, constraints, the internal environment, the external market, benchmarks, the people and subject matter involved, potential solutions, risks, benefits/justification, and any other knowledge necessary for success. Most of all, understand the customer and what they need to be successful.

2) PREPARE ... After helping the customer obtain approvals if needed, prepare the project organization (resources, roles & responsibilities), operating principles, the infrastructure and tools needed to run the project, organizational alignment, preliminary training needed, communication, and anything else needed for a smooth road ahead.

3) ITERATE... Using the axiom, "Think bold, implement safely," plan, design, build, test and pilot the solution before attempting a full scale implementation. Encourage innovation. Implement in phases to achieve quick wins, earlier benefits, and greater customer satisfaction. Consider iterative prototypes during the design phase. Don't forget additional training needed.

4) TRANSFORM... After each project phase and at the end of the project, evaluate and document lessons learned, customer satisfaction, and benefits achieved (vs expected) for the purpose of transforming yourself and the customer for the better. This includes guiding the customer to help them achieve maximum results with the product or service delivered, and laying the groundwork for their continued success.

Now that I have the framework locked in, I'll complete the model around these four phases. I am absolutely convinced that this model can help increase customer satisfaction and the general success rates of projects.

SOPM; A New Project Management Methodology

Service Oriented Project Management (SOPM) is taking shape as a methodology that fills the gaps in traditional project management, namely a RELENTLESS customer focus and the all-important analysis and benefits evaluation after the project has "completed."

As I fine tune the model, I'll post the iterations here, as a methodology in progress.

The four high-level steps in SOPM are as follows:

1) UNDERSTAND ... Develop an understanding of the problem being addressed, the goals, constraints, the internal environment, the external market, benchmarks, the people and subject matter involved, potential solutions, risks, benefits/justification, and any other knowledge necessary for success. Most of all, understand the customer.

2) ENABLE ... After helping the customer obtain approvals, prepare the project organization (resources, roles & responsibilities), operating principles, the infrastructure and tools needed to run the project, organizational alignment, preliminary training needed, communication, and anything else needed for a smooth road ahead.

3) ITERATE... Plan, design, build, test and pilot the solution before attempting a full scale implementation. Implement in phases to achieve quick wins, earlier benefits, and greater customer satisfaction. Consider iterative prototypes during the design phase. Don't forget additional training needed.

4) EVALUATE... After each project phase and at the end of the project, evaluate and document lessons learned, customer satisfaction, and benefits achieved (vs expected). This includes evaluating how the customer can achieve maximum results with the product of the project, and laying the groundwork for their continued success.

By using an UNDERSTAND, ENABLE, ITERATE, and EVALUATE process, with COMMUNICATE as an overarching activity that extends across all four steps, we adopt a much more holistic and customer-centered approach to project management.

A few key points... Customer satisfaction should be measured at milestones throughout the project, not just at the end. It's as important as monitoring cost and schedule (i.e. Earned Value performance).

Imagine seeing an S-Curve showing Planned Value, Earned Value, Actual Cost, and Customer Satisfaction. Maybe your project is on schedule and on budget, but the customer isn't satisfied with the results (or with the project communication, or a whole host of other issues).

A narrow focus on cost and schedule takes too much of an inward view. Besides, measuring customer satisfaction throughout a project allows for corrective action instead of managing in the rear view mirror.

More to come.

NOTE: I have since revised this model. See my updated entry.

IT Governance Conference: Enron Watchdog Keynotes ...

Sherron Watkins, Enron, keynotes at upcoming IT governance conference ...

... "According to the IT Governance Institute (ITGI), IT governance is now considered as critical a board and management discipline as corporate or enterprise governance. Effective IT governance helps to ensure that IT supports business goals, maximizes business investment in IT, and appropriately manages IT-related opportunities and risks. Such risks include legal and financial consequences stemming from non-compliance with corporate accounting legislation; namely, the Sarbanes-Oxley Act.

One key figure recognized by TIME magazine for her courageous actions during a high-profile corporate scandal that triggered the landmark Sarbanes-Oxley Act is Sherron Watkins, former Enron VP. Pink Elephant is pleased to welcome Ms. Watkins as one of the symposium’s keynote speakers. " ...

Via Pink Elephant: Sarbanes-Oxley Challenges Meet IT Best Practice ...

High Risk and Reward Projects Enabled through Partnerships ...

Oil and gas company, Encana, manages risks in unlocking the value of hydrocarbons from oilsands bitumen. The company will partner to realize the value of its assets from high risk / reward projects. ...

... "Regrouping from that defeat, EnCana is busy on Project Apple, with associated files codenamed Granny Smith, McIntosh and the like. The company has said it assessed more than 20 proposals from potential partners. " ...

High Risk and Reward Projects Enabled through Partnerships: Via globeandmail: EnCana puts the polish on Project Apple ...

Project Failure Case Study; Maine's Medicaid System

Talk about a project disaster. As reported in an excellent article in CIO Magazine, the Maine Medicaid Claims System project is a case study of a project gone awry.

The project was undertaken to switch from their legacy systems to a new web-based system to process Medicaid claims and facilitate HIPAA compliance (Health Insurance Portability and Accountability Act of 1996). As a result of the failed project, Maine is now the only state in the union not in compliance with HIPAA.

System problems led to many claims ending up in limbo, leading to hundreds of calls from health care practitioners, nearly 300,000 patients being turned away, several dentists and therapists going out of business, and destroying Maine’s finances and credit rating.

So what went wrong?

Mistakes included the following:

• Deciding to develop an entire system from scratch using unproven technology, while other states built a front-end onto their legacy systems
• Caving to pressure from management to meet tight deadlines with inadequate resources instead of pushing for a realistic plan to begin with
• Failing to notice why other bidders either didn’t bid or came in way higher (a sign that the schedule was unrealistic)
• Hiring a vendor with no experience in developing Medicaid claims systems because they were the lowest bidder
• Not having a Medicaid expert on the team, leading to errors in judgment
• Underestimating the time needed to meet with subject matter experts
• Competing with another major initiative (a department merger) for executives’ attention and resources
• Skipping project management basics (including piloting, adequate end-to-end testing, staff and user training, etc.) due to looming deadline pressures
• Failing to stop, regroup, and analyze the risks
• Taking a “big bang” approach to cutover with no contingency or backup should something go wrong

Management’s response, of course, was to switch program managers, and issue stronger demands to have a smooth system, but none of the changes or demands made much of a difference. Consultants were brought in to prioritize the many problems, but still, the complexities proved too much. It wasn’t until a Medicaid expert was brought in that things began to gel.

Like many project failures, it’s easy to point to the project management (and certainly there are many shortcomings there in this case), but the organization must share the blame as well if it insists on unrealistic deadlines and leads by fear (fear of shareholders, fear of competition, fear of management, etc.). None of these variables can make an unrealistic schedule more realistic.

It's really very simple. Either adequate resources must be committed, the expectations lowered, or a more piecemeal approach taken (or all three, if applicable). In any case, the schedule must be realistic and risks need to be managed.

Here's the full article. It's well worth reading, as are the reader comments.

Maine's Medicaid Mistakes - Editorial - CIO