15 Ways / Questions To A Smooth SharePoint Contract

We have all been burned on contracts (well most of us I suppose, I have a whole lot), predominantly prevalent with SharePoint projects because it seems like the skill set pool for an experienced SharePoint developer is particularly thin, and recruiters / human resources staff in organizations are ready to sell their mortal souls and lie their ass off to get you to join a team. I am not blaming them I guess, you sometimes have to do questionable things to fulfill your job role within empirical ethic boundaries, even though sometimes they appear to skirt them.

While it is nice to feel this popular and wanted, you often end up joining a team where if you are a pretty talented SharePoint developer, and you thought you would have a nice position where you would get to do higher visibility development tasks and delegation, you are instead stuck in a corner, sweat shopping out uninteresting class development that no one else wants to do.

Here are 15 ways / questions, which I have learned during the contract negotiation phase, to ask / do before taking any SharePoint contract so that you can avoid working in the broom closest with no air conditioning, next to decomposing drywall, with a rat who you end up naming because he becomes your only friend and contact for the next half a year. This kind of starts with the general business stuff, and get into the more technical stuff into the end, so if you are looking for the technical things, you can skip to the bottom.

1) If you are interviewing / negotiating for a consulting company that farms you out to a client, ASK IF THEY HAVE A SECURED / ACCEPTED BID ON THE CONTRACT!!!

This is important, very important because it effects your probable paycheck and therefore your ability to support your family. Consulting companies in my experience will try to staff personnel resources that are commendable and noted for a skill set before they actually secure a bid on a contract to increase the fluidity of the sale and increase the probability that their bid will be accepted. This is bad news bear for you though if they don’t get the contract, since you will either be benched or let go faster than a greased panther, depending on the parameters of the contract that you are going to sign (whether you go FTE, or doing a strict 10-99 deal). Just make sure they are hiring you for something running and secured, not something THEY PLAN ON doing. Contrary to popular belief, this is not an illegal thing to ask during a contract negotiation or an interview process.

2) It may look benign, stupendous even, and you should already be doing this, but actually read the damn contract thoroughly, completely, and infer as much as you can. Although skimming it makes you feel cool in front of the suits hiring you, it is a stupid move. ASK QUESTIONS!!!

And if they are offering you a sign-on bonus, read it with an even greater detail and attention to detail. Typically, they will hook you for the sign on bonus and then you are stuck in somewhere like Beirut ducking mortar shells trying to changing all your ArrayLists to List generics for a WebPart. Ye Ha!

3) Check the History of the Company on Indeed.com

There are a lot of unbiased opinions of companies that are available on Indeed.com from people that have worked through past headhunters or for those exact larger companies that you are negotiating with. Can really be a lifesaver, since the people that are posting on it have either already been staffed there, or have had some sort of relationship with the company already, and really don’t have a ton to gain by posting something either good or bad. There might be other sites for this that I don’t know about, post in the comments of this post if you know of any that would be helpful for other people.

4) Ask Whether This Is the Organizations First SharePoint Project

If it is, you are probably going to have to play the role of the management assistant as well as being subject to any development tasks. Expect to sit in meetings while a clueless PM lurks over at you for any semi-technical question. Generally, I try to pass on these contracts, unless the bill rate is enough to cure world hunger since requirements tend to be loose and scope creep is fairly constant since the PM will assume immediately that you can do everything and do an obligatory “yes sir” for anything the client asks for. At least you get to feel cool and capable.

5) Ask If The Same Team Will be Used throughout the Duration of the Project Lifecycle

This irks me a lot; you establish a bunch of relationships with people, and all of sudden three months later you have to do it again with a brand new team. It is preferable, at least to me personally, that you are with the same team during the duration of the project. Think about it, you just spent 300 bucks buying people drinks at night that you are never going to see again, how bad does that suck?

6) Ask If They Are Outsourcing

If they are, make sure that you are compensated suitably because you will be staying up generally pretty ludicrous hours in the evening, so you should be paid for your time you are working at home. That and you will be doing a whole lot of code reviews, and will be on the receiving end for a lot of code hand off that you may or may not have to end up retrofitting to a lot of organizational development standards.

7) Ask How They Arbitrarily Manage Projects, Generally (SDLC, etc.)

This is so important. Although it doesn’t have to be a deal breaker, it can really make your life miserable if you practice Agile SDLC concepts and the organization enforces a CMMI software development model. Outside of the SDLC query, you should ask the architecture of how they typically manage a project from inception, to requirements, to delivery. If there is no PM assigned, be ready to interface with clients all day. If there is no program manager, be prepared to handle a lot of budget things. If there is none of the above, you’re a one man show, and I don’t envy you that much.

8) Ask About The CLIENT DRESS CODE. Not The Dress Code At Corporate.

Corporate may let you come in your birthday suit swinging in the wind; however the client may want you to come on with a three-piece pin strip suit everyday looking like John Gotti. I wear flip-flops to work everyday, and it is something I ask right away, since I really hate wearing shoes. I also push the limits and always ask if I can wear a hat. Just ask about the clothes your feel comfortable in, no one likes developing in a something fit to attend a funeral in.

9) Ask How They Will Review Your Code

If they just kind brow you after asking this question, you might have some trouble, because your efforts are not going to incredibly visible to the people signing your check. Sometimes complex business problems doesn’t have an insane amount of visibility (like if you are doing a Workflow project that automates a lot of legacy business processes that just automate redundant tasks), so it is important that at least someone knows that you aren’t just sitting around and playing FreeCell all day. Just make sure you have SOMEONE that you can show, and who understands, your deliverables.

10) Ask If There Is an Hour Cap

This is important, try to cap off your hours, you aren’t a slave. People always try to squeeze the most that they can out of developers, and they will really exploit you if you don’t get an hour cap. Write this into your contract, so that if the cap expires, you get paid overtime, or there is some sort of bonus structure setup. What it breaks down to is, GET PAID FOR YOUR WORK.

11) Ask If They Have a Standardized SharePoint Development Image

If you are a tools person, not asking this will kill you. They might have enterprise templates for Visual Studio that they are using, or some other development control mechanism, and you will be stuck with what you have. If they don’t, ask if you can use your own image for development since you already have all your tools, etc. on it and it generally makes you more productive. And if they say no, ask about the length of time that you are afforded to put together your SharePoint VPC. We all know that this can take a freakin eon even if everything does go smoothly, and if you have to report your work accomplishments at the end of the week they are aware why you didn’t write a line of code.

12) Ask About the Method of Source Control That Contractors Use

This is important because if you are keeping it on your laptop, you are in jeopardy of losing a lot of money. Your laptop could get stolen, and then you have nothing to deliver to the client, and they will argue with you, or your sponsor, that they shouldn’t have to pay for anything that they never received. If they have an internal one, make sure you use it as diligently as you would for a corporate position. It also lets the client track your progress without having to come talk to you, which is nice.

13) Ask About Code Documentation

If they say they don’t require any, that is great, and get ready for maintenance extension on your contract (personal opinion). If they say you have to document it in all in Word, I meant re-think the contract unless it is a fairly thin amount that is expected, because you will be a whole lot of maintenance on the documentation itself. If they have no clue what you are talking about, use Ndoc and the will be impressed with your deliverables, and you will probably get an extension as well because it looks all nice and complicated. Just ask so you know what to expect.

14) Ask Where You Will Be Located, In the Building Wise and Where The Building Is Located

This is important. Since you will be a temporary employee, you might end up next to the water heater with a milk crate to sit on if you don’t agree on something beforehand. But, on the good end you will become friends with the janitor. Check out around the building too, if you are like me, you want to be able to walk to a place to decompress during the day (need the Bucks baby!), and make sure there is a Smokers Output if you smoke (I do, this is clutch).

15) Ask About Any Third Party Software They Are Using For SharePoint Development

Because it really may not tickle your fancy. If you were recently burned by a particular set of software, and they are relying on it for like interface components on WebParts, you are probably going to have to use it. If they have spent a lot of money on a control set, they are probably going to want you to use them, even though you might not very productive with them. Its better to find out about these possible issues before they become a problem.

Hopefully this is a good start that other people have some input on. It was at least kind of fun to write.


9 thoughts on “15 Ways / Questions To A Smooth SharePoint Contract”

  1. So, how are things at work now? from reading between the lines on this post, there might be some things you don’t like there too?

  2. Hi Adam,

    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.

  3. Valerie:

    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!)

  4. Pingback: Sharepoint BUZZ
  5. Adam,

    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

Leave a Reply

Your email address will not be published. Required fields are marked *