Saturday, January 26, 2008

Seeds of Failure

Managing vendors (and their representatives) can present its own set of challenges.

I was brought in to be Project Manager, support the IT Manager, and help oversee the replacement of their 3rd party loan package. The company in question makes loans and investments to companies that service the low income community -- loans to build housing, child care, etc. They borrow money and loan it out at a higher rate, just like a bank, but have a different business model.

The kicker was that the well known loan package had never been installed at a low income investment fund before, so they were untested in this "space". The IT Manager had never overseen this type of installation before, and the PM for the vendor was long on promises and good will, but short on delivering proof that the software could do the job.

The vendor's saleman was vague on the pricing, and when the vendor's PM came up with a quote for implementation that was near double the salesman's vagaries, there was added drama. Furthermore, the IT Manager thought the quote included the imaging module, and when it didn't they had to cough up additional money for that.

This is where I came in. One of the first things the IT Manager did was to give me the vendor PM's Microsoft Project file, with the instructions to fill it out with "more stuff".

The plan called for ONE data conversion, followed by a number of employees verifying the converted data. Then followed by workflow testing (assuming that the test scenarios could be modeled in the new system -- something that should have been done up front before selected the software package!). Then, there was ONE month of parallel testing and followed by going "live".

What I am saying here is that this project was doomed near it's inception. When I would voice my concerns, the standard answers from the vendor's PM were "I don't see any red flags" or "I think we're good". While I was skeptical and voiced as much to the IT Manager, she discounted my concerns because there was a hard go-live date and my sense of risk went against this.

As it turned out my duties were more along the lines of being an MS Project "updater", and none of my other PM skills were needed or wanted. The IT Manager and I developed a large credibility gap, and I was therefore limited in what I could do to help. There remained no real point in my staying on the project.

As I later found out, there were numerous conversions and also problems with test case scenarios. The hard go-live date was missed and there were a variety of other problems too.

As always, one reaps what they sow, and the seeds of failure were sown early-on for this project. Very unfortunate, since the the company's purpose is a noble one.

Thursday, January 17, 2008

Halt the Train Wreck

At times a project is deemed to be "out of control", "a train wreck", or a "catastrophe". A time-out is required to assess the project, the team, and the management, and to see if the project can be salvaged.

While it may seem reasonable to some that project development could continue in some way while these evaluations are being made, it is best to stop the project.

Evaluation of a project disaster requires the full involvement of the key team members (stakeholders, development staff, key management), and if project development is taking place in parallel you will not get the time and focus from them required to salvage it.

Unraveling the project will require decisions that may not be pleasant. These decisions can affect the team and project significantly. Allowing the project to limp along in catastrophe mode absorbs valuable resources without any real benefit to the project, and will allow important decisions to be put off. Halting the project will hopefully "light a fire" and drive home the point that the sooner decisions are made, the sooner the project can continue.

Halting the project also sends the message that top level management is serious about the disentanglement process.