Category Archives: project management

Healthcare.gov: Why Washington State eclipsed Washington DC

eclipsedLike the Mariners’ string of depressing seasons and lost opportunities, this month’s botched rollout of the federal Department of Health and Human Services (DHHS) healthcare.gov website represents a huge lost opportunity for the federal government. And some of the root causes of these two fiascos are amazingly similar.

Washington state’s own, separate, health benefit exchange registered phenomenal success, enrolling over 35,000 people in three weeks.

How can one state succeed where the federal government, with all its resources, cannot?

Read the rest of the article on Crosscut here, including 34 comments.

Advertisements

1 Comment

Filed under Fedgov, management of technology, project management

– Overpromise and Underdeliver?

IT Project Successes?

Information Technology Projects

Why do we consistently promise too much and then fail to deliver on information technology and other government projects?

The project mantra is clear: “scope, schedule, budget”. But how we actually do the planning, estimating and getting approval to start a project … well that’s the horse of a different color.

We promise the moon – “Project Widget will be the best thing for this department since sliced bread – it not only will slice bread, but will knead the dough and grow the yeast and self-bake itself”. Then, of course, instead of delivering sliced bread we might end up delivering half-a-loaf, or maybe an electric knife or perhaps a chopped salad. This problem: getting the project’s scope right.

Then there is schedule. Of course every project is a “priority”. We’re going to get it done in the “next nine months”. Why “nine” months? Because that’s less than a calendar and budget year, but it is longer than saying it will be done tomorrow, which is patently ludicrous. But nine months is also ludicrous for anything other than incubating a baby – and even babies usually take years of planning and preparation. Furthermore, in the public sector almost every procurement has to be done by RFP, and preparing a request for proposals alone, plus contract negotiations with a successful vendor, cannot be done in less than a year. And the schedule needs to include minor components such as business process discovery and the work of executing on the project.

Then there’s budget. Generally we’ll make a pretty good estimate of the actual real cost of the project. The usual mistake is for someone (fill-in-the-blank – “department director”, “Mayor”, “county commissioner”, “state legislator”, “grand phooba”) to say “we only have x number of dollars”. So, as the next step, the project budget shrinks to the magic budget number, while scope and schedule are left unchanged. And generally the “magic budget number” is determined by some highly scientific means such as the amount of money left over in a department budget at the end of a fiscal year, or the amount of money the City of Podunk Center spent on a similar project, or the size of a property tax increase which voters might be reasonably persuaded to pass.

Why do we plan projects this way in the public sector?

First, we are largely transparent and accountable in government. That’s really good news, because we – government – are stewards of taxpayer and ratepayer money. Oh, I suppose we can hide some small boondoggles, but there are too many whisteblowers and too much media scrutiny to hide a major failure. That’s not true in the private sector, where projects costing tens or hundreds of millions of dollars are failures or near failures, often hidden from public or shareholder view, with wide-ranging and sometimes near catastrophic economic effects. Some public examples include Boeing’s 787 Dreamliner or the Microsoft Courier tablet (gee, will anyone every produce a Windows tablet?) The federal government’s project failures are paramount examples of both poor project planning/execution and admirable transparency with an eye to reform.

Here are my top reasons for project mis-estimation:

  • Lack of rigorous project management. Project managers are crucial. But good project managers are also expensive. Government doesn’t grow or pay PMs well. Too often we assign project managers as the “last man standing” – whoever is left over when everyone else is doing the work. And we are woefully short on training – usually training and education are the first things cut from public budgets during recessions.
  • Eagerness to please. Everyone in a project is eager to please a boss – the County Executive, the Governor, a legislator, a department director. How often do we invoke “the Governor is really interested in … (fill in the blank related to the current project)”. Projects need to stand on their own for business value, as well as be of interest to the elected official presently in office.
  • Jadedness. Knowing the budget process described above, we’ll often pad estimates – make the budget larger and the schedule longer, knowing they will be cut. Then, of course, decision-makers and leaders can also play that game, figuring there is padding, and therefore cut all the deeper.
  • The constraints of the budget and election cycles. Typical budget cycles in government are one year. Election cycles can be two years, and at most four years. Unless elected officials and department directors really take a long-range view, these facts lead to short-range think and results, just as stock price and quarterly profits drive the private sector.

And here are my top cures:

  • Hiring professional project managers. Frankly, this means, for large projects, we should usually hire professional PMs or firms from outside government. As a side benefit, such outside firms can also help train, mentor and grow government employees so they become good PMs.
  • Good executive sponsorship. The executive sponsor for a project needs to be the government official with “skin in the game” – the owner of the “business”, whose job may be on the line if the project fails, as well as the official owning the business. A smartgrid project’s sponsor will be the electrical utility’s director of distribution and generation networks. A computer-aided dispatch system’s sponsor will be the Assistant Fire or Police Chief in charge of the 911 center and dispatch.
  • External quality assurance. QA is essentially a “watchdog” on projects, speaking truth to power, and highlighting areas of risk and opportunities for improvement as the project proceeds.
  • Small projects and quick wins. If possible, any large project should really be a series of small projects with quick wins. In the case of a computer-aided dispatch system, for example, the smaller projects could include installing computers in police vehicles, implementing automated vehicle location, implementing a records management system, and implementing the CAD software itself. Of course there is no way to build a sewage treatment plant serving a city of half-a-million as a series of small projects, but most IT projects can be decomposed.
  • Transparency. Perhaps the most important component is openness and honesty for everyone involved – project managers being honest with sponsors, technical staff being honest about their workloads, department directors looking at their portfolio of projects and putting the lower priority ones on hold so the higher priority ones have the resources for success. The federal government leads the way in transparency, with its public “dashboard” for information technology spending and projects.

What’s amazing is that, despite everything I’ve said above, we get an amazing amount of great projects completed. At the City of Seattle, we’ve tracked all our major projects. Since 2006, we’ve tracked 77 project through 2,071 project dashboard reports. We’ve found that, when they are completed, 75% of them are within budget. Of those 77 projects, 32% have been on time and 57% have delivered the scope they promised (i.e. a whole loaf of sliced bread). Clearly this record reflects our priorities – budget is the most important consideration, with scope second, and schedule lowest.

Not a bad record when compared with Standish group project failure statistics, but plenty of room for improvement.

Leave a comment

Filed under management of technology, project management

– Transclucent to the User

GEM Project Team with Mayor Nickels - click to enlarge

GEM Team with Mayor

On Monday night, December 8th, the Seattle Police Department started to use Microsoft Exchange/Outlook for electronic mail. This culminated moving more than 11,000 City of Seattle employees, over 12,400 e-mailboxes, and 900 BlackBerrys from an older e-mail technology to the Exchange 2007 product. All of it “translucent to the user”.

I’ve previously blogged about project management, and specifically identifying and reducing risks in large technology projects (“the P-I test“). With this entry I’m highlighting somewhat different project management practices.  We used certain techniques to reduce the impact of the technology changes on front-line City workers such as firefighters, accountants, and street maintenance staff.

(In case you think I’m just tooting our own horn, I am, but I’ve also blogged about my biggest project failure and you can read about that here, too!). 

We called this e-mail migration project GEM, for GroupWise to Exchange Migration.

Not only was the project on-time, under-budget and delivering all of its objectives, but there were very few whimpers from most City employees at this major change in their work lives. How was such a change so seamless?  

Electronic mail is, arguably, the most important technology used by workers in almost any company today, whether government or private.  It has supplanted the telephone and even the desktop computer as the key tool for many workers to be productive and efficient. Decisions which might take days or weeks without e-mail can be debated and handled rapidly with e-mail communication. Management of front-line projects (streets, water, electricity), debates and decisions on policies, notification of events, press releases, scheduling, all occur with this tool. Most importantly, it is a primary way for constituents and customers to communicate with City workers and elected officials and the way for those officials to coordinate the City’s response. 

Of course, when anything is this valuable in your life, you are extraordinarily skittish when it is NOT available or about to be significantly changed.  Managing this “culture change” – in the working habits of thousands of City workers – is the elusive key to success in a technology project.

I won’t get into the current debate (war?) about use of internal e-mail versus a hosted service, or whether Google’s g-mail is better or more cost effective than the Microsoft product set. Because e-mail is so important in our work lives, and because many people use Outlook at home (or in a previous job) anyway, it was the right choice for the City of Seattle. Because many e-mail messages are sensitive, and since I have a skilled and dedicated set of employees to manage and operate it, we would not have it hosted or managed elsewhere. Microsoft Exchange/Outlook is an established product, well-supported, used by 65% or so of the organizations in America today.  And many many other applications (purchasing or human resource systems, billing and customer service systems) are written to use Outlook/Exchange for communication.

Here are the elements of success for GEM:

  • Strong executive leadership. Mayor Greg Nickels fully supported this change, and every department director knew it. The nine-member Seattle City Council voted to fund the project ($4.9 million) after considerable, reasoned debate. These elected officials were able to articulate the rationale for making this change. This support helped immensely in cooperation for training, scheduling and acceptance throughout the Government.
  • Strong project leadership. My deputy department director sponsored the project – she has formal and informal ties to many line departments, and she’s managed many brick-and-mortar projects (e.g. building Parks community centers). She chose a strong project director who is a hard-nosed negotiator, and a skilled project manager who pays attention to both people and details.
  • Support. We chose, via competitive bid, a knowledgeable private partner – Avanade – to give us advice, skilled support and knowledge transfer. Avanade had helped many companies with similar conversions in the past, and performed in an outstanding manner for us.
  • Training. We gave employees a chance to purchase Microsoft Office 2007 via the home use program, and 2,000 of them took that chance, thereby learning the product suite at home. A month prior to each department’s conversion, we told them how to prepare, for example, by deleting old e-mail and taking training. We offered training in classes, video and reading material for anyone from heavy e-mail users to people who just needed a refresher on Outlook.
  • Communicate communicate communicate. We told all 12,000 employees at the beginning of 2009 what we planned to do (“to” them!)  One month out from their department’s conversion, we told them how to get trained and ready.  Two weeks out we communicated details via their management chain and via e-mail message. The day before conversion, each employee had a sheet of instructions placed on their chair. The day after conversion, technology staff chosen for their great “deskside manner” walked the halls and cubicles to answer questions and solve problems.  We had a skilled service desk / help desk and a special e-mail contact point. And all along we had a detailed, fact-and-fun-filled internal website with information, training, FAQ’s, and links to more resources.
  • Skilled City employees. We already had a highly competent help desk, capable desktop support staff and experienced engineers supporting servers and storage and messaging system.  We trained and leveraged this skilled and motivated set of employees, coupled with Avanade, to do the technical work on the project.
  • Finally – and perhaps this is most important, we drafted departments into the effort. Each department had at least one and usually a team of people who worked with the GEM project team to customize the training and conversion plan for that department’s unique needs. Police patrol officers use e-mail differently than Parks groundskeepers who are different than budget analysts who are different than electrical utility engineers. These “extended teams” in departments not only participated in the planning, but became natural advocates for overcoming problems and socializing the change in each department.

Leadership, communication, user representation, strong private partner, skilled and motivated technical staff – a GEM of a project, translucent to the users!

1 Comment

Filed under e-mail, management of technology, project management, Seattle DoIT

– The “P-I Test”

The Seattle Post-Intelligencer, click to see more</em>

The Seattle Post-Intelligencer, 1863-2009

Technology projects scare the hell out of me. And I’m a Chief “Technology” Officer! Tech projects are full of risk – there are two dozen career-ending ways projects can go south.

But how do you measure and control risk?

Bill Schrier’s first project management rule is the “P-I Test”.

Now, what is “P-I”?  No – it is not “private investigator”.   I named the “P-I test” after Seattle’s beloved daily newspaper, the Seattle Post Intelligencer. Although I’ve been using the “P-I test” for years, the real Seattle Post Intelligencer publishes its last paper edition today, March 17, 2009, after 146 years of publishing.

The P-I test is simple: if a particular technology project goes south, where will it show up in the Seattle P-I – front page above the fold? Local section, page 5, beneath a mattress advertisement? Or will the failure (hopefully) be off every reporter’s radar, that is, no one cares?

One of the big differences between government technology work and private industry is the P-I test. Only very rarely will a failed technology project from a private company make the newspapers. Private companies care about stock price, shareholder value and “face”. So their project failures are buried deeper and darker than the bottom of a coal mine.

But in government, everything is (at least eventually and theoretically), subject to public disclosure. Successful projects (or any good news, for that matter) rarely sell newspapers.

And, in an environment where taxpayer money is at risk and voters give a verdict on government leadership every four years (i.e. by electing a Mayor or City Council members), mitigating the risk of failing the PI test is “job one”.

But when projects are successful, no one notices! Indeed, that is possibly the truest measure of a successful tech project – implementation without notoriety.

Determining how newspapers or reporters or the public will determine failure is notoriously hard. I’ve had relatively trivial projects make headlines, like a simple mistake of sending an e-mail message with all recipients’ e-mail addresses in the clear, or having a bit of difficulty getting a Wi-Fi hotspot to work right.

On the other hand, implementation of a new billing system in 2002 for the City of Seattle’s electric utility – a project a year late and $10 million over its budget of $28 million – probably played a part in the end of the electric utility superintendent’s career.

I have a whole set of “Schrier’s project management rules” including (2) “hire somebody who knows what they are doing” and (3) “make sure the butt of someone in the business is on the line”. And I’ll write about those rules in a future blog entry.

But the real bottom line is that – since I took over as CTO in 2003 – the City of Seattle has not had a single significant information technology project failure. And we’ve done more than $100 million in projects! Credit for this string of successes belongs, not to me, but rather to Mayor Greg Nickels, who demands accountability from every department director, and to the Project Management Center of Excellence in my department, a dedicated set of four professionals who track and demand accountability on over 30 projects-in-progress.

I’ll write more about the other “rules” in Schrier’s project management lexicon. In the meantime, I’ll be extraordinarily sad about the last paper edition of the Seattle Post Intelligencer, publishing today, and the loss of the namesake of my first and most important project management tool, the “P-I Test”.

2 Comments

Filed under project management