this is great stuff. I have run into some master bull$h!ters in SharePoint interviews. SharePoint is a highly visible product and people’s egos can get out of hand during discovery phases, architecture, deployment (ever dealt with infrastructure people who think SP is a piece of junk? Well, let me tell you…) and, ta-da, process optimization. In case you did not notice, most middle management lives on inefficient business processes (which keep them busy or helps with looking busy). Optimizing these processes (or helping optimize those processes) may awake more egos and people whose “nest” they build over the years will finally become transparent with SharePoint.

Never EVER, under any conditions, agree to “train” someone in SharePoint as a part of the job, especially remote teams. This is the endless source of FUD and time waster and won’t be billable (like unpaid overtime). If someone asks me for training, I can offer training but that costs extra, requires extra time and commitment. It is not an afterthought.

Also, you must have your own SharePoint environment (on a laptop), in case something blows up at the client’s (as it often does. I develop everything on my box or, if I work on somebody else’s box, I move the artifacts into my local environment at the end of the day. I was always glad I did. It is always better to work with real hardware than half-a$$ed VM which responds like PCs from 20 years ago.

Finally, ask about how exposed you will be to the users and what the deliverables are for the first 2-3 weeks. Expectations for SharePoint and productivity are very high and people quickly start filling your bucket. Before you know it, you have to develop two dozen web parts, half a dozen templates and work out the custom kinks for branding for 25 clients who are knocking at the door – all by next Monday. Keep your scope in check and publish it to project owners/managers.

Great, great stuff. Now that I know that I am not the only one who saw things this way I feel much better.

SP Guy

Here’s another quick list of SharePoint articles around the blogosphere:

15 Ways / Questions To A Smooth SharePoint Contract – Adam goes thru his list of 15 questions you should be asking yourself or your future employer before you agree to the …

These are good points, you covered a lot of stuff that I missed, but wish that I would have hit (and if you don’t mind, with your permissions, I would like to move some up to the post body).

I completely agree with you on checking out whether the employees are happy, even if you are a subcontractor through a random staffing firm or whatever, this is 100% a good indication of how well your contract experience is going to go. Although you may be jumping firm to firm, what is a year but a summation of working experiences?

I can’t believe I missed the knowledge transfer point, but that is a huge issue a lot of the time. I have had a ton of contracts where I have been doing SharePoint development, subsequently, been asked to do a knowledge transfer to a .NET developer with no experience whatsoever with SharePoint. As you can guess, this was never a smooth process, so definitely something to clear up front to avoid any complications. I would encourage everyone that reads this post to take Valerie’s point about this into 100% consideration.

The support thing is off and on IMHO. Sometimes you get it as a sub, sometimes you don’t, totally depends on the sponsoring organization (the prime) and the client. It’s hard to bank on it unless the organization has a good SharePoint practice in place. Otherwise, hell, they might be asking you all the questions!

I tried to touch on the quality control of SharePoint deliverables in the documentation portion but didn’t hit it well. But you make an excellent point, there is a broad difference between well developed software that includes all testing harnesses (such as including mock builds), and worthless software that just works “enough” (like CorasWorks!).

I have gotten burned a LOT by asking about working remotely, to me it is more of a dice roll then anything. It can mean you have a balance between life and work, or it can mean that you are trying to be lazy, spend all morning getting drunk off homemade Starbucks / Khaula mixed drinks while attempting to get some code done. While some of us enjoying coding drunk (that’s me!), it may not be super efficient for other people. There are lot of reasons why this is entirely more efficient for some people however.

I hate arrogant programmers, can’t stand them, and 100% not one of them. Actually, just got relieved of having to deal with one, because I choose not to treat people like shit regardless of their skills or attitude, just not in me. Subcontractors have a certain luxury where they are allowed to look at a project with an interesting perspective, and a lot of times its unfair to those staffed full time. As a quick example, I am really a sponsor of developing your own WebPart base class so that you can implement certain standards such as exception handling which can make mass WebPart differences a breeze. I know a lot of developers are revving up on SharePoint development, so I have to tread tactfully, and not to suggest this sort of radical shift. Does it give me the right to tell them they are morons and so wrong for inheriting from the framework class. Hell no. In any respect, who the hell says that my way right. Everyone has their own coding styles anyhoo!

The Nazi subcontractor mentality IMHO ultimately is just detrimental to a project. Assimilation in those particular types of circumstances often I feel is more helpful then productivity!

Thanks for your comments, they improved the point I was shooting for a lot. As I said, with your permissions I would like to move them up to the post body (credit will be given of course!)

Those are all very good points that any company should be able to answer. I’m not sure where your contracts have been but have a few points from the other side.
1) It is very important that the company you choose to work with firstly, has happy employees – if the employees are not happy chances are you will not enjoy it either. Ask to speak to someone that is in the office during an interview and get their opinion. Remember to pay attention not to the words but the animation of the employee – if they look like eeyore saying they are happy they are probably not.
2) How much repeat customer’s do they have. If it’s less than 50% then the company is probably not doing the right things. At Ideaca, our whole business is built on our philosophy that “every customer is a reference customer”. That does not mean that we do everything they say either. Getting a reference customer to us means being honest and advising them on possible risk factors. This has caused us to sometimes lose projects but we believe you need to do it right.
3) Knowledge transfer – you need to know up front how much time you will have to spend getting the company resources up to speed as well as the client resources.
4) Support for you – find out if there are company resources you can reach out to if you need help – which everyone does from time to time
5) Quality management – what are their testing and migration procedures. Some projects have very strict guidelines and may require your time to write and execute test scripts – because of the menial nature – make sure you know it up front if you don’t enjoy that type of task
6) Ask how they feel about working remotely – if they allow you to work from home it shows that they at least put some value on work/life balance. There are sometimes exceptions to that depending on the project but at least find out how the company you are going to subcontract to feels about it.

Because I’m writing this I have to add in my big beef with subcontractors – do not assume you are the smartest person on the planet. There is nothing worse with someone who is arrogant and not willing to listen to other’s. You can be the smartest person on the team but be humble and always willing to listen – you don’t need to act on whatever opinion you receive but at least listen and make others feel important.