Your worst project management experience?

This forum is for members to share and gain knowledge of Project Management. Got a question about project management? Need help with a problem? Wish to offer tips and advice? Post here.
Post Reply
User avatar
begeland
Expert Member
Expert Member
Posts: 173
Joined: Sat 09 Mar 2013 11:46 pm
Location: Las Vegas, NV
Contact:

I'd like to start a new thread on sharing the misery. What is your worst project management experience?

It may be one embarrassing moment on an otherwise great project. It may be an entire project down the tubes. But we've all had them. I'll share mine shortly, but I wanted to get the question out here so we could get some discussion going. Thanks!
Brad Egeland
User avatar
begeland
Expert Member
Expert Member
Posts: 173
Joined: Sat 09 Mar 2013 11:46 pm
Location: Las Vegas, NV
Contact:

Ok...so NO ONE has had a bad project experience? I see lots of views, but no posts about experiences. I'll be the first to share.

I've had a few bad ones, but I think possibly the worst was when my Business Analyst who was with me during some onsite customer functional requirements meetings following formal project kickoff actually was forced to tears. Yes, crying. Mostly outside of the sessions, but some during the sessions though not as obvious.

What had happened was this. The account manager who sold the project set some expectations for the customer - or implied certain things that the customer then interpreted - and that caused us major problems during this discovery/requirements phase. I remember that at every break we were again on the phone with the account manager trying to figure out what he promised and what he had told the customer.

Our solution was a proprietary out of the box solution (sort of an ERP type solution) that we would then configure to match the business processes/needs of the client. In order to really help us define the requirements well, though, the customer needs some familiarity with the solution. This customer had none, and were told that their training was free with the maintenance agreement they purchased (and we're talking 10s of thousands of dollars). It was not. The customer was not at all happy...and this was only one of the problems we faced during this session of discovery/requirements.

The solution? We halted the project, drew up a change order to bring a trainer onsite to the customer location (and cut them a nice deal for the misunderstanding) and got their key personnel trained for a reasonable price - AND THEN we resumed the requirements definition. And with no more crying.

Brad
User avatar
kwalford
Global Moderator
Global Moderator
Posts: 301
Joined: Thu 08 Dec 2011 1:34 pm

I am surprised no one else has replied to this thread too...

I have been trying to think of one myself, as I know there have been a few, but I am struggling to think of one of my bad experiences currently.

Good story there Brad; I am not sure how I would of coped with tears in a meeting, difficult situation.

Kit.
User avatar
dhaughey
Site Admin
Site Admin
Posts: 460
Joined: Sat 19 Dec 2009 4:39 pm
Location: London

Hi Brad,

My worst project management experience was the development of a software recruitment tool. It suffered classic scope creep, and what started as a simple system for posting jobs on a website turned into a full-blown recruitment management system.

So how did this happen? It came down to inadequate requirements gathering. There were a set of requirements written by the client that didn't explain the full extent of their needs. A lot of additional requirements emerged as they developed their thinking. So this points to inadequate change control. Coupled to this, the client had a direct line into the developers, and keen to please, the developers added new features and functions, a clear example of 'gold plating'.

I'll hold my hands up and say I wasn't in full control of the project and although I could see the business benefits for what it was producing, did not communicate well enough to the sponsor and other senior stakeholders.

This project remained a bone of contention long after completion and was often brought up (unfairly in my view) not as an example of a poorly run project (which it was), but an example of poor quality software (which it wasn't). The perception was that because the project wasn't run well the software quality must be poor. Interestingly, the widely used worldwide solution lasted seven years before being replaced with a managed service.

The motto is to never judge a project's success on day one; look at how it performs over a number of weeks and months.

So the lessons to learn from this project are:
  1. Carry out thorough requirements gathering and get sign-off from the client for the scope of work.
  2. Initiate a change control process (request, review, approve, plan) through which all changes pass.
  3. Communicate effectively to the sponsor and other senior stakeholders.
You are only as good as your last project and sometimes you're only as good as your last project failure. The memory of failures seem to fade slower than successes, so be careful and never neglect your requirtements gathering.

Duncan
Post Reply