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.