Terrapin Consulting

IT and Project Management Consulting

  • Home
  • Services
    • Project Management
    • Strategy-to-Project Alignment
    • Education/Training
    • Speaking Engagements
  • Blog
    • Archives
  • About
Home 2014 Archives for June 2014

Archives for June 2014

June 19, 2014 By PM Dom

Nothing to See Here, Move Along

Typical Status Reporting

There have been a few high-profile project failures recently that highlight the danger in status reporting. It seems many projects are reported as low risk and on schedule all the way up until the time they are catastrophic failures. There is no progression from good to bad just a very sudden failure. In fact, many (most) projects fail incrementally. Past performance IS a predictor of future performance for projects. Projects that fall behind early rarely recover and finish on time.

The first example is from the federal government’s project to develop the Healthcare.gov website to satisfy the requirements in the Affordable Care Act (aka “Obamacare”). Major government IT projects are tracked on www.itdashboard.gov. The dashboard from August 2013 (three months before launch) shows the status as nearly all green (good). The overall project rating is green and it is rated a 5 (out of 5, with 5 being the best). The dashboard includes six cost and schedule variance assessments – five are green and one is yellow. It also includes operational performance and other “investment” metrics – most are “met.”

Now, I am sure this is not the main status reporting mechanism used by the Healthcare.gov project team but this one sure is misleading – and it’s on a public website for everyone to see (this dashboard exists even today – nearly six months after the failed launch).

The second example is California’s recent payroll implementation project. The status report before its pilot program launch shows 15 areas – 14 are assessed as green and one is yellow. The pilot program launch went poorly just three months later and the entire project was suspended 11 months later.

In both of these cases, what went wrong and how did it go wrong so quickly? The fact is that neither of these projects failed suddenly – both were high risk when these status reports were published. But the status reports painted a rosy picture that may have led leaders astray as to the true status.

Filed Under: ProjectFAIL

June 19, 2014 By PM Dom

Evaluating IT Performance

Following is a process to evaluate an IT department. Similar to project management, I find that many organizations fail at some of the basics.

  1. Hardware
    • Inventory all hardware, particularly servers and their purpose (many companies don’t know what they own)
  2. Software
    • Inventory software and their purpose (look for “shadow apps”  – apps that people have been installed locally – these pose a greater security threat)
  3. Network
    • Document network architecture (vulnerabilities are easier to spot if the architecture is documented)
  4. Information Security
    • Review status of routers, firewalls, firmware updates, anti-virus software and other equipment designed for security (companies struggle to keep up with the latest versions of security devices and software)
    • Hire a company to evaluate (hack) you to determine vulnerabilities
  5. Projects
    • Document the purpose and status of every project (status of projects is likely to be worse than commonly believed)
    • Align projects to strategy (some won’t align to your strategy and should be terminated)
    • Evaluate business value for each project
  6. Help Desk
    • Review help desk statistics (software is better and people are smarter – help desk requests should be trending downwards)
  7. Disaster Recovery
    • Review the results of the latest DR test (many companies fall behind on DR testing and they fail to make changes based on the results)
    • Review the restore process (the business is frequently unaware of how long it will take to restore certain operations in a disaster)
  8. Organization
    • Review the org structure and the people in leadership roles
  9. Processes
    • Evaluate common processes for effectiveness (PM processes, security, backups, help desk, etc.)
  10. Process Improvement
    • Review the regular status reports that are used to measure and manage IT (ensure IT is measuring things that are important – not just things that are easy to measure)

 

Filed Under: IT

June 11, 2014 By PM Dom

Failure to Act: SF-Oakland Bay Bridge Project

The Sacramento Bee has a(nother) article on the San Francisco – Oakland Bay Bridge project. It details how a Chinese construction company did not weld steel girders to the requirements, potentially jeopardizing the structural integrity of the bridge. Some of the eye-opening facts:

  • ZPMC, the Chinese construction company hired to build the bridge girders had never built bridge girders before! They were awarded the contract because their bid was $250M below the next closest bid. Naturally the final cost was well over $250M higher.
  • Caltrans, the government agency in charge, allowed ZPMC to ignore both welding codes as well as contractual requirements
  • ZPMC was not penalized for failure, in fact, they were paid extra to work faster
  • Several government workers were re-assigned after pointing out quality issues
  • One lead executive for the government quit and joined a company involved in the project

The article implies government waste as government people lived quite well when traveling to China to check on manufacturing. It also implies criminal wrong-doing when it states the law enforcement officials are looking into things.

This project reminds me of the Maryland health exchange project in that an unqualified company won the contract (see here). I don’t know how government procurement officials could get this so wrong.

It also highlights one of the pitfalls in project status reporting. As noted here, even when risks are identified, leaders frequently fail to act.

Filed Under: ProjectFAIL

Twitter

Tweets by @DominicLepore

Recent Posts

  • It’s Not Micromanagement
  • Benefits Realization
  • Why PMP?
  • Active Learning in the Classroom
  • How Not to Design a System

© Copyright 2014 Terrapin Consulting LLC · All Rights Reserved · Powered by WordPress &middot