When it comes to testing new systems and consumer-oriented websites, many things can and often do go awry. Healthcare.gov is a very topical example, but these types of things happen all of the time without the din of the mass media.

In this post, I’ll focus on the role of the project manager (PM) as it relates to system testing. While massive technology projects require that someone is effectively in charge, the inimical impact of a delusional, neophyte, or just plain bad project manager is impossible to overstate. I’ll cover two examples from my own consulting career that prove my point. I have anonymized the participants because I don’t like lawsuits.

Bad idea.

Example 1: Double Threading

Scene: ERP implementation for a large healthcare organization in the northeastern United States. Year: 2006.

Try concurrently juggling two major system tests. It’s no picnic. As I tried to unsuccessfully explain to Dorothy, it would be difficult for both consultants and employees to remember who did what to whom and when. Unfortunately, I was right–in spades.

The next week was sheer madness. Were our errors the result of a design issue, poor timing, a missed step, bad data, a true software glitch, or something else? When we investigated issues in data area A, we had to ignore issues in environment B, exacerbating the situation.

Dorothy’s “double threading” was disastrous, giving fodder to those who wanted to postpone the system’s implementation indefinitely. When errors appeared in testing, those opposed to the new system would say, “I told you so.” Not the best team dynamic.

Ultimately, that project ran months and hundreds of thousands of dollars past its targets. Heads rolled.

Example 2: Date Magic

Scene: ERP implementation for a mid-sized retail organization in the northeastern United States. Year: 2000.

When the project was conceived and planned 18 months ago, system testing was supposed to last a full six weeks. Now, the team’s backs are against the wall. In her infinite wisdom, Marie (the PM) for the vendor/consultancy arbitrarily decided that those six weeks could be magically shrunk to two or three—and combined with employee training, no less.

PM should heed the advice of experienced consultants who know how long testing should take.

In large part due to Marie’s mismanagement, the project missed key dates. Fed up with her incompetence, the client asked the consulting firm to remove her from the project. Consultants and employees rejoiced.

Simon Says: Hold PMs Accountable

Despite obvious differences in scale, these two projects share a great deal in common with Healthcare.gov.

In the nearly decade that I spent implementing enterprise systems, I sat in more status and project planning meetings that I could count. As some project approached their deadlines, I saw a few PMs fudge dates to make everything fit.

Now, dates are equal parts arts and science, but PMs are not deities. Nor are not technical or functional experts. As such, they should not make make testing-related decisions in a vacuum. They should heed the advice of experienced consultants who know how long testing should take.

Don’t be afraid to challenge PMs–and remove them if their answers don’t pass the smell test.

Feedback

While the words and opinions in this post are my own, Corvil has compensated me to write it.