quote:

Originally posted by Lord Vaalic:

I hate when the customer CEO gives your VP the RFQ, but with inadequate SOW so your PM cant issue a PO to the SME to start the WBS and they cant establish a KPI or RACI. What a bunch of BS

Can you say that in English?

Sadly I understood exactly what you wrote. Too many years as PM!

Sadly, I too understood every bit of it.

Dang it if I didn't understand too.

quote:

Originally posted by V-Tail:

quote:

Originally posted by Lord Vaalic:

I hate when the customer CEO gives your VP the RFQ, but with inadequate SOW so your PM cant issue a PO to the SME to start the WBS and they cant establish a KPI or RACI. What a bunch of BS

Can you say that in English?

CEO - Chief Exec Officer
VP - Vice President

were there any other you didn't understand?

I'm not a manager just a lowly maintenance technician in a multi billion dollar industry. One of the first things I learned is we are not here to make sense, we are just here to make product. The stupid people above me won't buy parts, but waste thousands on shit that I know won't work. Glad I get paid by the hour.

You nailed one of my pet peeves.

Retired now, I was an attorney for many years negotiating technology infrastructure contracts.

I learned early on that, while the terms and conditions are (obviously) important, the SOWs and technical exhibits are critical. I used to drive project teams crazy by insisting that they be complete and clearly written.

But our VP of Systems Engineering sure appreciated it when those project exhibits saved him $$$ on more than one occasion.

quote:

Originally posted by nhracecraft:
I'll just leave this here....

That is priceless!

Reminds me of a meeting with a very unhappy customer. They were furious that we were not delivering the system they wanted. They got their attorney involved, so my company got me involved.

Meeting kicks off. Their atty gives a speech about how we’re in breach, how they’re going to sue us for millions, blah, blah, blah.

When he was done, I simply said “If you actually read the agreement’s technical specs, you’d know that you contracted for a Pinto but are now demanding a Cadillac. We’ll be happy to build you the Cadillac, but the change order is going to be enormous. Let us know how you’d like to proceed.”

The customer team went into an adjoining room for a while. When they came out, they adjourned the meeting and left with their tails between their legs.

quote:

Originally posted by bigdeal:
I thought that was my project. Wrap your head around this one.

I am loving this thread; it brings back so many memories.

Probably my all time favorite was the deal where our sales guy made promises that not only he could not keep, but which violated the laws of physics.

Of course the customer's atty promptly translated those promises into contract guarantees. The trouble started when I said "no way"; I pointed out that our company could not meet those specs even if we wanted to.

The sales guy decided to have me brushed aside by suggesting that the customer call our company CEO to complain that 'your lawyer is killing this deal'. That call had the unintended effect of bringing a lot of attention to the deal, and when the dust settled, our CEO backed me up -- and fired the sales guy.

quote:

Originally posted by sig2392

That is how some companies survive.

They bid low, deliver the absolute minimum and lousy crap specified in the document and stand around and wait for the change orders to make a profit.

Change Order Artists is what I have always called them.

The boat picture is so true and absolutely priceless.

quote:

Originally posted by V-Tail:
Many years ago, I was team technical lead on a software project that the company I worked for was doing for San Francisco's BART fare collection system.

We never met with the BART folks prior to the project; I took my direction from the System Requirements document that they provided.

I scratched my head over one of the interface descriptions. Couldn't for the life of me, figure why in the world they would specify an interface as klutzy as they did. I kept thinking that I was not reading it correctly, I conferred with several people in my company, and we were all in agreement about what they wanted.

OK, I designed the software interface to do exactly what they wanted.

The system was implemented and tested, everything worked, we submitted it to the customer along with our invoice.

We had an acceptance meeting, first time I came face to face with them. They had given us a review document, and they really slammed me on the terrible interface design.

I did not say anything, just sat there and let them rant, while the president of my company glared at me, thinking that I had done a lousy job.

Finally, when it was my turn to speak, I asked everybody to open the Requirements Document to the section starting on page 47, and walked them through it, paragraph by paragraph, showing how my design was exactly what they had requested.

The conference room got very quiet. You could have heard a pin drop. Company president got a big smile on his face when I stated that we had done what BART requested, if they wanted to re-specify the interface, I would get back to them with an additional quote for a re-design to meet their revised requirements.

That was good. I would have liked to have been a fly on the wall for that one.

quote:

Originally posted by Eponym:
I saw that many times as a software developer. "We don't know (or can't articulate) what we want, but we know this is not it."

If you can't give me your exact requirements, how can I meet them?

It's a classic mismatch between customer ignorance and software professionals. For some reason it happens more in software than in the engineering world.

quote:

Originally posted by bigdeal:

quote:

Originally posted by ensigmatic:
I once was lead software designer on what became known in the company as the Project From Hell.

I thought that was my project. Wrap your head around this one. I used to work for a huge financial software company. They signed the following project (which was assigned to me) that was turned down by every single one of our competitors.

Simultaneous software, hardware, and operations conversion of '2' banks (the $15B primary bank and a $2B bank that was being acquiring). 107 branch locations plus three operational centers. Primary bank was running an in house, defunct, no longer supported software system that had been cobbled together with custom code for the past ten years and for which there was little to no documentation. Bank being acquired was running in a datacenter environment, on a completely different software system, and most of its senior/key staff had quit. Normal project timetable for a single bank conversion of the size of the primary bank, 8-10 months. Required project timeline for the two bank conversion, 5-6 months.

This project forced me to quit working for the company I'd worked for for almost 6 years, and which in the end, almost bankrupted the company. It was by far the biggest disaster ever executed by the company, and I knew I would have been the scapegoat when it failed had I stuck around.

More to the ops comments, managing customer expectations separates the rookies and hacks from the pros when it comes to project/program managers. Its far and away the most difficult aspect of running large projects.

I got out of IT project mgt some time ago and transitioned back to the keyboard and never looked back. Still lovin it. Wrestling with machines and bad software is infinitely better for me, but truly good software project managers are worth their weight on gold and I have a lot of respect for their ability to deal with that mess and move forward in spite of the insanities invovled.

quote:

Originally posted by wrightd:
...but truly good software project managers are worth their weight on gold and I have a lot of respect for their ability to deal with that mess and move forward in spite of the insanities invovled.

I truly believe there's one point in every PM's life where they can finally claim they know what they're doing. That moment came for me when I took over a project from a more senior peer who had completely lost control. I flew to New York and sat through a 2 hour conference meeting with my peer and senior staff of a very large bank based in Brooklyn, wherein they chewed my ass for over an hour as the rep of the company (they'd had it with my peer). When the COO finally asked me if I was going to offer anything, I stood up looked around the room and asked if anyone else had anything they wanted to offer as I wanted everything out on the table before I started. Then I walked the room for almost an hour laying out the pathway forward. When we finished the meeting the COO apologized to me for them being so blunt and aggressive with me. I told him not to worry about it as I learned a long time ago that New Yorkers disliked everyone, so I never felt as though I was being singled out. He laughed, took me to lunch, and we progressed through the next 6 months to have a successful project delivery. And when I left the company a few years later to work for myself, he and that bank became one of my best customers. Lemonade out of lemons. Learn your customer and how best to establish a level of rapport and respect with them. That's an aspect of PM most young PM's have absolutely no concept of and that PMI completely ignores in their training.

quote:

Originally posted by V-Tail:

quote:

Originally posted by Lord Vaalic:

I hate when the customer CEO gives your VP the RFQ, but with inadequate SOW so your PM cant issue a PO to the SME to start the WBS and they cant establish a KPI or RACI. What a bunch of BS

Can you say that in English?

RFQ = Request for Quote
SOW = Statement of Work
PM = Project Manager
PO = Purchase Order
SME = Subject Matter Expert
WBS = ???
KPI = ???
RACI = ???
I think everybody knows BS.

quote:

Originally posted by slosig:

quote:

Originally posted by V-Tail:

quote:

Originally posted by Lord Vaalic:

I hate when the customer CEO gives your VP the RFQ, but with inadequate SOW so your PM cant issue a PO to the SME to start the WBS and they cant establish a KPI or RACI. What a bunch of BS

Can you say that in English?

RFQ = Request for Quote
SOW = Statement of Work
PM = Project Manager
PO = Purchase Order
SME = Subject Matter Expert
WBS = ???
KPI = ???
RACI = ???
I think everybody knows BS.

WBS - Work Breakdown Structure
KPI - Key Performance Indicator
RACI - Responsible, Accountable, Consulted, and Informed aka a Responsibility Assignment Matrix.

I hate to say it, but I read what LV posted and I understood The Whole damn thing. I’m a dork. lol

quote:

Originally posted by wrightd:

quote:

Originally posted by Eponym:
I saw that many times as a software developer. "We don't know (or can't articulate) what we want, but we know this is not it."

If you can't give me your exact requirements, how can I meet them?

It's a classic mismatch between customer ignorance and software professionals. For some reason it happens more in software than in the engineering world.

I was reading this trying to understand why things sound so messed up. I am involved in writing and review of RFP's, statements of work for long term supply agreements, corporate equipment standards and various other things for manufacturing. I consult globally on capital projects costing more than $20M.

And when I am part of specifying and buying a new production line, the kind of behavior described in this thread would be considered very unprofessional. There is constant communication with the supplier(s), multiple rounds of clarification and adjusting of quotes until we can be sure they are quoting what we want. We don't always choose the lowest bidder.

After a supplier (or Tier 1 integrator) gets the project, we have a few months time with multiple long sessions of meetings to present our IP (detailed product drawings, product specs, and many other things) that they cannot have until there is a supply contract, and ensure that they fully understand everything they need to do, and review their concept designs. Then after they are clear, they go about detail designing the equipment and lines and everything and then we go through multiple sessions of reviews to approve their designs before they start building. Then after interim progress checks,
there is a runoff at their facility, installation at ours, debugging and fixing issues, then acceptance only after production begins and we produce a specified amount of product.

It is hard to fathom throwing a (poorly) written spec over the wall and then waiting to see the final result, then getting into a grudging stalemate over the results. The kinds of projects I do take years, and then need support for many years (spare parts, upgrades, retools) and although there are a lot of negotiations over scope changes, with cross references to the RFP and final quote, in the end things work out and we don't have lawyers or senior executives coming in to do our jobs for us, nor do we behave unprofessionally. We budget for some overruns and rarely have to ask for more money because the adds and deletes usually balance out for the most part.

Now, one of the things we make clear in writing is that we are product manufacturers who know a lot about equipment but we are not equipment designers, so anything the supplier designs and builds still has to be meet the intended function in the specified cycle time, they cannot simply sit on their ass and say "you approved it".