Outsourcing an insourced project
-
You heard that right. After I finally bailed out of the little shop of horrors (mentioned in another thread), I got a short term contract with another company. It didn't take me long to realize that standard procedure at the client company was to have as few employees as possible and to have contractors do most of the work. Generally, all the management/supervisors were FTE's and all the worker bees were contractors. It was also one of those largish companies that uses a preferred vendor list, which is the polite way of saying they hang a job opening out the window and let all the body shop dogs jump and snap for it - with the result that most of the contractors were H1B's. We had a fire drill one day and I was the ONE blond head in a sea of brunette/black.
It went fine for several months. I was on a "modified waterfall" project where all the developers were used to working agile and so resented all the time we had to take to get the requirements *just right* before they could start work. My job was system analyst. In English that means I rewrote the requirements from user-speak to developer-speak. Most of you here are already getting your blood pressure up, I know. GOOD developers don't need requirements translated for them. As a former developer, I completely agree, but this was the process at that company. And they had quality checkpoints that all projects had to go through, that included strict review of the documentation.
The first WTF was that someone in management promised an external client that delivery would be made in January. The project for various reasons didn't get started until October. We had a whole new team and only one person who was familiar with the application. So the learning curve and holiday season slowed us down so that we didn't finish requirements gathering until January. Management drove the PM nuts by making him fast-track the project and then crash the project. Our more realistic delivery date was in July but that was Just. Not. Acceptable. The PM did his best by by pretending we weren't waterfall and allowing the developers to start working off the requirements simultaneously with me writing the design docs. By this time we'd completed the learning curve, too, so things started to accelerate.
In late February, one week before I was due to run my documents through the quality checkpoint, they dumped our entire project team and handed the project over to Acme Managed Services. I was told to stop work and hand over my documents to Acme people to finish. In summary, just as we were really making progress and getting somewhere, the project had to start over with all new people. The icing on the cake was if you looked at it from the angle of job type: we were all contractors. They fired a bunch of contractors and handed the project to... different contractors.
Yep, that saved money. Oh, and I'm sure the project completed in January.
-
@jetcitywoman said:
Most of you here are already getting your blood pressure up, I know. GOOD developers don't need requirements translated for them.
whu whu what?
user-speak is a different dialect from dev-speak. You NEED these translators in between.
-
@dhromed said:
user-speak is a different dialect from dev-speak. You NEED these translators in between.
Well-well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?
-
How on earth do you even choose a deadline before requirements gathering? There is nothing worse than a project that gets delayed due to other reasons (third-party critical path issues, other projects taking away human resources and manhours from your project, etc.) yet the PM and the devs for that project get the blame. It happens way too often.
Also:
@jetcitywoman said:
I rewrote the requirements from user-speak to developer-speak.
Isn't that standard operating procedure for the waterfall model? It sounds like you're making a design spec out of the requirements spec.
-
@RHuckster said:
@jetcitywoman said:
I rewrote the requirements from user-speak to developer-speak.
Isn't that standard operating procedure for the waterfall model? It sounds like you're making a design spec out of the requirements spec.
Well, yes, exactly. It might be a fun exercise to count all the WTF's.
1. Setting the deadline before requirements are even started.
2. Declaring a project will be done by waterfall when it's got such a hard deadline in less than a year.
3. Declaring a project will be done by waterfall when the development team you put on it are all used to Agile.
4. Declaring a project will be done by waterfall, and then when it can't be delivered on time, letting the developers work Agily (but don't admit that's what you're doing).
5. Declaring a project will be done by waterfall, which requires months of documentation/analysis/design, assigning one business analyst and one system analyst to it and then trying to speed things up by throwing more developers on it.
I'll probably think of more later.
-
@dhromed said:
user-speak is a different dialect from dev-speak. You NEED these translators in between.
For example:
-
@jetcitywoman said:
@RHuckster said:
@jetcitywoman said:
I rewrote the requirements from user-speak to developer-speak.
Isn't that standard operating procedure for the waterfall model? It sounds like you're making a design spec out of the requirements spec.
Well, yes, exactly. It might be a fun exercise to count all the WTF's.
1. Setting the deadline before requirements are even started.
2. Declaring a project will be done by waterfall when it's got such a hard deadline in less than a year.
3. Declaring a project will be done by waterfall when the development team you put on it are all used to Agile.
4. Declaring a project will be done by waterfall, and then when it can't be delivered on time, letting the developers work Agily (but don't admit that's what you're doing).
5. Declaring a project will be done by waterfall, which requires months of documentation/analysis/design, assigning one business analyst and one system analyst to it and then trying to speed things up by throwing more developers on it.
I'll probably think of more later.
Just out of curiosity, was the use of RUP involved in any way?
-
[quote user="Renan "C#" Sousa"] Just out of curiosity, was the use of RUP involved in any way?[/quote]
Only sort of. We used a couple of the Rational products, but no UML.
-
@RHuckster said:
How on earth do you even choose a deadline before requirements gathering?
Client dictates deadline.
We had a client that had a deadline and we quoted how long each part would take, so we set up Gannt charts to map out when things would happen. Then they didn't come to the party with content required on time. They supplied a (video shoot) script that would take us over a week to process (you know, like make sure the script is intelligible, then hire the actors, set up the studio, shoot, edit, render, cue, upload, etc) the day it was due (and it was still incomplete) then asked where it was. I'm glad I'm only slightly involved with that project.
-
That's why I suspect I'd suck at project management. I'd tell the customer in clear language how he dropped the ball and that's why the deadline will be missed. No dancing twinkie-toes around facts for me, and if they get red-faced and take their ball and go home to cry it's fine with me. I'll buy the team pizza and beer with the remaining project funds and call it good.
On the other hand, I'd rock!
-
@Zemm said:
Client dictates deadline.
Client indicates deadline. What are you, slaves?
@Zemm said:
Then they didn't come to the party with content required on time.
Ok, their fault.
@Zemm said:
the day it was due [they] asked where it was.
... was there no communication in between? Regular updates between project manager and client would have made that final question impossible.
