As I mentioned in my last post, I always security trim SharePoint. A very common issue with a security trimmed SharePoint is the "access denied" message that you receive when trying to activate the "Office SharePoint Server Publishing Infrastructure" site collection feature.

There are lots of blog topics about this. Most refer to this one as the definitive source.

Activating Office SharePoint Server Publishing Infrastructure

The issue here is that the publishing feature actually breaks a security rule. When you think about it, activating a site collection feature should only ever modify settings related to that site collection. I previously blogged about how it was bad practice for a site collection feature to modify the web.config files for a given web application.

If you set the scope of this feature at the site collection level, you are basically allowing a site collection administrator to make a change that affects all other site collections in the web application. Uh – does the site collection administrator have access to other site collections? Probably not, so why the hell would you allow them to perform a task that impacts on site collections to which they have no access? You don’t – it breaks the security model.

Well, as it happens, the publishing feature needs to create some SharePoint timer jobs to deal with the scheduling of publishing pages (i.e. Setting the date/time of when a page should be published to the masses). But where are timer jobs edited and managed?

Site Collection Administration! This is a *farm* level operation. Should a site collection administrator have the access rights to add custom timer jobs to the SharePoint farm? Hell, no! that is a farm administrator’s job!

So, is it no surprise then, that the publishing feature barfs when activated by a site collection administrator who has no *farm* level access? (I’ve pasted the error message to the end of this article).

I could whine about how this *should* be done, but instead, I’ll simply tell you the two quickest tricks to fix this issue. Both of these methods do not require changing permissions as per the aforementioned blog.

The first method, is to use STSADM to activate the feature for the site collection. By definition, to use the STSADM command, you have to be logged into the SharePoint server and be a farm administrator. Therefore, running the following command should do the trick.

stsadm -o activatefeature -name PublishingSite -url http://sitecollectionurl

The second method is the one that I use (although it’s less clean). As per normal, I create a web application, and then create a site collection. (Usually the blank template for reasons that I will talk about some other time). But rather than log into the site and activate the publishing feature via site settings, I immediately create a *second*  site collection (e.g /sites/boo).

Remember that I am performing this task via SharePoint central administration, so I have farm level permissions.

When I create this second site collection, I choose the publishing site template. As the name suggests, the publishing site template uses the publishing site feature by default. So in creating this site collection, the SharePoint timer jobs get added to the farm.

I then immediately *delete* this site collection, as it is no longer needed.

Now I can load the originally created site collection and activate the publishing feature. It will work fine, because the timer jobs have already been created, and all of the other goodies that the publishing feature gives you, are scoped at the *site collection* level. Therefore, no more "access denied" messages.

Regards

Paul Culmsee

www.cleverworkarounds.com

Error message: (stop reading now – this is for google 🙂

"Feature Activation: Threw an exception, attempting to roll back.  Feature ‘PublishingResources’ (ID: ‘aebc918d-b20f-4a11-a1db-9ed84d79c87e’).  Exception: Microsoft.SharePoint.SPException: Provisioning did not succeed. Details: Failed to provision the scheduling job definitions.  Page scheduling will not succeed. OriginalException: Access denied. —> System.Security.SecurityException: Access denied.     at Microsoft.SharePoint.Administration.SPPersistedObject.Update()     at Microsoft.SharePoint.Administration.SPJobDefinition.Update()     at Microsoft.SharePoint.Administration.SPWorkItemJobDefinition.Update()     at Microsoft.SharePoint.Publishing.Internal.RootProvisioner.<>c__DisplayClass5.<AddSchedulingJobDefinitions>b__4()     at Microsoft.SharePoint.SPSecurity.CodeToRunElevatedWrapper

I guess the entire SharePoint world now is aware of the post SP1 "Infrastructure updates" put out by Microsoft recently. Probably the best thing about them are that the flaky "content deployment" feature has had some serious work done on it. (My advice has always been use with extreme caution or avoid it, but now I will have to reassess).

Anyway, that is not what I am writing about. Being a former IT Security consultant, I have always installed SharePoint in a "least privilege" configuration. I use different service accounts for search, farm, SSP, reporting services and web applications. The farm account in particular, is one that needs to be very carefully managed given its control over the heart of SharePoint – the configuration database.

Specifically, the farm account never should have any significant rights on any SharePoint farm server, over and above what it minimally needs (which is some SQL Server rights and some DCOM permission stuff). For what it’s worth, I do not use the Network Service account either, as it is actually more risky than a low privileged domain or local user account.

Developers on the other hand tend to run their boxes as full admin. I have no problem with this, so long as there is a QA or test server that is running least privilege.

However, as always with tightening the screws, there are some potential side effects in doing this. There are occasions when the farm account actually needs to perform a task that requires higher privileges, over and above what it has by default. Upgrading SharePoint from a standard to enterprise license is one such example, and it seems that performing the infrastructure update may be another.

If you take the time to read the installation instructions for the infrastructure update, there is this gem of advice:

To ensure that you have the correct permissions to install the software update and run the SharePoint Products and Technologies Configuration Wizard, we recommend that you add the account for the SharePoint Central Administration v3 application pool identity to the Administrators group on each of the local Web servers and application servers and then log on by using that account

You may wonder why this even matters? After all, it is exceedingly likely that you logged into the server as an administrator or domain administrator anyway. Surely you have all the permission that you need, right?

The answer is that not all update tasks are run by your logged-in account. Although you start the installation using your account, at a certain point during the install, many tasks are performed by the SharePoint Central Administration application. Thus, despite you having administrative permissions, SharePoint (using the farm account) will not have.

So the advice above essentially says, temporarily add the SharePoint farm account to the local administrators group and then log into the server as that user account. Now perform the action as instructed. That way the account that starts the installation is the same account that runs SharePoint and thus we know that we are using the correct account with the correct server privileges.

Once the installation has been completed, you can log out of the farm account and then revoke its administrator access, and we are back to the original locked down configuration.

So keep this in mind when performing farm tasks that are likely to require some privileges at the operating system level. It is a good habit to get into (provided you remember to lock down permissions afterwards 🙂 ).

Cheers

Paul

Hi all

My poor-old cleverworkarounds blog has been sadly neglected lately (and my numbers are reflecting that too dammit). But I have actually been doing a while lot of writing for other SharePoint online publications, namely EndUserSharePoint and SharePoint Magazine.

The feedback from both has been great and much appreciated. If you haven’t read these articles, then here is your quick reference.

Series 1: Rethinking SharePoint

This is a 4 part series that was a serious attempt to delve into SharePoint headspace. I focused very much on the human/social side of SharePoint projects. I was pretty pleased with how it came out and look forward to the final part being published soon.

• Thinking SharePoint – and listen to your mother!
• Thinking SharePoint Part 2 – The “unconsciously competent” Ikea Mecca
• Thinking SharePoint Part 3 – A Tale of Two Clients
• Thinking SharePoint Part 4 – Zen and the art of SharePoint

Series 2: A tribute to the leave form

This series is an offbeat look at the world of InfoPath Forms Services and SharePoint Designer workflow. Although I am having a bit of fun with this, there is a serious message behind it. While forms services looks terrific in demos, sometimes looks can be deceiving! The trick with this series is that they are also written to cater for a large audience, and that will be quite a challenge when we get into web services and code behind in InfoPath.

I’ve written 4 articles so far and I’d say there could easily be a dozen by the time I am done. The feedback has been really good, so here’s hoping I can deliver the rest!

• A tribute to the humble “leave form” – Part 1
• A tribute to the humble “leave form” – Part 2 *not yet released*
• A tribute to the humble “leave form” – Part 3 *not yet released*
• A tribute to the humble “leave form” – Part 4 *not yet released*
• .
• .
• A tribute to the humble “leave form” – Part n *not yet written* 🙂

I have a large list of topics to also get well and truly stuck into, so hopefully I’ll have some quality stuff for you fairly soon.

Stay tuned

Paul Culmsee

It is the typical scenario isn’t it. Site works fine for a week and then is officially launched on a Monday morning and the site breaks after an hour complaining that it cannot connect to the configuration database. Whoa?

The SQL Server was checked and confirmed to be running fine, and in checking the SharePoint web front end server I I noticed was MSSEARCH.EXE was chewing memory at a rapid rate of knots. Checking the event logs showed up a steady sequence of event ID 7888, 10036 and 3355 messages. Later I noticed that the search crawl was stuck on "Crawling".

If you search on this topic, many people recommend recreating your Shared Service Provider. In this case, this is unnecessary (not to mention drastic).

It turned out to be an unfortunate combination of factors.

• The client was using SQL Server 2005 with SP1
• The client had a SQL Server maintenance plan with a "rebuild index" task.

Non SQL reader? Maintenance plans are a "good thing". Think of it as a fitness regime for your SQL Server. You can regularly perform integrity checks, tasks to optimise performance, run backups and the like. A screenshot of a basic SQL2005 maintenance plan is to the right.

As it turns out, my client ran a maintenance plan each Sunday (hence why this broke on the Monday of go-live). It also turns out that the "rebuild index" maintenance plan task in SQL Server prior to SP2 has a teeny weenie problem. (By "rebuilding" an index, we mean that it is in effect, deleting and recreating it again).

When rebuilt, various options set on the indexes are not recreated the same way as they were originally created. As you may have guessed, this is extremely uncool, since SharePoint set various indexes in a certain way, it expects things to remain consistent.

There is a KB that you can read all about it here.

http://support.microsoft.com/kb/930887/en-us

Also, another great blog post about the issue is here:

http://blogs.vertigo.com/personal/michael/Blog/Lists/Posts/Post.aspx?ID=4

Some of effects of this dodgily recreated index are listed in the KB article, including:

1. In Shared Services, the "indexing status" remains stuck in the "Crawling" state
2. The number of handles that are opened by the MSSearch.exe process increases
3. The number of TCP connections to the computer that is running SQL Server increases
4. Several error are recorded in the SharePoint logfiles.

• "SqlCrawl::ExecuteCommand fails Error 0x80040e2f"
• CGathererQueueManager::FlushQueue failed with recoverable error 0x80040e2f
• CGathererFilterSink::CommitLinks : pGatherAddLink->AddLinkComplete error=0x80040e2f

Additionally, in my case, MSSEARCH.EXE leaked memory very rapidly when viewed in Task Manager and I received the event logs as shown at the end of this post.

To resolve it, follow the instructions at Michael’s blog as the KB article is poorly written, but make sure that you do it for all tables as listed in the KB article! Michael’s post only covers 2 indexes and there actually are more in the search database as shown below.

• Event Type:      Error
• Event Source:   Office SharePoint Server
• Event Category:            Office Server General
• Event ID:          7888
• Date:                1/07/2008
• Time:                12:03:03 PM
• User:                N/A
• Computer:         MyServer

Description:

Message: A connection was successfully established with the server, but then an error occurred during the pre-login handshake.  When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 0 – No process is on the other end of the pipe.)

• Event Type:      Error
• Event Source:   Office Server Search
• Event Category:            Gatherer
• Event ID:          10036
• Date:                1/07/2008
• Time:                12:03:38 PM
• User:                N/A
• Computer:         MyServer

Description:

A database error occurred.

Source: Microsoft OLE DB Provider for SQL Server

Code: 17 occurred 1 time(s)

Description: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.

• Event Type:      Error
• Event Source:   Windows SharePoint Services 3
• Event Category:            Database
• Event ID:          3355
• Date:                1/07/2008
• Time:                12:04:08 PM
• User:                N/A
• Computer:         MyServer

Description:

Cannot connect to SQL Server. MyServer not found. Additional error information from SQL Server is included below.

[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.

• Event Type:      Error
• Event Source:   Office SharePoint Server
• Event Category:            Office Server Shared Services
• Event ID:          6482
• Date:                1/07/2008
• Time:                12:05:12 PM
• User:                N/A
• Computer:         MyServer

Description:

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (009e9001-5c8f-4705-9b4d-ee514c442fc7).

Reason: Exception from HRESULT: 0x80040D1B

Techinal Support Details:

System.Runtime.InteropServices.COMException (0x80040D1B): Exception from HRESULT: 0x80040D1B

   at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.SynchronizeDefaultContentSource(IDictionary applications)

   at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()

   at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

07/01/2008 12:25:01.85 mssearch.exe (0x0E20)                          0x0E38 Search Server Common             GathererSql                               0          Monitorable       CSqlCrawl::ExecuteCommand fails Error 0x80040e2f – File:d:\office\source\search\search\gather\server\gathersql.cxx Line:407 

This post from the eLumenotion blog is clever and really tickled my sense of humour.

He describes a declassified wartime era document called the "Simple Sabotage Field Manual" and the content is pure gold 🙂

"It gives advice on how to deliberately screw things up but can also be read as an anti-pattern of behaviors to avoid yourself and to watch for in those you manage or collaborate with. The evil genius of this guide is that all of the techniques it advises are destructive behaviors that normal people exhibit on a daily basis. So, if you were to do these things in a theater of war you could hurt the enemy while maintaining plausible deniability and avoid a firing squad."

Sections include

• Sabotage Under the Guise of Process
• Sabotage Via Project Management
• Sabotage Your Team Via Poor Work

I soooo wish that I had seen this when I was writing the "SharePoint Project Failure" series as I actually touched on some of these areas.

Do yourself a favour and check the post.

My next post on "Thinking SharePoint" for www.endusersharepoint.com reproduced here.

Hi again. Sorry about the delay in continuing with this "how to think SharePoint" series, but in Australia, the month of June is the end of the financial year. I assume it works the same way in the rest of the world too. What happens here is that IT Managers suddenly realise that they have some budget funds left over and therefore feel an irrepressible urge to spend it all. (They tend to be fearful that they will get less money allocated for the next year if they don’t spend all that is allocated to them this year).

Usually what they spend surplus budget cash on depends on whatever product or technology is at the peak of the hype cycle for that year. Therefore instead of something morale boosting like paying their hardworking staff a bonus or purchasing training vouchers for them, this year a lot of IT managers will wander around showing off their shiny new Apple iPhone and a lot of SharePoint consultants like me are very busy indeed.

And this is relevant, why?

Okay so yes, I am busy and haven’t had much time to devote to writing. But the real reason that I bring this end of financial year stuff up, is to point out that if you took anything away from the first post, you would appreciate that I find it a warning sign. Despite best intentions, buying SharePoint because you have some budget left is not necessarily the best place to focus surplus funds. You are in effect perpetuating the whole issue of the "solution looking for a problem".

In this world of organisational politics, no manager or sponsor is going to purchase SharePoint without something with "wow factor" to show for it. So on top of a fixed deadline, it has to look great and solve a few pertinent business needs, so that the organisation endorses and evangelises it, right?

My SharePoint spider senses are tingling already…

The plight of the "Ikea guy"

In the last post I implied that the prevalent world of folders (or directories) originated from two stoned Multix programmers in the 1960’s. I also likened folders to a wooden toybox and compared it to SharePoint as an uber-cool Ikea style modular storage solution. Of course, it all looked absolutely fantastic when you saw it in the display room in the suburban mecca that is an Ikea store.

So I want you to picture the plight of the "Ikea guy". He’s the guy who arrives at a house with a truck full of Ikea boxes who is going to install it for you. Now I want you to think about your organisation (in all its messed-up glory) and try and picture it as a family living at this house. 

From the Ikea guy’s point of view, the house looks really nice as he walks up to the front door. The garden is neat and trimmed and the lounge room is clean and tidy. The family inside seem really polite. However, once pleasantries have been exchanged and he takes a look around the rest of the house, it takes about 10 minutes for the Ikea guy to know that it’s just not going to be a good day.

Why?

• Mum and Dad are in marriage counselling and it’s not going well
• The kids barely speak to each other and don’t respect their parents
• Dad thinks he knows best and that everything should be strictly put away according to colour no matter which room
• Mum doesn’t care how things are put away, so long as they are put away
• One of the kids is a teenage goth/emo, and he wants it all painted black
• One kid is anal retentive and has one of those label makers and likes to put "Property of xxx" on everything
• Another kid is a greenie-stoner and "it all should be like.. whatever you want man…"
• One of the kids is vain and self obsessed, wants more pocket money and wants to individualise everything with stickers all over the place
• One kid is a toddler, needs nappies changed and leaves a mess everywhere he/she goes

Finally…

• The husband never told the family that the Ikea guy was coming anyway and his measurements were out

So after much arguments between themselves, they turn to the Ikea guy and say "You tell us how should we do this?"

At this point the Ikea guy is completely screwed, no matter what he says, he is in trouble. It’s like when your wife or girlfriend asks if she looks fat in that dress. Even a pause before answering is going to be misconstrued in a way where you always lose.

Personalities, personalities…

In a lot of my writings I have fun with stereotypes. I tend to imply that IT managers are luddites or micro-managers, web designers and branding people are all vain metrosexuals and IT nerds have no people skills :-P. Senior managers all have a serious case of attention deficit disorder and the general user population is as varied as the kids I used in the Ikea example. The "human" side of SharePoint fascinates me greatly, as I have seen some people completely besotted with particular product features, such as wikis or blogs, yet have no interest at all in other features.

Not only are there different personalities, there are different leaning types. For people involved with SharePoint projects at any level, I recommend reading up on Myers-Briggs Indicators or the Marsden DISC quadrant model. I’ll blog in detail about these some other time, but the point here is that your version of the truth, if you’re lucky, will be shared by only 20% of your peers. So even if you put a bunch of SharePoint technical experts into a room and asked them to design a collaborative solution, the chances of them creating the same design is actually pretty low.

It’s like music taste. I’m sure that some readers thought to themselves "What’s wrong with the Backstreet Boys?", after reading my first post. Whilst I find that question too ridiculous to even contemplate, I recognise that part of the key to "thinking SharePoint" is recognising that Backstreet Boys fans do actually exist and therefore ensuring that their "special needs" are accommodated :-).

Moral? Chacun à son goût. Each to their own! Just remember that not everyone sees it the way you do and what will excite and interest you will not necessarily do the same for others.

Learning Styles

Another big contributor to effective "SharePoint thinking" is actually rooted in learning style theory. The theory says that when training people, there are different stages of awareness and competence. Personality types affect learning a lot, but here I present a bastardised SharePoint version of learning theory.

Stage 1 – SharePoint ‘unconscious incompetence’

• The person is not aware of the relevance or considerations of the problem that SharePoint is being used to solve
• The person is not aware that they have a particular deficiency in their knowledge of the applicability of SharePoint
• The person might deny the relevance or usefulness of SharePoint
• Conversely, the person might oversell the relevance or usefulness of SharePoint

Training theory states that the person must become conscious of their incompetence before development of the new skill or learning can begin. The aim of the trainer is to guide the person into the ‘conscious competence’ stage. In most problematic SharePoint projects, it is common that participants are at this unconscious incompetence stage and training without recognition of this fact is misfocused and wasteful. While the majority of participants in a SharePoint project are at this stage in their learning, then you are on a dangerous slope to SharePoint project failure if you proceed too fast.

Stage 2 – SharePoint conscious incompetence’

• The person becomes aware of the existence and relevance of the problem that SharePoint is being used to solve
• The person is therefore also aware of their deficiency in SharePoint knowledge and skill, ideally by attempting or trying to use the product
• The person realises that by improving their skill or ability in SharePoint, their effectiveness will improve

Many people will feel that they are at this stage, but in fact they are still in stage 1. (It’s hard to put a quantifiable finger on how I personally determine this, but I think it is something that seasoned SharePoint professionals get a good feel for over time). Essentially any untested assumption on how SharePoint works or how it should be used to solve a problem is within the realm of stage 1!

I find that if I can get clients into Stage 2, then the nature of engagements change. The fixation on delivering the whole enchilada in a fixed time and fixed cost is replaced by dialogue, workshops, strategy sessions and the likes. At this point no scope of what is to be delivered has been fixed in stone as the client realises that they have to invest more in their learning and understanding for an ultimately positive outcome. The client has in effect made a commitment to learn and we proceed steadily to stage 3.

Stage 3 – SharePoint conscious competence

Note, In my opinion this period takes anywhere from two to twelve months, depending on the organisational size, culture, wickedness of the problem to solve, etc.

• The person achieves ‘conscious competence’ in SharePoint when they can use it without feeling fearful or intimidated
• The person will need to concentrate and think in order to understand the technical and organisational governance implications of a new SharePoint solution
• The person will not reliably perform SharePoint work unless thinking about it – the skill is not yet ‘second nature’ or ‘automatic’
• The person should be able to demonstrate SharePoint skills to another, but is unlikely to have the ability to teach it well to another person
• The person should ideally continue to practice their skills, and if appropriate, commit to becoming ‘unconsciously competent’ at the new skill
• Practice is the single most effective way to move from stage 3 to 4

Stage 4 – SharePoint unconscious competence.

Nirvana! Are any of us here yet???

• Applying SharePoint features and capabilities to business problems skill becomes so practiced that estimates of time, effort and cost are accurate and met
• Understanding of technical and organisational governance considerations of potential courses of action are implicitly understood

And then there was the Intranet

One of the reasons that folders have stuck for so many years would have to be its simplicity. For all of its suckiness, it has a somewhat constraining effect. Whilst folders can suck royally, it’s all you have available to use and therefore debates/arguments are not about whether to use folders or not, but how to use them. For most, there really was no alternative.

Then from around the mid nineties, there came the rise of the intranet. As a content delivery mechanism it proved hugely popular and suddenly corporate knowledge was made available via a much more accessible medium. But it was a different kind of content, and there was a significant "disconnect" with the corporate file system. Content authors would put their files onto the file-system and then on the intranet in a different format.

For the sake of article size and keeping it flowing, I am not going to talk too much about portals vs intranet’s because to the average end user, they are one and the same. I know people will beg to differ with me on this but I don’t think the distinction will be that relevant to this article.

Choices, choices, choices…

Even now more than a decade of "intranets" later, many clients who I talk to really struggle with the concept of a "SharePoint style intranet". The disconnection between the traditional intranet and the file-system is fairly ingrained, and in my experience, it is very common to find people initially unable to "connect" with the idea that your file-system, document management system and workflow system can be your intranet and visa versa.

This disconnect needs to be addressed early in the piece. Failure to do so and expectations will be unmet. Differing versions of the truth will abound and then how can participants and stakeholders possibly cope with the veritable smorgasbord of choices offered by SharePoint?

We still have folders of course, but now we have other elements as well, such as document libraries, columns of various types, webparts, versioning, approvals, lists, workflows, sites, site collections, web applications (oh and full text indexing/search too). So rather than debate on how, we now also have to argue on the what as well.

Combine organisational culture factors, SharePoint conscious or unconscious competence levels, the different personality types, life skills and values of participants, each with different buttons to push. Is it any great revelation then that too many choices can be more destructive than none at all?

Sheesh! It’s a wonder we don’t kill each other trying to work this all out!

Conclusion

I suspect that many reading this article would not be too offended if I suggest that they are "SharePoint consciously incompetent". It is actually where you need to start from, and in some ways I am preaching to the converted here. It is the people, not reading this article, who are likely to be in the unconsciously incompetent stage of learning. So, no matter what your role in your organisation is, one of the keys to "thinking SharePoint" as it were, is to move yourselves and your colleagues from stage 1 to stage 2.

In the next post I am going to tell you a tale of two clients, where one made the transition from SharePoint unconscious incompetence to SharePoint conscious incompetence and one who did not. I was the "Ikea guy" in both cases, and I think the stories offer some valuable insights.

Bye for now

Paul

Mentally tired this weekend and a headache too, so no work stuff. I promise to get back to SharePoint topics soon though…

I just read something amazing that really surprised me. Opeth (the progressive metal band that is target of a few of my SharePoint metaphors) has managed to debut at #7 on the Australian music charts with their latest album Watershed. It has garnered some pretty rave reviews and for a band who’s roots originate in some pretty brutal death-metal style stuff. It is a testament to the unique band they have become and their appeal outside your typical headbanger audience.

So I thought in between various other pieces of work I would post a review of their album. If I mention the word "SharePoint", does that make it a legit CleverWorkarounds post? 🙂

Continue reading “Opeth – Watershed review”

Note: Special thanks to Andrew Jolly for his excellent ideas and feedback

I have to say, SharePoint is one of the most misunderstood products that Microsoft have ever released. The misunderstanding extends from executive management who signed the budget approval to put it in, to the geeks who actually put it in for us, and all the way to us end-users who are expected to find nirvana in its magical world of sites, lists, libraries, workflows and the like.

Misunderstanding creates confusion, and confusion leads to bad implementations, expectations unmet, teams deflated and the word “SharePoint” being spoken only in whispers in-case you’re overheard by the many ears of the corporate immune mechanism.

The outcome of this series is to give the reader an appreciation of a more human look at SharePoint. Therefore I will not be exhaustively examining every feature within SharePoint, but instead to take a high level look at some of the key SharePoint concepts and then try and put them into an organisational context. To get the best out of SharePoint requires forethought and soul searching. Despite the obvious temptation, diving straight in can be a little like wearing a Backstreet Boys t-shirt at a Metallica concert – you may live to regret that decision…

.. but you can hardly blame Metallica can you?

Article Pre-requisites

This series has been aimed at a broad cross section of the user base. If your circumstances match any of the following scenarios, then the material may be for you.

• you have had SharePoint pushed at you by an overzealous IT department and you are wondering what the fuss is all about
• you are a member of the overzealous IT department, a true believer and wonder why the masses don’t get it
• you are a senior executive who’s computer literacy extends to the on-button of your laptop but your IT Manager tells you this “SharePoint” thing may be good for the organisation
• your organisation is doing one of those heavily promoted organisational change frameworks with a fancy slogan, t-shirts and mouse-mats. SharePoint is touted as a key component
• you find the myriad of documentation, blogs, and online references to be too intimidating or nerdy for your taste
• SharePoint is deployed, you have been sent on a 2 day feature-fest training course but little real progress has been made since then.

For those not yet convinced

If you do not consider yourself a SharePoint true believer, then good on you! You are probably half way to a successful deployment already. It is not a panacea and it will not bring about world peace. It has massive potential – no doubt about it, but the propensity to fail is higher than you might expect. (For more on that topic see this series I wrote a little while back)

SharePoint has a myriad of features and ways to approach solving common business problems. Whether you are a senior manager, team lead or team member, chances are you can find a way to improve or optimise some aspect of your work using SharePoint. You can find plenty of great articles on endusersharepoint.com to introduce you to the product, solve common problems and learn from others. But at the end of the day, SharePoint is a tool and all tools are supposed to come with a safety manual to prevent misuse and accidental injury.

So to continue the above metaphor, the only way you would get out of the Metallica concert alive with the Backstreet Boys t-shirt would be to shout the bar and buy a lot of beers!

In this series, I hope to teach you which t-shirt to wear at a metal gig, as well as how and when to buy those beers when you get it wrong!

How Microsoft software products are normally delivered

SharePoint represents a change for users as well as IT people. Previously, when say, the latest MSOffice suite was deployed to a company, users had little say. If you were lucky, you would get sent off to some training, and then left to your own devices. But that was cool – its MSOffice. We have all used it, and using a new version isn’t really a major hindrance to producing Word, Excel or PowerPoint documents. Give it a day or two and you are pretty much back in business.

But SharePoint – that’s a whole different story. Not only do you need to be trained in how the product works, you need time to take it all in. You almost certainly need to also change the way you think about certain aspects to your work and you will almost certainly not get it right the first time. Thus, for some of you (likely all who are reading this article) will relish the opportunity to use some of the features to improve your productivity. However, many others will resist it and take a long time to come around.

What makes SharePoint such an interesting product is that the pro and anti crowds will have to accommodate each other if a SharePoint project is to really succeed. That is the tough bit!

40 years of folders

In 1965 an operating system called Multics was developed for mainframe computers. It wasn’t exactly a rampaging success back then. But hey, PC’s hadn’t been invented either and back then, “The Sound of Music” was everyone’s idea of a night out at the movies. Thus it wasn’t exactly dotcom times.

But it was here, where the first “Hierarchical file system” was developed.

“Hierarchical what the…” You exclaim?

You know it as folders, subfolders or directories and for over 40 years, the concept has essentially been unchanged. For most people, folders and subfolders have been your only option for categorising and collaborating on files.

I would have loved to be a fly on the wall when the Multics guys wrote the specification for the hierarchical file system. Since it’s the sixties, I’m sure that’s it happened something like this…

Engineer 1 (smoking a joint of weed) “Dude, imagine if we could like… put a filing cabinet in the computer man…”

Passes joint to Engineer 2 who takes a drag and laughs uncontrollably for ten minutes

Engineer 2: Whoa man, your freaking me out! – let’s order some pizza”

Listen to your mother (and clean up your room already)!

We adults are complete hypocrites. As kids, we were told relentlessly by our mothers to clean our rooms. We tell our children to clean up their rooms too, yet the shared file system in the typical workplace is messier than even the most rebellious teenager’s poster covered, mouldy sock smelling abode.

The corporate file system is like a giant play-area for adults, which has not been cleaned in years. In fact, whenever there is a suggestion to ‘clean up’ the play-area, the adult equivalent of “oh mum do I have to?” is heard down the corridors.

Why is it that people don’t like to put their toys away? As you mother said, “if you leave them lying around they will get broken, and may be accidently thrown out”.

Anybody who has ever worked for an organisation of more than 1 person will know the joy (not!) of trying to find that all important critical file. You know darn well it’s there somewhere, but do you think you can find it? Then you go to the trouble to recreate your work, only to find that someone changed permissions and you no longer see it.

The inefficiencies caused by the messy play area are pretty significant, not only on your individual stress levels, but at a departmental and organisational level too. Often files go missing, or the wrong versions are used. Multiple copies abound, and everyone seems to have an in-built reflex to file and name things slightly differently to everyone else. I’ve seen this cost big money too, an example being hundreds of thousands of dollars lost when a fixed price contract used a cost estimate based on the wrong specification. Ouch!

The Ikea effect

Forget the marketing fluff and the seemingly endless array of features on SharePoint slide decks. For most people SharePoint will be about sites, lists, libraries, forms and workflow. In subsequent articles I will talk about these as these concepts are really important, but if there is one theme I want to leave you with.

These new features are like going from a wooden toybox like this…

…to a fully decked out Ikea playroom like this

It might look pretty, and smell new and fresh at the start. But the moral of the story is this. You might have a fancier storage system with additional bells and whistles, but you still need to put your toys away and agree with everyone else where things should go! Furthermore, The IKEA guy who installs it all for you might make some suggestions, but at the end of the day, he isn’t going to be able to definitively tell you where things go and you wouldn’t listen to him anyhow as they are your toys.

So in the next post I’ll dig a little deeper into putting our toys away properly.

Thanks for reading

Paul Culmsee

I just posted a new article to the EndUserSharePoint.com as a guest author. There will be a few of us doing this over the next few weeks, and it will be interesting to see how it pans out. The article is a more end-user focused version of the topic areas that I am interested in – the human side of collaboration. I’ll re-post it here too in a couple of days, but for now, you can read my article here.

The article is called "Thinking SharePoint (and listen to your mother)"

In the ongoing quest to find the perfect metaphor, it features Metallica, the Backstreet Boys, two stoned software engineers and Ikea.

later

Paul

Hi

Well, here we are at part 8 in a series of posts dedicated to the topic of SharePoint project failure. Surely after 7 posts, you would think that we are exhausting the various factors that can have a negative influence on time, budget and SharePoint deliverables? Alas no! My urge to peel back this onion continues unabated and thus I present one final post in this series.

Now if I had my time again, I would definitely re-order these posts, because this topic area is back in the realm of project management. But not to worry. I’ll probably do a ‘reloaded’ version of this series at some point in the future or make an ebook that is more detailed and more coherently written, along with contributions from friends.

In the remote chance that you are hitting this article first up, it is actually the last of a long series written over the last couple of months (well, last for now anyway). We started this series with an examination of the pioneering work by Horst Rittell in the 1970’s and subsequently examined some of the notable historical references to wicked problems in IT. From there, we turned our attention to SharePoint specifically and why it, as a product, can be a wicked problem. We looked at the product from viewpoints, specifically, project managers, IT infrastructure architects and application developers.

In the last article, we once again drifted away from SharePoint directly and looked at senior management and project sponsors contribution. Almost by definition, when looking at the senior management level, it makes no sense to be product specific, since at this level it is always about business strategy.

In this post, I’d like to examine when best practice frameworks, the intent of which is to reduce risk of project failure, actually have the opposite effect. We will look at why this is the case in some detail.

CleverWorkarounds tequila shot rating..

    For readers with a passing interest in best practice frameworks and project management.

For nerds who swear they will never leave the "tech stuff."

Continue reading “Why do SharePoint Projects Fail? – Part 8”