10 Steps for A Military SharePoint Contract

Recently a friend of mine won a substantial SharePoint military contract which I contributed to the RFP for since I owed him a favor (your welcome Kirk for my entire weekend). Although he has been doing SharePoint since it was Tahoe, he had on no account held a military contract, and was wondering about some pointers that he could take in that would facilitate reduced resistance, and increased applicability while engaging on the SharePoint project. As a result I started writing a personal email to him regarding some concepts since I just moved back into the private sector so felt equipped to, which hurriedly I could see as being a constructive post so determined to put it out there for the community.

Now this is all subjective, and might not translate to all military SharePoint contracts, so take it with a grain of salt. Though I think that bulk of the points are generalized enough that it should at least provide reasonable applicability for a preponderance of military contracts, matters such as these should be looked with gargantuan scrutiny.

Military Personnel Cause More Friction Than Private Markets

This really took me a while to get used to in view of the fact that for an assortment of private SharePoint projects it can be recurrent that people are in reality eager for a SharePoint deployment. Because of the way indirect clout and influence is shared within an orthodox military structure, and while there certainly is a defined chain of command, the defined rigidity does not make it an absolute. There might be a GS 9 through 11 that has been entrenched in a unit waiting on their pension, and they are a hard sell because they have been doing things a particular way for nearly 20 years. It has worked thus far so why change it now? And while on paper the persons ranking might not be directly impressive, that person’s relationships should make you look at them like they are a SES 2 as far as you are concerned. More often than not, you can gauge the assimilation of your deployment by measuring the adaptation of the product by such people, not by the early adopters that are clearly biting at the chomp in order to leverage SharePoint. Understanding these unspoken and undocumented relationships is huge!

It is important to realize that there is a huge gap between the private sector and the military segment in this regard. In the military, you would actually think that rank is king and that is the end of it. However it is customary that relationships habitually will trump rank. Furthermore, in the military, product use can, and more often than not, will be forced by a commander if you don’t play the implementation role just right. While this seems like it would be a benefit, you will quickly find out that it is the quite opposite. The old mantra You can catch more flies with honey than with vinegar goes right out the window, and now you are not the most favorite person in your unit since you are forcing people to change the way they do their jobs. Not only is this bad for the current state of your contract and your user audience, wait until the contract is up for rebid and those identical people are solicited for feedback during the proposal lobbying.

You Are Not A Civil Service Employee. You Are A Contractor

Don’t portray yourself as being a civil service employee regardless of where you are, it is a terrible habit to get into it and can be misconstrued as offensive to civilians. Most civilians have influential reasons for being a civilian otherwise they WOULD be contractors. The line between a civilian and a contractor is NOT fine, nor should it be or ever considered to be. You don’t walk into a meeting at a private sector client and claim that you work directly for the company in some position that would clearly only exist as an FTE at a private sector firm, don’t do it in a military environment.

FFS Don’t Piss Of IA

As far as you should be concerned, IA is trump. Not only should you not cause problems with them, making a good friend in IA will span your bases and contracts. I have known my same IA contact for nearly 5 years now, and even though he is staffed permanently at a different base I will most likely never work at again, the information he gives me regarding any of my current and future contracts regardless of station is nothing less than priceless. Just don’t do things that knowingly are going to make them upset, like putting a NIPR and SIPR box within the physical proximity limits of each other. They will rip your head off, and then you are on their radar and you will get hit on each audit. It’s kind of like the IRS in that sense I suppose.

Hiring A Generic Project Manager Will Go Over Like A Fart In Church

If you are responsible for staffing, do not under any circumstances hire a generic project manager for a military SharePoint contract. A project manager in a military environment is a specialized position since they have to understand the inner working of the military, this type of knowledge is disseminated through experience and not through book smarts or nonspecific PM knowledge. While a generic PM might understand the fundamental ranking and command hierarchy concepts, they will have no clue about how the military cogs make the overall federal machine work. Unless you want to send a lamb to the slaughter, just avoid it and shell out the money for a PM either with direct military background or previous federal work history (state governments generally do not count). Going back to the above point about acclimation of product, the PM will heavily be responsible for facilitating the rely of operational information that will affect the whole project. When they get the aggregate picture along with the intricate unit workings, their contributions are unmistakably noticeable and will cause the project to run much smoother.

Don’t DARE Tell A Commander How To Run His Unit

I love it when I am in a meeting and I see someone do this. A commander didn’t get to his position because he took shit on a daily basis from contractors telling him how to do things; they are in a leadership position because they are leaders and were noticed as such. They know their unit; otherwise they wouldn’t be in command of it. Don’t try to tailor a unit to SharePoint, simply give a commander options, and believe me, he will tell you exactly how he wants SharePoint to run in his unit. Trying to tailor a process to a product is poor form anyways; a military environment is unquestionably no exception. The best mantra when working with a commander is take ever should you were about to say and switch it with a could. There are many neat portions of SharePoint that could potentially solve critical business issues; they just need to be presented delicately and with tact.

What The…Different Commander, Different Day

It is pretty recurrent that command changes ensue, at least it was in the Air Force it is habitual. Don’t let it dishearten you; unless it results in the project getting canned then I would be frustrated as well. Restructuring is incomparably common in the military because the pronouncement can come from so many directions and sources, and while some are based on timely rotations, others are to optimize the workings of the unit(s) (such as unit merges, etc.). If you substitute commanders, you must approach the new commander and show him the value in your work instantaneously. The same reasons that the old commander firstly solicited you as a contractor for must be presented to the new commander so that he can see the significance in your work since he will be unacquainted with preceding efforts. If it is not immediate, manufacture a practical case study because it is worth the time. Otherwise, there is regularly a budgetary review process as one of the first things on a new commanders list, and he/she won’t even know why that money is going to a particular project.

Use That One Guy That Has Been On A Military Contract

I can’t emphasis this enough, on most military SharePoint projects this is generally one person on the team that has already done an enterprise SharePoint deployment in a federal environment. Same branch? Tremendous! Different Branch? Not as great, notwithstanding still pretty damn good. And it might not even be the person that is judged to be the most indispensable personnel on your team. Their insight into the pre-workings of a military structure you will discover to repeatedly save your ass again and again. Even when those concepts aren’t related to your SharePoint deployment and are just insights into significant military processes.

Acronyms Are Better Than No Acronyms

There are so many acronyms. There are acronyms for things that shouldn’t even be acronyms, but because it is an unspoken tradition to turn any three letter denotation into an acronym, you really have to get used to it. And seriously, don’t bother writing them down since there will be repetition in the acronyms that are used. You will end up using the same acronym a lot, but based on the context, it will have severely dissimilar meanings. This must be taken into account for particular audiences and will lessen confusion.

Military Liaisons Are Worth The Money

Especially if they were stationed at the base your contract is at, even better if they were in the same unit and command hasn’t changed. That comradery is invaluable and the preexisting relationships will make your life infinitely easier. They do cost a lot of money, and normally their solitary deliverables are esoteric, however the difference is directly noticeable.

You Are Contributing Most Likely to a War Effort, Not a Random Business

Within a military contract the work that you are doing has severe impacts that are by and large not found in the private sector. Sure, there are definitely outages which effect private business and that is no good; however they don’t affect people in the field that are relying on your system for war support. Most developers for example will recycle an App Pool to realize a new GAC versioned assembly being deployed and not bat an eyelash. Taking this mindset into a military environment will make your SharePoint contract the quickest one in federal history. Those actions ARE noticed, ARE logged, and will be examined. People will notice that brief latency shift, and you can bet your ass that you will hear about it later.

There are so many more, but that’s about it for now! Happy military SharePoint contracting!


SharePoint Recruiters Shouldn’t Suck At Their Jobs

Generally that is what I am discovering is the case, however terse that may appear. I normally don’t peruse recruiter sites, except I got this outlandishly awesome job offer housed in one. Before I knew it, I was searching for absolute randomness on the site for fun. As I was browsing for SharePoint jobs, I established what looked to be the average SharePoint job ad, and I chuckled a bit.

I will in fact copy and paste it directly from the offered advertisement text:

SharePoint Programmer / Developer / Architect: Must have at least 7 years practical work experience in C# with building solutions on top of SharePoint. 7 years Java experience to support conversions of J2EE to .NET solutions. To support this role, 5 years of Oracle and Delphi experience preferred. 5 years experience required with MFC/ATL and Crystal Reports.

Must have 5 years of deep architectural experience with building large SharePoint farms, and administrating them in the same capacity including deployed custom development. Several years architecting and developing against ISA and MIIS preferred and encouraged, however not required.

Interestingly enough, on recruiter sites you are able to spot precisely when the job was posted. The antiquated date appended to this made sense to me since this particular position has been open for over half a year, borderline 8 months. And I will wager that no sensible applicant has dared to apply to this gobbledygook.


Because not only does the ad undoubtedly convey that the posting recruiter did inadequate technical research because of the erroneousness of technical dating (which offends job seekers btw), but they must be looking for the fabled nine armed, four brained mythical programmer that they prophecies foretell of, because for all intents and purposes those requirements are outrageous.

First, let’s pick apart the ad.

7 years of C# development experience, while being feasible, is marvelously atypical since the establishment of the C# language in common commercial markets is roughly in late 2000. So, this organization is most likely looking for a C# beta tester for when Anders Hejlsberg was still calling it code name Cool. Needless to say, this would be exceptional and uncommon.

7 years of .NET development on top of SharePoint I can see being a qualification, if STS (2001) development actually used .NET. Then it would be cool. But it didn’t. So the basic arithmetic of the recruiter sucks. Even then, you would be subject to the same time considerations as described above, making it not necessarily common.

5 years experience with MFC/ATL? Huh? I mean, I did MFC / ATL programming for a long time (it paid for college), and I have to admit I really don’t use that skill set outside of the far reaching development concepts very often. It just isn’t obligatory for ordinary SharePoint business development (note the use of the word ordinary there).

I actually can understand the Crystal Reports one. I guess. I mean I don’t use it, but it seems like in some circles it could be interpreted as a pragmatic requirement. I guess.

The conversions requirement made me sort of laugh, since that is a pretty specific skill set to want out of a developer. Because of this, as well as the larger noted SharePoint development experience, I think the organization might be more successful with breaking this into two separate jobs. To me, it’s kind of like walking into a barbershop, getting a haircut, and then asking why the barber didn’t go wash your car and walk the dog. Lazy bastard. I think coupling a C# developer that has rudimentary Java skills with a Java developer with basic C# skills would produce higher quality code conversion, most likely in a more reasonable time frame since those two programming schools tend to stay siloed in their language of choice. Even though in my experience code conversions just end up being a software rewrite anyways.

When the recruiter starts to talk about wanting the SharePoint developer, architect, and administration full package, I start to get a little frustrated. While there are certainly people that can wear all these hats, very well too, generally they become too busy divvying themselves up between tasks spawned from owning those assorted roles habitually those tasks never near completion. Only little increments are accomplished, never leading to closing. People often times like to specialize in a certain aspect additionally, and pride themselves in knowing all the ins and outs of that niche. I like doing architecture, but I love doing development. Furthermore, I simply loathe administration. It doesn’t mean I can’t do it; I just don’t enjoy it as a job role. It doesn’t blow my hair back.

The ISA and MIIS requirements are asinine if it is anything but a proof of concept or a small deployment. This should be principally noted with the MIIS requirement; the recruiter should be looking for someone that continually focuses on identity management systems when standing that up. Knowing those concepts to the metal vastly increases chance of project success. Like I said in a previous point, you don’t ask your barber to cut your grass. Unless your barber is just genuinely charitable and bored.

Consequently what happens when you are the recruiter that placed this ad out into the wild? You do a dance of joy because low and behold you found a hidden genius that satisfies hopeless requirements (not just meaning that they are hard, they really are impossible)! Yeah! Diamond in the rough! You rule! And he is willing to do it for 40k a year!

But what does your organization end up with?

The quintessential, yesss-sssir guy, whom only has the qualification of being a professional impostor and habitual liar. Fundamentally you have someone with an archetypal psychological complex tailored around satisfying people even though that satisfaction is bogus. Meaning, they are full of shit. I am not saying that to satisfy all the requirements is impossible (assuming that technology timeframes were right). It’s not, however it is decidedly unlikely. More than likely, they might *know* these buzzwords, read about it a bit, but don’t have deep experience. I have minimal Delphi experience, and very, very brief Oracle experience. Although I have used these, I don’t list them as skill sets of mine. I am not proficient enough. If they were mentioned at a job interview as required, I would throw sand in the interviewer’s eyes and flee on foot.

So I propose the following to SharePoint recruiters…

Firstly, be sensible with your project needs. I know it would be nice to have a methamphetamine IV feed developer that consistently practiced other technology facets locked in the closet that only required fish heads for substance doing your project work. I wouldn’t mind one of those myself. But it isn’t rational. When defining roles for a SharePoint implementation during the project planning process, it is healthier to have more jobs divvied up based on specialization rather than constrained numbers trying to overexert themselves out of their specialty. The former has proven, at least in my personal experience, while taking a large toll on budget tends to lead to enhanced quality of deliverables and probability of aggregate project success.

Secondly, tailor their SharePoint job ads to be more specific. Don’t be so vague. You clearly have a project, with a defined project scope (hopefully), project WBS’s (even though you are mocking people), and other project documentation. I don’t understand why this isn’t kept in mind when you are making your staffing decisions. I appreciate keeping it ambiguous because who doesn’t like the brain-surgeon-that-worked-charities-while-saving-puppies-from-burning-houses-but-now-does-awesome-SharePoint-development-guy, but your advertisement requirements are not practical. One of the most important portions of project planning is to define the roles filled by project team members and the responsibility of each role. I really doubt that there is just one role defined as everything besides the project manager.

Lastly, for Christ’s sake, research the technology that you are advertising for. You don’t have to know it very well, you just have to know it enough to *find* someone that knows it a whole lot more than you do. If I wanted to find a good dairy farmer to get some milk, I don’t have to know how to milk a cow or manage a farm, I just have to know the basics of the milk I want. The same goes when you are building technology requirements. Kinda.