SharePoint Fatigue Syndrome
Hiya
I have been wrong about many things – I am happy to admit that. In SharePoint land, one of my bigger naive assumptions was that in early 2007, I figured I’d have maybe a 6 month head start before the rest of the industry began to learn from its initial SharePoint deployment mistakes and start delivering SharePoint “properly.” I thought that I’d better make hay while the sun shines, so to speak, as the market would tighten up as more players entered it.
Yet here we are, heading to the latter half of 2011 – some five years later. As I continue to go into organisations, whether in a SharePoint remedial capacity, or a training/architect capacity, I am still seeing the legacy of really poor SharePoint outcomes. Furthermore I am seeing other, frankly disturbing trends that leave me both concerned and pessimistic. I now have a label for this concern: “SharePoint Fatigue Syndrome.” SharePoint Fatigue Syndrome is hard to define, yet its effects are there for all to see. I suffer from it at times, and I am certain others do too. As an example, recently on the Perth SharePoint User Group on LinkedIn the following topic for discussion was raised:
Hi folks, as you already know we have a worrying skills shortage in SharePoint Development / Architecture in Perth and things are getting worse. It’s getting to the stage where companies have to suspend or worse still abandon their SharePoint projects due to lack of available talent. As the core of the SharePoint community in Perth your suggestions are vital towards finding real solutions to this growing problem. What can be done?
Now I know that this problem is not just limited to Perth. There are consistently reports online that speak of SharePoint people being in demand. So you would think that in a “hot” sector like SharePoint, where the industry is crying out for talent, that the rate of attrition would not outpace the uptake of new talent. After all – money talks, right? If you are a .NET developer with half a brain, there is serious money to be made in SharePoint development land. On top of that, there is the collective realisation in the marketplace that actually talking to people about how SharePoint could make their lives easier, leads to better outcomes. Hence the emergence of this notion of a “SharePoint Architect” with a more varied skill-set that just tech or dev. This role has further been legitimised by entire conferences now just catering to the business this end of the market (I am thinking the Share conferences here).
So, we have all of this newfound collective wisdom spreading through the community via various channels, in terms of the skills and roles required in SharePoint circa 2011 and beyond. We have the fat pay-packets being commanded as a result of demand for these skills. So, with that in mind, why is the attrition rate growing?
As an example, I know personally, several exceptional SharePoint practitioners who are no longer in SharePoint. I’ve also had various quiet conversations with many SharePoint practitioners, right up to SharePoint MCM’s, who vent their various frustrations on how difficult it is to get truly lasting SharePoint solutions in their clients and organisations. I’ve reflected on the various reasons I have come to the conclusion that SharePoint is just plain tiring. As a result, people are burning themselves out.
7 causes of SharePoint Fatigue Syndrome…
Burnout, in case you are not aware, is actually a lack of emotional attachment to what you are doing. Quoting about.com:
The term “burnout” is a relatively new term, first coined in 1974 by Herbert Freudenberger, in his book, “Burnout: The High Cost of High Achievement.” He originally defined ‘burnout’ as “the extinction of motivation or incentive, especially where one’s devotion to a cause or relationship fails to produce the desired results.
SharePoint Fatigue Syndrome is SharePoint manifested burnout. The symptoms include feeling physically and emotionally drained, difficulty maintaining optimism and energy levels, feeling that you have less to give as the burden of work seems overwhelming. Sound familiar?
So why does SharePoint work run this risk? I see 7 major reasons.
1: Cost pressure leading to overwork
First up, the lure of the big dollar is a double edged sword. Not long ago I shared a beer with a SharePoint developer who’s work I respect greatly, yet I can’t afford to hire. This is because the percentage of chargeable hours he would need to work just so I can break even, is very high. This puts me (the employer) under pressure and at risk. As a result, I need to ensure that my newly minted SharePoint employee is productive from day 1 and I need him to work a lot of hours. But here is the irony. When I had my beer with this developer, the conversation started with him lamenting to me that he is already pulling ridiculous hours (60 to 80 per week). He was looking for a job with less hours and yet more money. This is simply not sustainable, both for employer and employee. The more you chase one (work hours vs. money), the more you lose the other it seems.
2: Structures that force an inappropriate problem solving paradigm (and wicked problems of course)
Then there is the broader problem where structure influences behaviour. As a basic example: from the developers’ perspective, they have to put up with sales guys who promise the world, and project managers who then make their life hell and force them to cut corners delivering the impossible. Project managers find out that their beloved work breakdown structure gets chopped and changed when their pain-in-the-ass developers whine that they can’t make the schedule. As I have stated many times previously, SharePoint project are likely to have wicked problem aspects to them. The structures that work well to deliver tame problems, such as Exchange, a VOIP system or a network upgrade, are much less effective for SharePoint projects. While organisations persist with approaches that consistently fail to deliver good outcomes, and don’t look at the structural issues, the attrition rate will continue. There is only so much that someone can take putting up with these sorts of stresses.
3: Technical complexity
SharePoint’s technical complexity plays a part too. No-one person understands the product in its entirety. The closest person I know is Spence and ages ago on twitter he remarked that even within Microsoft no-one understood it all. As a result, it is simply too easy to make a costly mistake via an untested assumption. (I thought the user profile service was tough – until I did federated claims authentication and multitenancy that is). The utter myriad of features, design options and their even greater number of caveats, mean that one can make a simple design mistake that causes the entire logical edifice of an information architecture to come crashing down. Many have experienced the feeling of having to tell someone that the project time and cost is about to blow out because nobody realised that, say, Managed Metadata has a bunch of issues that precludes its use in many circumstances. Accordingly, SharePoint architects learn pretty quickly that it is hard to answer a definite “yes” to many questions, because to do so would require a question worded like a contractual clause, to ensure it is framed with appropriate caveats. Even then, consultants would know that lingering feeling in the back of their mind that they might have missed an assumption. This brings me onto…
4: Pace of change
This is BIG…and becoming more acute. Remember the saying ‘The only certainties in life are death and taxes?’ Outside of that, the future is always unpredictable.
In between SharePoint 2003 and SharePoint 2007, the wave of Web 2.0 and social networking broke, forever changing how we collaborate and work with information online (and some of those effects are still to be felt). Microsoft, like any smart organisation, responds to the sentiment of its client base. Microsoft also, like most mature organisations, tends to hedge its bets in terms of marketplace strategy in which it tries to get in on the act with the cool kids, yet tries not to kill the goose that laid the golden egg. Just look at Windows 8’s new interface, tablets, app stores and the cloud.
But that is one facet. Change happens in many forms and at many scales. For example, at a project level, it may mean a key team member leaves the organisation suddenly (SharePoint fatigue no doubt). At a global and organisational level, events like the odd global financial crisis force organisations to change strategic focus very quickly indeed.
I don’t know about you, but when Windows 8 was announced recently I was not excited (in fact I was not excited by SharePoint 2010 either). I thought to myself “So soon? I am still figuring out the current platform!”
As an example of the effect of pace of change, consider all the Government 2.0 initiatives around the world. Collaboration is in-vogue baby, so information should be free and government agencies should engage with the community. While that’s nice and all, there is the world of compliance, security and records management that takes a very different view. So, we end up with market forces that push against each other in combination with vendors hedging strategy of being all things to all people. It’s little wonder that SharePoint projects become very complex very fast.
By the way, it is worthwhile checking out what Bill Brantley in this post sums up the whole government 2.0 issue when he said:
What exactly is the nature of the Gov 2.0 challenge? This question was inspired by Andrew Krzmarzick’s post (What Gov 2.0 Needs Now: Managers, Money and Models) and Christina Morrison’s post (What is Gov 2.0? A survey of Government IT pros) on the recent GovLoop survey about Gov 2.0. As Andrew and Christina argued, the survey demonstrates many differing perspectives on Gov 2.0 in terms of what it actually means and how to implement Gov 2.0. To me, this suggests that Gov 2.0 is the classic wicked problem
5: SharePoint Entropy
One of my clients (who you will meet in my book when it’s published), once said to me “All good ideas eventually deteriorate into hard work.” This is a nice way to lead into the concept of SharePoint entropy, which in some ways is the inevitable outcome from the first four symptoms. The easiest way to understand entropy is to watch this awesome TV series called the “Wonders of The Universe.” In that show, the concept of entropy was discussed and for me made a lot of intrinsic sense. Without getting into the detail, entropy is the notion that over time things move from an organised to less organised state. Rather than have me waste your time trying to explain it in prose, let’s listen to the show in question. (Don’t skip the video – this is important!)
Now what does this has to do with SharePoint fatigue? Gordon Whyte saw what I am getting at with his post on entropy within organisations, especially in relation to change management.
For example, when we build a car we take raw materials such as metal, leather, plastic and glass and arrange them in a highly organised way to make a car. But if we then leave that car for long enough the metal will rust, the glass will become brittle and break and the leather will dry out and turn to dust. If the car is left for a very long time it will eventually disappear altogether. This thought left me wondering about the nature of organisations. If a progression from order to chaos is the natural order of the universe, then is this same pressure present in organisations and, perhaps more importantly, what is the optimum position for an organisation between the extremes of rigid inflexibility (low entropy) and complete chaos (high entropy)? This question is not as crazy as it might at first appear”
Gordon has nailed the issue in his post. Any SharePoint solution that has a low entropic nature requires more energy and effort to maintain that order and control. Complex SharePoint solutions often have complex governance wrapped around them. Governance that is process and structure centric by definition, has low entropy and accordingly, needs higher effort to maintain over time. In fact, if you do not maintain that effort and energy, then any SharePoint solution will usually disintegrate back into the sort of information management chaos that gave rise to SharePoint in the first place! Rather like the sandcastle in the video.
By the way, I feel that email and file shares are high entropy solutions – all failed SharePoint projects lead back to these tools because they require less structure to maintain (in the short term).
In short, if SharePoint is implemented with low entropy, more energy is needed to maintain it. Remove the energy and very quickly, things become chaotic again. Governance approaches that are not cognisant of this will never stand the test of time. The question then becomes whether people feel that the end in mind is worth the perceived extra effort that is being asked of them.
6. Social complexity
Social complexity is also somewhat of a result of the first five symptoms. Most organisations have a blame culture. If they didn’t, then people wouldn’t spend so much time trying to position themselves for blame avoidance. Social complexity is the result of turf wars, ideological smackdowns and all of the other sort of things that result in the cliché of “the silos” where people are not talking to each-other in organisations. SharePoint exacerbates social complexity for two main reasons.
Firstly, because it is a collaboration tool, it actually requires some collaboration to put it in! This is often easier said than done. Secondly, because it is a pervasive and disruptive technology, it almost always clashes with an established tool, process or practice where proponents aren’t willing to change. In fact, they may not even recognise that there is a problem to solve – especially when SharePoint has been thrust upon them. (In an old post, I wrote about the notion of memeplexes and the ideological immune mechanisms that they create and why it is so hard to get shared understanding across departmental boundaries in organisations. Memetic smackdowns are the result).
The long and the short of social complexity is that there is only so much stress people can take. We all seem to have a pathological need to seek order and safety, rather then remain in a stressful situation. Once social complexity bites, the merry-go-round of staff attrition really starts to bite…
7. Meaning over motivation…
Now if I haven’t completely depressed you, let me offer you a perverse glimmer of light. For those of us who understand the preceding 6 fatigue symptoms, recognise them for what they are and take steps to mitigating them, there is one other symptom that contributes to SharePoint Fatigue Syndrome. This is the trickiest of all – and I am a somewhat willing victim of it.
I have spent a lot of time learning techniques to help address the symptoms I outlined here and as it turns out, these skills are universally applicable, whether in SharePoint, IT or beyond IT. For years now, I have metaphorically had one foot out of the SharePoint world door and the other foot into the world of construction, health and management sectors. Hell…I have written what I think is the first business book ever by a SharePoint person that is a non SharePoint and non IT. I also have clients with SharePoint deployments who do not know me as a SharePoint person at all, but only as a sensemaker (and for that I am grateful.)
The point is this: While the investment in these skills enables me to counter the effects of SharePoint fatigue syndrome, it is also inexorably pulling me away from SharePoint work. It seems that once you crack this nut a little, your skills are in demand across the entire problem solving spectrum. Right now this is my coping mechanism for SharePoint Fatigue Syndrome – I get to step away from SharePoint for periods and work on something else. Eventually…inevitably…I will also be one of those attrition statistics.
Conclusion:
The problem is that SharePoint Fatigue Syndrome is a negatively reinforcing cycle. As evidenced by the SharePoint attrition rate, money isn’t that great a motivator. If it was, then the void of skilled resources would have been filled by now. Paying more money might give you a short term gain, but in the long term is not going to address my seven causes of SharePoint Fatigue Syndrome.
I will leave this admittedly negative sounding post with the key to breaking this cycle. While you can attend my SharePoint Governance and Information Architecture class or Issue Mapping Class to learn many ways, the video below says it all. I encourage you to watch and reflect on it, because it’s the same key point to understanding how to do effective user engagement.
Thanks for reading
Paul Culmsee
Instead of planning their SharePoint deployments, most companies are waiting for the wind to spontaneously deposit sand in all the right places to build their castles. And then are somehow disappointed when it doesn’t happen. In a way, SharePoint is like a Rubik’s Cube — it loooks like a toy, but is much much more complex. Most people start out with simple moves, mixing the colors, but when the thing gets messed up, they put it down and walk away in frustration. But those who take the time to learn how to use it will find that they can solve any mix (problem) by following the same process each time.
I agree with Christian. Pretty much every site I go to SharePoint is driven by an IT heavy team whereby the business do not realise this is not like implementing Exchange, SQL or another piece of technology that has a clearly defined role within a stack. SharePoint has to be an enabler and before it can be this, the business need to clearly understand their processes and what it is they want to enable exactly. Only then can you start to build a platform that 1) meets the client expectations and 2) can be architecturally designed to scale with the business vision (my god, when I mention Vision I usually get a lot of blank faces).
Love the idea of “SharePoint Entropy”. Personally, I think this should be a slide on every SharePoint deck. Now, how to visualise it….
Once again, Paul, you’ve got things spectacularly wrong. No, just kidding – you’re right on all counts!
I am one of the disaffected you describe as “burned out”; I quite literally cannot bring myself to care about SharePoint much anymore, and I know a good number of professionals in Toronto who feel the same way: We can’t wait to get away from it, even as the demand for our talents goes ever higher.
Why? For God’s sake, why would we feel this way?
My fatigue with SharePoint came from my two-year stint as a consultant with Microsoft Consulting Services (MCS). In that time I was assigned to some absolutely lucrative yet completely unproductive and ineffective projects. They all had a sameness to them that felt like wandering around an infinite loop with no escape – a consequence of, as you talk about in your classes, SharePoint being a definitive “wicked problem”. I began to see the complexities being disregarded and SharePoint the hammer that viewed all customer problems as nails.
My days began to devolve into very dissatisfying exercises in offering the same guidance that would never be taken up, coming up with the umpteenth workaround for the platform’s shortcomings, etc.
Compounding this disenchantment was a complete mismatch of project management approaches that changed little over my six year career working with SharePoint: It almost always defaulted to big-design-up-front, waterfall which for a SharePoint project, is absolute suicide: There are literally so many variables, from the technology’s unpredictability, to poor user requirements to emergent answers to the team itself that make it extremely risky.
This contributed to some really miserable experiences putting in overtime to try and meet obligations on schedule and cost that I had no hand in setting. My burnout took a while, but when it came it was almost absolute.
So, I find, as usual with most things you write, I’m nodding violently in agreement with your points 1-3 and 6 above.
On point 7, my coping mechanism was to continually press for the introduction of agile process frameworks like Scrum and commensurate developer skills to improve the quality of solutions and reduce defects. Over time, as I won and lost battles, the disenchantment with SharePoint grew. It ultimately led to my decision to start a new business this past April to help teams and businesses undergo agile transformations so they could begin to cut through their wicked problems and deliver ROI, irrespective of platform.
In this respect, I’m a happy attrition statistic. There’s more positive things I can do in my new role than I could ever accomplish trying to coerce a complicated SharePoint solution into a pointless, plan-driven, phased exercise with unrealistic goals and poorly understood requirements.
Chris R. Chapman
President & Founder, Derailleur Consulting
Paul, one of the big problems I see (and this relates to / is a subset of your points #2 and #6) is that companies hire SharePoint resources to deliver a technology solution, when half or more of the battle lies with the human, cultural issues within an organization. SOWs are typically not scoped to include much time for assessment, strategy, roadmapping, workshops, etc. To your point #7, the companies that dedicate the budget to hire this kind of problem-solving skillset may still be in the minority. Good consultants know how to work this kind of advice and recommendation in where they can, but speaking frankly, if you’re already working a ton of hours (point #1) you’re going to be less likely to do the kind of consideration and preparation that are needed to make your case for a strategic focus if you’re not able to bill for it. And that disconnect can definitely be fatiguing.
Always love your writing Paul and always agree (as if there was ever anything to disagree with?)
Add me to your SharePoint burnout list – I’ll be done here before this year closes…but this passion for the technology will hang on to me for a long time. I think that passion we embrace is what drives us to fatigue; love of what we are doing and those we are ‘doing’ it with (the community)! Some part of me is envious of those who just do SharePoint as a job….and yet, I have to wonder if they are really just droids in human clothing? ha!
Thanks for the great post Paul!
Chris, you were one of those prople I was thinking about when I made that point about people who have left SharePoint. I also appreciate you sharing your story. There are several others like you too…but I better not mention names as I might get in trouble.
In the book I describe working in project alliances and how the structure it creates to foster collaborative proble, solving. It can add, what I think, is the missing bit of some agile methods. But of course you have already read it 🙂 I think it takes what you do intrinsically with agile and make it more expicit (ie holding environment). I am so looking forward to being able to promote the book when the publisher approves the artwork 🙂
regards
Paul
Hi Kerri
In 1989 I saw the video clip to Queen’s “I want it all” on TV and was instantly hooked on the band. With passion burning bright I eventually came to own their entire back catalogue, solo records, rarities, etc. In classic trainspotter fashion, you can ask me anything about the band and I could answer just about anything. For several years I listened to no other music…
Did that passion last? No. Is the passion gone? Also no.
What the? Although I still like the band a lot, and at times shake my head and say “Damn they were a cut above”, time has exposed me to other bands (Opeth – hehe) and other music. If you manage not to burn out, passion will eventually turn to *pragmatism* I think.
The reason I tell that story is because I have always had that kind of pragmatic passion for SharePoint. I think it is because I did document management systems prior – going right back to 1998. I’ve never hated SharePoint, but I’ve never gushed over it either. I think this is really important, because I think being passionate can create a lens that is rose-tinged. Marc Andreson wrote about this when he said the SharePoint community can be insular.
There is definitely a cultural thing too. Australians aren’t exuberant in the same way Americans are. We definitely whine more, as evidenced by my posts 🙂
IMHO too much time gets wasted arguing about structure (which is inevitably going to be organic anyway if it is going to be ‘living’) and too much information gets put on the resulting site with too little purpose or sense of role/responsibility attached to it. Just my two bits.
Paul, Okay, so in an effort to equate this passion for Queen with the struggle that is SharePoint, I’m thinking that you’d have to consider a twin who does not share your passion for the band. While you amass these band treasures and are recognized as a knowledgeable member of the fan club, your twin who can stand the band over the radio waves on occasion really won’t tolerate any repeated play. Your desire for Mr. Mercury is reduced to playing 45s in monotone because your parents, not understanding the battle between you and your brother,side with him in a preference for his old-time country music, thinking that anything so boldly named after a monarch must be dangerous.
Your love of the music drives a wedge between you and your twin and the only course of action is to leave the home you’ve known for 18+ years to find a new one with Queen lovers…
Only by then you’ve moved on and decided that you are your own rock star and you will make your own music, form your own band, and tour the world yourself.
Yeah – I can totally see that analogy!
Paul, Great post as usual. I have always believed that when people work together to accomplish something, and don’t care who gets the credit, great things can happen. And people working together is what collaboration is all about. I suffer from the burnout as a result of not seeing people work better together (for various reasons, with technology being a minor part of the problem). Laurie Buczek wrote about the burnout she felt, which resulted in leaving her role of managing internal social collaboration at Intel. You can only bang your head against a wall for so long I guess.
Fantastic insight:
“In short, if SharePoint is implemented with low entropy, more energy is needed to maintain it. Remove the energy and very quickly, things become chaotic again. Governance approaches that are not cognisant of this will never stand the test of time. The question then becomes whether people feel that the end in mind is worth the perceived extra effort that is being asked of them”
Paul, nice post mate. You make some very good points about SharePoint entropy and burnout that I can draw direct parallels to my SharePoint experience. I remember at a previous company we did a WSS to MOSS migration and a dedicated core group of which I was a member basically lived at work for almost 2 weeks to build a shiny new “perfect” environment and bring the content over into the new structure. Then watched over the years as it slowly eroded away as the system support team struggled to keep our “castle” from falling over. The burnout factor sounds like a very common story, which is probably why I’m moving into project management. lol
Paul – as usual you hit the nail on the head. I think your concept of the “wicked problem” is spot on – you did a great job of fleshing that out at the FEDSPUG/WSPDC webinar.
It’s nice to see someone put a name on this phenomenon – I was wondering why, on the Metro home the other day, why I still spend weeks (if not months) on client engagements undoing past errors, educating folks on capabilities (i.e. “this is not a fileshare”), and reframing planning and deployment scenarios from “how many servers do I need?” to “let’s talk about information architecture, business architecture, wicked problems” first. I, like you, thought that some of that would go naturally go away with the evolution and maturation of the platform from 2007 to 2010 but it clearly has not.
I see the legacy of “product mentality” everywhere – there should be no difference between a SharePoint deployment and custom Drupal, Java or ColdFusion build (requirements, UI/UX, IA, should all be part of the SharePoint SDLC) but sadly, the “plug and play” mentality persists and I think underpins the staffing issues, short term focus, developer driven deployments and lack of attention to “wicked problems” you so elegantly pointed out above.
Thanks Paul!
Paul,
Really good post. I try to remind myself daily how lucky I am to be so fabulously rewarded for something I love to do, but as days go on I too increasingly feel the fatigue of demands placed on me and my team to deliver these complex SharePoint solutions within dynamic environments and under intense time constraints. For now, I still start each day with an enthusiasm and a passion for what I do, but I also know that someday I will wake up and think “I’m done. I’m burnt out.” and then I too will become another statistic in the SharePoint space …
Very perceptive remarks, Paul. I agree with so many of your points. Like you, I thought that by having 5 years of experience with MCMS before working with MOSS, I would enjoy 6 months or a year of a head-start in SharePoint consulting before the market became flooded, but here it is 2011 and I live in a metropolitan market of several million people and I literally know of only one other freelance SharePoint consultant like myself. I get asked at least 3 times a week if I know any available SharePoint folks.
Ironically enough, many people see the lack of available SharePoint talent and decide to start consulting companies, but unfortunately they don’t “grow” new SharePoint consultants, which means there’s the same number of people who can actually do the SharePoint work, and now twice as many sales guys out there trying to sell SharePoint jobs. Along those lines, I finally decided to get my MCT certification so I can actually train my clients, using real curriculum, how to develop and maintain their own solutions. I figure this is “elevating” my city as a whole in terms of growing new talent.
Aother thing I wanted to add. Having started off my career working with Microsoft Content Management Server, I still tend to build Publishing sites for clients. About three quarters of these sites are Intranet sites, about a quarter are public facing. The great things about Publishing sites is that, on the governance spectrum, they are by nature on the “highly controlled” side of things. In fact, along those lines, I steer clients *away* from using all the features of SharePoint. As a consultant, I feel like one of my primary jobs is to reduce complexity as much as possible in the SharePoint solutions I help my clients develop. (Right now, I have a client who is just starting to wrap her mind around all SharePoint can do and is getting very anxious, and I’m trying to reduce her anxiety by communicating to her that we won’t use every feature there is in SharePoint.) I’m finding that my role as a SharePoint consultant often means not trying to architect some monsterly huge SharePoint system that takes lots and lots of control, but to help my clients know which features of SharePoint to leave out, thus balancing “high” and “low” entropy solutions, as you would say.
At the end of the day, working for myself has prevented me from burnout. I have the freedom to not take projects that are doomed to fail, and if I do find myslef in a nasty situation, I simply take it as a personal challenge. However, at the end of the day, an organization has to own their own solution, and I can only point them in the way they should go. Knowing your own limitations is also a key to preventing burnout when it comes to SharePoint.
Great comments Becky
Your approach is entirely consistent with mine. I introduce SharePoint in bite sized chunks and I read where a client is at, based on the maturity in the questions I am asked. This is the sort of approach I outlined in my folders vs metadata post from some time ago in terms of the notion of “productive distress”
http://www.cleverworkarounds.com/2009/09/30/folders-are-bad-and-other-urban-legends/
regards
Paul
Hi we have same customers which haven’t any problem with entrophy. in 2007 we setup same basic provisionning, and sharepoint i still consistent.
PS i’m in Project Management since Microsoft Project Server 2003 and sharepoint is just add on :o)
Like you I have many customers with no problem with SharePoint entropy. I really should do a followup post on how we have managed that… (mind you half the cleverworkarounds blog tells you that answer)
Paul great points as always. There are very real dangers and risks you have outlined. Excellent comments as well!
When I read this though I thought: When has it ever been just about SharePoint?
Nothing you really mention is “SharePoint Fatigue Syndrome” it’s “other stuff fatigue syndrome” no?
On every single engagement I have ever been on (and my two years at two very different companies working internally) even though I was/am hired due to my SharePoint focus I don’t really think of myself as struggling ever with SharePoint. I actually don’t think so much about “I do SharePoint” though it simplifies explanations to friends and family.
In fact most of the time it’s doing the requirements gathering, the listening, the advising, the creative process of coming up with solutions to challenges… Even though SharePoint is the tool I use when I am doing it, I never really think of the work I do as “SharePoint Work”. To me what get’s me super excited everyday working at my job (especially consulting on site with clients) is that we are solving real problems! We are using technology to make peoples jobs easier, to help people do more, and to share and learn from each other in new ways.
I LOVE working in a collaborative, content driven, and process driven space. It means everyday I am encountering new challenges and problems. Learning more and adding things to my ‘toolbelt’. For the past 7 years of working with SharePoint I think what keeps me extremely enthusiastic and movivated (on all Microsoft technology) is that I never once thought of what I was doing being technology specific. I am familiar with SharePoint, I know it better than I know… well maybe anything else from a technical perspective, but that familiarity is just another reason I get to focus my time, mental energy and more into figuring out how to solve problems and other creative/fun aspects of my work.
I love finding bad deployments. I love finding horrible Governance plans and lack of any business strategy. It’s when I find those that I feel like I can really make a difference. Where all of that dedication, learning, and focus can help someone do something great. It validates the effort I put in, and lets me share those tools I have refined (and still add to everyday).
Paul I completely agreed with what you wrote, but it didn’t damper my excitement at all. If people are feeling like they are burning out maybe they are just working in a way that causes too much friction. Go with the flow of what you care about, feels right, and matters to you (regardless of your job). If none of that works then maybe change can be the catalyst to make things better and you can pass that torch on to someone else (or ignite the fire in them so to speak).
I say. Burn baby burn. 🙂
Hi Richard
Your reply essentially validates the point made in the video I ended with. Meaning over motivation. You get meaning from the work you do and that keeps the fires of passion burning bright.
But there is a key point missing in your reply that I did not make clear enough in my article. Like you, I really enjoy the sort of work you describe. But for every Richard Harbridge that comes along, there are those who move to other pastures the the reasons I outlined. The meaning is not there. Go back to the premise of my article – that linkedin user group question about the critical skills shortage and my contention that there has been long enough time to fill the gap. To that end, I maintain there is a SharePoint fatigue syndrome. Yes those other factors apply to other projects (and that was deliberate on my part), but I was talking specifically about the problem of the attirtion rate with SharePoint. In short, there isn’t SharePoint without that “other stuff”. Just because it happens elsewhere is beside the point.
This also goes to the point I was trying to make in reason 7. Let me ask you this Richard, if you had the chance to take all of your learnings and then go and perform a week of strategic planning work with 50 practitioners for say, healthcare is delivered in a large rural area, or coming up with a performace framework (KPI/KRA) for a brand new entire city to be built over 25 years, or participating in a non IT project worth several hundred million dollars where the mode of collaborative project delivery has never been tried before? I have had those opportunities and for me that really fires up my passion, because the learning and insight it gives me is utterly invaluable for how I then deliver SharePoint projects. To that end, I was trying to make the point that the better you get at doing what you are doing Richard, the more you can be pulled into projects and problems where those same symptoms occur that you called “stuff”. So it in turn, contributes to the Fatigue Syndrome. The Paul Culmsee’s, Andrew Woodwards, Richard Harbirgdes, Chris Chapmans and Ivan Brebners end up finding more meaningful work in other projects…
Absolutely true.
My hasty reply was meant in the spirit of enthusiasm and for that reason (I felt it accentuated it more effectively) I left out careful logical reasoning/discussion.
I agree with your assessment that attrition could be a major factor in the known skills shortage.
Let’s look at some general statistics for context:
– On indeed if you look up SharePoint you will see a trend of approximately 800% job growth in the last 5 years.
– The number of SharePoint Microsoft partners is now well over 4,000. Back in 2003 days I remember the number being in the hundreds (I believe).
– There are over 1000 SharePoint products or solutions out in the marketplace. According to Microsoft there are over 1000 in development. That means from a high level there is roughly the same amount of products/solutions being developed in the marketplace right now as there has been for the entire life of SharePoint.
Here are some additional factors (that I have also seen through my research):
– There are a growing number of SharePoint Management and Director level positions in both Consultancies and Internally within enterprises who have made significant SharePoint investments. In my opinion this leads to a talent vacuum since highly talented individuals will move into these new roles being created (there is a lot of growth here) and it also means that as leadership roles develop so too does the ‘importance’ and ability to support additional resource requests (think budgets). Meaning more SharePoint entry level, and mid-senior level jobs.
– The asking rate and overall expected salary of a SharePoint resource is very high right now. For many consultancies it is challenging to find a balance between bill rate, utilization and the employee costs. When an experienced (2yr +) SharePoint developer or administrator is looking for a job it’s not unreasonable for them to demand $100 an hour, or $100,000.00 a year. This increases the risk of hiring SharePoint staff and also increases the attrition rate of employees due to the competitive nature of the employment landscape.
– Many of the people designing, defining, and budgeting for SharePoint initiatives, projects, and implementations do not have SharePoint experience (see initial point I made here around director level jobs) this means that they may state they need 3 SharePoint developers for 6 months, but the reality might be that if the work was properly broken down and planned out by an experienced SharePoint architect it might only need one SharePoint developer, one web services/.NET developer and one SAP developer (if it’s say an integration project).
If you think about the things I outlined briefly here I think they could account for most of the talent shortage. While I could see fatigue being an issue for senior resources (exasperating my initial point around director level staff) I still have trouble figuring out how much of a statistical impact it would have. Will definitely think about it more.
P.S – I have quite a bit more on this topic – but that will be in my chapter in my upcoming book currently titled: “Growing SharePoint Capacity & Meeting Staffing Resource Needs”. I am not sure how much I am allowed to share once I agree to the publisher.
P.P.S – I finally see you at Share in a month and a bit! Super excited! Try and convince K to come! 😛
Hi Richard
First up congratulations on your book project. I have a challenge for you. Think about the resourcing question from the point of view of my 7 factors. Now that would be a great chapter!
regards
Paul
Kailash is coming and keen to meet you guys
Best article I’ve read since 2007.
A beacon in an ocean of MVP brown-nosers.
I think that’s a very eloquent summary of the issues. SharePoint solutions frequently combine infrastructure, applications, user experience, information management and a whole host of other facets of IT. Consultants are frequently tagged with unhelpful and ignorant labels such as “SharePoint Expert” or “SharePoint Guru” – which sets impossible expectations before you’ve even begun! I also struggle with having to “rescue” projects with poor contracts created by those who didn’t understand the peculiarities of SharePoint.
In time, I suspect that SharePoint infrastructures will exist as “utility” and project focus will shift to implementation of a SharePoint service into a business – rather than full architectural design. There will be a reduced need for consultants’ expertise to span the full technical gamut of SharePoint solutions. This will be helpful.
I recently took your SP Governance and IA class with 21 Apps, and the material in there about wicked problems combined with this blog post and the second video really make me think back to theory of computer science classes and the difference between deterministic and non-deterministic problems. The theory has been around for quite some time, but it feels like the work you are doing is finding practical approaches to identifying and dealing with business problems that fall into that non-deterministic space.
Keep up the good work, really enjoyed the course and your blog.
Hi Phil
Your comment on “poor contracts” is so true. We devoted a chapter to that in the book which, by the way, is entitled “The Heretic’s Guide to Best Practices” and should be out soon… You are also a psychic mate. I have been doing a lot of cloud based SharePoint lately, both via O365 and Amazon, and completely agree with this point: “In time, I suspect that SharePoint infrastructures will exist as “utility” and project focus will shift to implementation of a SharePoint service into a business – rather than full architectural design. There will be a reduced need for consultants’ expertise to span the full technical gamut of SharePoint solutions. This will be helpful.”
In fact that was my next planned bunch of blog posts…
Joe, thanks for the positive feedback from the class! Glad you enjoyed it and I will be back in London to run a dedicated Issue Mapping class in March 2012 if that is of interest…
regards
Paul
The % of SharePoint development projects getting into escalation mode (running in RED) seems to be higher compared to vanilla ASP.Net or Java world. This is due to structures, SDLC, Complexity, Pace of Change, Entropy and Fatigue that you mentioned in your post.
While there is no sinlge long term solution, in the short term, Organizations need to ensure that SharePoint Recruitment is greater than SharePoint Attrition (Input > Output). We add to SharePoint pool of resources by training ASP.Net Developers on SharePoint. Loose some, but add even more practitioners back to the community.
Amen and thank you for this honest and accurate assessment of working/living the SharePoint world. So many things stand out as completely accurate. If you’re writing a book on the topic of SharePoint Fatigue count me as sold. Great, great, great article. I can’t agree enough. Is Microsoft listening????
Brilliant and concise.
The “bait and switch” situation you refer to is what I recognize as key to the build/collapse/give up cycle resulting in burnout.
Big shiny product demo > promise the moon > dollars get spent > reality sets in > no one can agree > IT gets blamed > SharePoint sucks.
You do not install and configure it. It takes long-term care and feeding which requires ongoing decision-making and commitment from a cross-section of business stakeholders who probably never sit in the same room for more than a few hours a year if they can help it. The results you describe are exactly the outcome I would expect for such a situation.
Everyone knows that if it seems too good to be true it probably is. So why do so many people keep expecting SharePoint to be that touted “silver bullet?”
Year 2016! SP 2016 is out on the way, SP went to Cloud! What happened?? Problems same, after millions of mishaps in SharePoint projects, no learning curve, neither for consultancies, nor by clients, nor by Microsoft! But why Microsoft should worry at all with our problems as product team? They have done quite well, by overselling the product.
I have same burn out symptoms and now, I am done, really I am this time. I have had periods I sat down at home a few months, trying to think what to do next.. and never properly considered for other jobs, except SharePoint ones… Once more, when I have to make a living, I end up going back.