[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sas-l
Subject:    Re: FW: ***The DON'Ts of Consulting!
From:       Roland <roland.rashleigh-berry () VIRGIN ! NET>
Date:       1999-11-30 23:11:50
[Download RAW message or body]

I'll show you all a REAL "don't" of Consulting. Wait until the end.

john_salkeld@SANDWICH.PFIZER.COM wrote:
>
> Well,... I'm a bit disappointed that Rolands attempts to set the flames
> flying has resulted in so little response to the list - maybe it all went
> personally to him?  Perhaps the list is just too sensible to respond to the
> bait?

Hopefully.

> But, I might as well throw in my 2-pennies worth...... just to keep it
> going.
>
> I'm a 'permie' who has worked with SAS software in the UK for about 13
> years.  In that time I've been responsible for recruiting many contract SAS
> programmers (Roland we may have met along the way here.....).  While I think
> you identify a characteristic of some staff (permies and contractors) in
> their desire to retain a hands-on technical role, and the possible
> reluctance of companies to recognise the value of such individuals cv
> people/project managers, I can't agree with the rest of your comments aimed
> at contractors.

It was there to open debate. This ng has been too stuffy for too long.

> Part of the interview process for contract staff is to see if they can fill
> the intended role - if this is as part of a team then being a team player is
> an important (the most important?) characteristic I look for.  This also
> applies to permies when I interview them for jobs.  If they can't function
> as part of the team then their other skills become (almost) irrelevant.

But this is Pfizer in Sandwich, Kent. You people hire hundreds of
contractors. Your output is dependent on them. I would have thought that
you would need a mix of such people within your own organisation. I
would throw caution to the wind if I were hiring for Pfizer and get in
the people with the best SAS skills and kick out the ones who can't
perform or function within a team environment after 3-6 months. You have
nothing to lose and everything to gain. Your use of SAS is massive and I
would have thought that few few "off-the-wall thinkers" and crazy gurus
would be just the ticket there.

> I haven't come across any contractors who exhibit the traits you describe (a

Well, most of my time in SAS has been in MVS Capacity Planning.
Mainframe people are maybe much more looney. From my own experience,
that is. But I have definitely noticed that newish pharm contractors try
to pretend they are "experts" when they get their first contract. They
seem to think they were hired for that reason -- when of course all they
were hired for was to get the job done.

> result of a good interview process?) - although I've occasionally  seen
> these characteristics exhibited by permies.  Contractors are recruited to

Maybe you should sack all the permies.

> 'get the job done' and for their skills - buy the skills rather than train

If only contractors knew this.

> own staff - but this doesn't mean that you expect them to know everything.

Why the hell don't you people invest in training your own staff up to a
decent level of skill in SAS? Surely this would save money in the long
run?

> I expect a team to share knowledge and experience - both permanent and
> contract staff - they learn from each other.

That is the best way. Hugely more efficient and resulting in a much
better product.

> I suppose the bottom line of my comments are - the traits you describe have
> very little to do with contractors, more to do with individuals irrelevant
> of their job status.   I'd also suggest that the traits you describe might
> be difficult to maintain as a contractor - who would employ such an
> individual? - a permie might survive as long as he didn't upset the wrong
> people.  So how do all these contractors you describe manage to get (and
> keep) their jobs?

By buggering up things if they don't get their way. I have seen it
happen.

When I went for the interview at my current place, one of the
interviewers asked me what I thought of the idea that contractors
deliberately make things more complicated just so they can make
themselves indispensible and keep their jobs. I have no idea whether
this gut really meant it. Perhaps he did. Or maybe he just wanted to see
my reaction.

> PS    Why exactly are you so keen to start this flame/thread - some specific
> reason, or just out for a laugh?

It breaks up the day.



Now for the real "Don'ts of Consulting" . Don't piss off a prospective
employer. Pfizer, in the UK at Sandwich, Kent, is the biggest employer
of SAS contractors in the UK. They pay the highest rates as well. The
worst thing a SAS contractor like myself could do is to tell this
manager and employer of contractors what could be some nasty home truths
about the use of SAS at Pfizer. Would I do a stupid thing like that?
Read on....



I know a few people who have worked at Pfizer and they tell me that the
problem with that place is that people are changing the reporting macros
all the time. If you rerun a piece of SAS code a few days later it might
abend or produce a different output. This is what they have told me.
They have said that the reporting environment is not stable. If this is
the case then this is madness.

Where I work, we can rerun the reports of a study years later and get
exactly the same output as the original. Not a character will be out of
place, not a single figure different. I write and maintain reporting
macros in my team. Some of these macros are extremely powerful and
flexible. Far from trivial. I am aware that there is this need to be
able to rerun things and get exactly the same output. To achieve this,
the macros have their version numbers in their name. Like "aetabv4"
instead of "aetab" to signify that the macro is a version 4 macro. They
stay with that name until a change is made that might alter the output
in any way. In that case a new macro is created called "aetabv5".
"aetabv4" will stay there, no longer eligible to be supported, so that
old studies, if rerun, can pick it up and produce the same output.

I just thought I would chuck that in your direction.

Roland

[prev in list] [next in list] [prev in thread] [next in thread]