Hi again

This article is the second half of a pair of articles explaining how I integrated real-time performance data with an SharePoint based IT operational portal, designed around the principle of passive compliance with legislative or organisational controls.

In the first post, I introduced the PI product by OSIsoft, and explained how SQL Reporting services is able to generate reports from more than just SQL Server databases. I demonstrated how I created a report server report from performance data stored in the PI historian via an OLE DB provider for PI, and I also demonstrated how I was able to create a report that accepted a parameter, so that the output of the report could be customised.

I also showed how a SharePoint provides a facility to enter parameter data when using the report viewer web part.

We will now conclude this article by explaining a little about my passively compliant IT portal, and how I was able to enhance it with seamless integration with the real-time performance data stored in the PI historian.

Just to remind you, here is my conceptual diagram in "acoustic Visio" format

The IT portal

This is the really ultra brief explanation of the thinking that went into my IT portal

I spent a lot of time thinking about how critical IT information could be stored in SharePoint to achieve the goals of quick and easy access to information, make tasks like change/configuration management more transparent and efficient, as well as capture knowledge and documentation. I was influenced considerably by ISO17799 as it was called back then, especially in the area of asset management. I liked the use of the term "IT Assets" in ISO17799 and the strong emphasis on ownership and custodianship.

ISO defined asset as "any tangible or intangible thing that has value to an organization". It maintained that "…to achieve and maintain appropriate protection of organizational assets. All assets should be accounted for and have a nominated owner. Owners should be identified for all assets and the responsibility for the maintenance of appropriate controls should be assigned. The implementation of specific controls may be delegated by the owner as appropriate but the owner remains responsible for the proper protection of the assets."

That idea of delegation is that an owner of an asset can delegate the day-to-day management of that asset to a custodian, but the owner still bears ultimate responsibility.

So I developed a portal around this idea, but soon was hit by some constraints due to the broad ISO definition of an asset. Since assets have interdependencies, geeks have a tendency to over-complicate things and product a messy web of interdependencies. After some trial and error, as well as some soul searching I was able to come up with a 3 tier model that worked.

I changed the use of the word "asset", and split it into three broad asset types. Devices (eg Server, SAN, Switch, Router, etc) IT Services (eg Messaging, Databases, IP Network, etc) Information Assets (eg Intranet, Timesheets,

The main thing to note about this model is to explain the different between an IT Service and an Information Asset. The distinction is in the area of ownership. In the case of an "Information Asset", the ownership of that asset is not IT. IT are a service provider, and by definition the IT view of the world is different to the rest of the organisation. An "IT Service" on the other hand, is always owned by IT and it is the IT services that underpin information assets.

So there is a hierarchical relationship there. You can’t have an information asset without an IT service providing it. Accountabilities are clear also. IT own the service, but are not responsible for the information asset itself - that’s for other areas of the organisation. (an Information Asset can also depend on other information assets as well as many IT services.

While this may sound so obvious that its not worth writing, my experience is that IT department often view information assets and the services providing those assets as one and the same thing.

Devices and Services

So, as an IT department, we provide a variety of services to the organisation. We provide them with an IP network, potentially a voice over IP system, a database subsystem, a backup and recovery service, etc.

It is fairly obvious that each IT service consists of a combination of IT devices (and often other IT services). an IP network is an obvious one and a basic example. The devices that underpin the "IP Network" service are routers, switches and wireless access points.

For devices we need to store information like

• Serial Number
• Warranty Details
• Physical Location
• Vendor information
• Passwords
• Device Type
• IP Address
• Change/Configuration Management history
• IT Services that depend on this device (there is usually more than 1)

For services, we need to store information like

• Service Owner
• Service Custodian
• Service Level Agreement (uptime guarantees, etc)
• Change/Configuration Management history
• IT Devices that underpin this service (there is usually more than 1)
• Dependency relationships with other IT services
• Information Assets that depend on this IT service

Keen eyed ITIL practitioners will realise that all I am describing here is a SharePoint based CMDB. I have a site template, content types, lists, event handlers and workflows that allow the above information to be managed in SharePoint. Below is three snippets showing sections of the portal, drilling down into the device view by location (click to expand), before showing the actual information about the server "DM01"

Now the above screen is the one that I am interested in. You may also notice that the page above is a system generated page, based on the list called "IT Devices". I want to add real-time performance data to this screen, so that as well as being able to see asset information about a device, I also want to see its recent performance.

Modifying a system page

I talked about making modifications to system pages in detail in part 3 of my branding using Javascript series. Essentially, a system page is an automatically generated ASPX page that SharePoint creates. Think about what happens each time you add a column to a list or library. The NewForm.aspx, Editform.Aspx and Dispform.aspx are modified as they have to be rebuild to display the new or modified column.

SharePoint makes it a little tricky to edit these pages on account of custom modifications running the risk of breaking things. But as I described in the branding series, using the ToolPaneView hack does the job for us in a safe manner.

So using this hack, I was able to add a report viewer web part to the Dispform.aspx of the "IT devices" list as shown below.

Finally, we have our report viewer webpart, linked to our report that accesses PI historian data. As you can see below, the report that I created actually is expecting two parameters to be supplied. These parameters will be used to retrieve specific performance data and turn it into a chart.

Web Part Connection Magic

Now as it stands, the report is pretty much useless to us in the sense that we have to enter parameters to it manually, to get it to actually present us the information that we want. But on the same page as this report is a bunch of interesting information about a particular device, such as its name, IP Address, location and description. Wouldn’t it be great if we could somehow pass the device name (or some other device information) to the report web part automatically.

That way, each time you opened up a device entry, the report would retrieve performance information for the device currently being viewed. That would be very, very cool.

Fortunately for us it can be easily done. The report services web part, like many other web parts is connectable. This means that it can accept information from other web parts. This means that it is possible to have the parameters automatically passed to the report! 

Wohoo!

So here is how I am going to do this. I am going to add two new columns to my device list. Each column will be the parameter passed to the report. This way, I can tailor the report being generated on a device by device basis. For example, for a SAN device I might want to report on disk I/O, but a server I might want CPU. If I store the parameter as a column, the report will be able to retrieve whatever performance data I need.

Below shows the device list with the additional two columns added. the columns are called TAGPARAM1 and TAGPARAM2. The next screen below, shows the values I have entered for each column against the device DM01. These values will be passed to the report server report and used to find matching performance data.

So the next question becomes, how do I now transparently pass these two parameters to the report? We now have the report and the parameters on the same page, but no obvious means to pass the value of TagParam1 and TagParam2 to the report viewer web part.

The answer my friends, is to use a filter web part!

Using the toolpane view hack, we once again edit the view item page for the Device List. We now need to add two additional web parts (because we have two parameters). Below is the web part to add.

The result should be a screen looking like the figure below

Filter web parts are not visible when a page is rendered in the browser. They are instead used to pass data between other web parts. There are various filter web parts that work in different ways. The Page Field filter is capable of passing the value of any column to another web part.

Confused? Check out how I use this web part below…

The screen above shows that the two Page Field filters web parts are not configured. They are prompting you to open the tool pane and configure them. Below is the configuration pane for the page field filter. Can you see how it has enumerated all of the columns for the "IT device" list? In the second and third screen we have chosen TagParam1 for the first page filter and TagParam2 for the second page filter web part.

Now take a look at the page in edit mode. The page filters now change display to say that they are not connected. All we have done so far is tell the web parts which columns to grab the parameter values from

Almost Home - Connecting the filters

So now we need to connect each Page Field filter web part to the report viewer web part. This will have the effect of passing to the report viewer web part, the value of TagParam1 and TagParam2. Since these values change from device to device, the report will display unique data for each device.

To to connect each page filter web part you click the edit dropdown for each page filter. From the list of choices, choose "Connections", and it will expand out to the choice of "Send Filter Values To". If you click on this, you will be promoted to send the filter values to the report viewer web part on the page. Since in my example, the report viewer web part requires two parameters, you will be asked to choose which of the two parameters to send the value to.

Repeat this step for both page filter web parts and something amazing happens, we see a performance report on the devices page!! The filter has passed the values of TagParam1 and tagParam2 to the report and it has retrieved the matching data!

Let’s now save this page and view it in all of its glory! Sweet eh!

 

Conclusion (and Touchups)

So let’s step back and look at what we have achieved. We can visit our IT Operations portal, open the devices list and immediately view real-time performance statistics for that device. Since I am using a PI historian, the performance data could have been collected via SNMP, netflow, ping, WMI, Performance Monitor counters, a script or many, many methods. But we do not need to worry about that, we just ask PI for the data that we want and display it using reporting services.

Because the parameters are stored as additional metadata with each device, you have complete control over the data being presented back to SharePoint. You might decide that servers should always return CPU stats, but a storage area network return disk I/O stats. It is all controllable just by the values you enter into the columns being used as report parameters.

The only additional thing that I did was to use my CleverWorkArounds Hide Field Web Part, to subsequently hide the TagParam1 and TagParam2 fields from display, so that when IT staff are looking at the integrated asset and performance data, the ‘behind the scenes’ glue is hidden from them.

So looking at this from a IT portal/compliance point of view, we now have an integrated platform where we can:

• View device asset information (serial number, purchase date, warranty, physical location)
• View IT Service information (owners, custodians and SLA’s)
• View Information Asset information (owners, custodians and SLA’s)
• Understand the relationships between devices, services and information assets
• Access standards, procedures and work instructions pertaining to devices, services and information assets
• Manage change and configuration management for devices, services and information assets
• Quickly and easily view detailed, real time performance statistics of devices

All in all, not a bad afternoons work really! And not one line of code!

As i said way back at the start of the first article, this started out as a quick idea for a demo and it seems to have a heck of a lot of potential. Of course, I used PI but there is no reason why you can’t use similar techniques in your own IT portals to integrate your operational and performance data into the one place.

I hope that you enjoyed this article and I look forward to feedback.

<Blatant Plug>Want an IT Portal built in passive compliance? Then let’s talk!</Blatant Plug>

cheers

Paul Culmsee

 

 

 

 

OSISoft addendum

Now someone at OSISoft at some point will read this article and wonder why I didn’t write about RTWebparts. Essentially PI has some web parts that can be used to display historian data in SharePoint. There were two reasons why I did not mention them.

1. To use RTWebparts you have to install a lot of PI components onto your web front end servers. Nothing wrong with that, but with Report Services, those components only need to go onto the report server. For my circumstances and what I had to demonstrate, this was sufficient.
2. This post was actually not about OSISoft or PI per se. It was used to demonstrate how it is possible to use SharePoint to integrate performance and operational information into one integrated location. In the event that you have PI in your enterprise and want to leverage it with SharePoint, I suggest you contact me about it because we do happen to be very good at it

 

No Tags

Hi

This is one of those nerdy posts in the category of "look at me! look at me! look at what I did, isn’t it cool?". Normally application developers write posts like this, demonstrating some cool bit of code they are really proud of. Being only a part-time developer and more of a security/governance/compliance kind of guy, my "aint it cool" post is a little different.

So if you are a non developer and you are already tempted to skip this one, please reconsider. If you are a CIO, IT manager, Infrastructure manager or are simply into ITIL, COBiT or compliance around IT operations in general, this post may have something for you. It offers something for knowledge managers too. Additionally it gives you a teensy tiny glimpse into my own personal manifesto of how you can integrate different types of data to achieve the sort of IT operational excellence that is a step above where you may be now.

Additionally, if you are a Cisco nerd or an infrastructure person who has experience with monitoring, you will also find something potentially useful here.

In this post, I am going to show you how I leveraged three key technologies, along with a dash of best practice methodology to create an IT Portal that I think is cool.

The Premise - "Passive Compliance"

In my career I have filled various IT roles and drunk the kool-aid of most of the vendors, technologies, methodologies and practices. Nowadays I am a product of all of these influences, leaving me slightly bitter and twisted, somewhat of a security nerd, but at the same time fairly pragmatic and always mindful of working to business goals and strategy.

One or the major influences to my current view of the world, was a role working for OSI Software from 2000-2004, via a former subsidiary company called WiredCity. OSISoft develop products in the process control space, and their core product is a data historian called PI. At WiredCity, we took this product out of the process control market and right into the IT enterprise and OSISoft now market this product as "IT Monitor". I’ll talk about PI/IT monitor in detail in a moment, but humour me and just accept my word that it is a hellishly fast number crunching database for storing lots of juicy performance data.

An addition I like to read all the various best practice frameworks and methodologies and I write about them a fair bit. As a result of this interest, I have a SharePoint IT portal template that I have developed over the last couple of years, designed around the guiding principle of passive compliance. That is, by utilising the portal for IT various operational tasks, structured in a certain way, you implicitly address some COBiT/ISO27001 controls as well as leverage ITIL principles. I designed it in such a way that an auditor could take a look at it and it would demonstrate the assurance around IT controls for operational system support. It also had the added benefit of being a powerful addition to disaster recovery strategy. (In the second article, to be published soon, I will describe my IT portal in more detail).

Finally, I have SQL Reporting Services integrated with SharePoint, used to present enterprise data from various databases into the IT Portal - also as part of the principle of passive compliance via business intelligence.

Recently, I was called in to help conduct a demonstration of the aforementioned PI software, so I decided to add PI functionality to my existing "passive compliance" IT portal to integrate asset and control data (like change/configuration management) along with real-time performance data. All in all I was very pleased with the outcome as it was done in a day with pretty impressive effect. I was able to do this with minimal coding, utilising various features of all three of the above applications with a few other components and pretty much wrote no code at all.

Below I have built a conceptual diagram of the solution. Unfortunately I don’t have Visio installed, but I found a great freeware alternative

I know, there is a lot to take in here (click to enlarge), but if you look in the center of the diagram, you will see a mock up of a SharePoint display. All of the other components drawn around it combine to produce that display. I’ll now talk about the main combination, PI and SQL Reporting Services.

A slice of PI

Okay so let’s explain PI because I think most people have a handle on SharePoint :-).

To the right is the terminator looking at data from a PI historian showing power flow in California. So this product is not a lightweight at all. It’s heritage lies in this sort of critical industrial monitoring.

Just to get the disclaimers out of the way, I do not work for OSISoft anymore nor are they even aware of this post. Just so hard-core geeks don’t flame me and call me a weenie, let me just say that I love RRDTool and SmokePing and prefer Zabbix over Nagios. Does that make me cool enough to make comment on this topic now?   

Like RRDTool, PI is a data historian, designed and optimised for time-series data.

"Data historian? Is that like a database of some kind?", you may ask. The answer is yes, but its not a relational database like SQL Server or Oracle. Instead, it is a "real-time, time series" data store. The English translation of that definition, is that PI is extremely efficient at storing time based performance data.

"So what, you can store that in SQL Server, mySQL or Oracle", I hear you say. Yes you most certainly can. But PI was designed from the ground up for this kind of data, whereas relational databases are not. As a result, PI is blisteringly fast and efficient. Pulling say, 3 months of data that was collected at 15 second intervals would literally take seconds to do, with no loss of fidelity, even going back months.

As an example, let’s say you needed to monitor CPU usage of a critical server. PI could collect this data periodically, save it into the historian for later view/review/reporting or analysis. Getting data into the historian can be performed a number of ways. OSISoft have written ‘interfaces’ to allow collection of data from sources such as SNMP, WMI, TCP-Response, Windows Performance Monitor counters, Netflow and many others.

The main point is that once the data is inside the historian, it really doesn’t matter whether the data was collected via SNMP, Performance Monitor, a custom script, etc. All historian data can now be viewed, compared, analysed and reported via a variety of tools in a consistent fashion.

SQL Reporting Services

For those of you not aware, Reporting Services has been part of SQL Server since SQL 2000 and allows for fairly easy generation of reports out of SQL databases. More recently, Microsoft updated SQL Server 2005 with tight integration with SharePoint. Now when creating a report server report, it is "published" to SharePoint in a similar manner to the publishing of InfoPath forms.

Creating reports is performed via two ways, but I am only going to discuss the Visual Studio method. Using Visual Studio, you are able to design a tailored report, consisting of tables and charts. An example of a SQL Reporting Services Report in visual studio is below. (from MSDN)

 

The interesting thing about SQL Reporting services is that it can pull data from data sources other than SQL Server databases. Data sources include Oracle, Web Services, ODBC and OLE-DB. Depending on your data source, reports can be parameterised (did I just make up a new word? ). This is particularly important to SharePoint as you will soon see. It essentially means that you can feed your report values that customise the output of that report. In doing so, reports can be written and published once, yet be flexible in the sort of data that is returned.

Below is a basic example:

Here is a basic SQL statement that retrieves three fields from a data table called "picomp2". Those fields are "Tag", "Time" and "Value". This example selects values only where "Time" is between 12-1pm on July 28th and where "tag" contains the string "MYSERVER"

SELECT    "tag", "time", "value"
FROM      picomp2
WHERE     (tag LIKE ‘%MYSERVER%’) AND ("time" >= ‘7/28/2008 12:00:00 PM’) AND ("time" <= ‘7/28/2008 1:00:00 PM’)

Now what if we wanted to make the value for TAG flexible? So instead of "MYSERVER", use the string "DISK" or "PROCESSOR". Fortunately for most data sources, SQL Reporting Services allows you to pass parameters into the SQL. Thus, consider this modified version of the above SQL statement.

SELECT    "tag", "time", "value"
FROM      picomp2
WHERE     (tag LIKE ‘%’ + ? + ‘%’) AND ("time" >= ‘7/28/2008 12:00:00 PM’) AND ("time" <= ‘7/28/2008 1:00:00 PM’) 

Look carefully at the WHERE clause in the above line. Instead of specifying %MYSERVER%, I have modified it to %?%. The question mark has special meaning. It means that you will be prompted to specify the string to be added to the SQL on the fly. Below I illustrate the sequence using three screenshots. The first screenshot shows the above SQL inside a visual studio report project. Clicking the exclamation mark will execute this SQL.

Immediately we get asked to fill out the parameter as shown below. (I have added the string "DISK")

Clicking OK, and the SQL will now be executed against the datasource, with the matching results returned as shown below. Note the all data returned contains the word "disk" in the name. (I have scrubbed identifiable information to protect the innocent).

Reporting Services and SharePoint Integration

Now we get to the important bit. As mentioned earlier, SharePoint and SQL Reporting Services are now tightly integrated. I am not going to explain this integration in detail, but what I am going to show you is how a parameterised query like the example above is handled in SharePoint.

In short, if you want to display a Reporting Services report in SharePoint, you use a web part called the "SQL Server Reporting Services Report Viewer"

After dropping this webpart onto a SharePoint page, you pick the report to display, and if it happens to be a parameterised report, you see a screen that looks something like the following.

Notice anything interesting? The webpart recognises that the report requires a parameter and asks for you to enter it. As you will see in the second article, this is very useful indeed! But first let’s get reporting services talking to the PI historian.

Fun with OLEDB

So, I have described (albeit extremely briefly) enough information about PI and Reporting services. I mentioned earlier that PI is not a relational database, but a time series database. This didn’t stop OSISoft from writing an OLEDB provider

Thus it is possible to get SQL reporting services to query PI using SQL syntax. In fact the SQL example that I showed in the previous section was actually querying the PI historian.

To get reporting services to be able to talk to PI, I need to create a report server Data Source as shown below. When selecting the data source type, I choose OLE DB from the list. The subsequent screen allows you to pick the specific OLEDB provider for PI from the list.

Now I won’t go into the complete details of completing the configuration of the PI OLE DB provider, as my point here is to demonstrate the core principle of using OLE DB to allow SQL Reporting Services to query a non-relational data store.

Once the data source had been configured and tested (see the test button in the above screenshot), I was able to then create my SQL query and then design a report layout. Here is the sample SQL again.

SELECT    "tag", "time", "value"
FROM      picomp2
WHERE     (tag LIKE ‘%’ + ? + ‘%’) AND ("time" >= ‘7/28/2008 12:00:00 PM’) AND ("time" <= ‘7/28/2008 1:00:00 PM’) 

As I previously explained, this SQL statement contains a parameter, which is passed to the report when it is run, thereby providing the ability to generate a dynamic report.

Using Visual Studio I created a new report and added a chart from the toolbox. Once again the purpose of this post is not to teach how to create a report layout, but below is a screenshot to illustrate the report layout being designed. You will see that I have previewed my design and it has displayed a textbox (top left) allowing the parameter to be entered for the report to be run. The report has pulled the relevant data from the PI historian and rendered it in a nice chart that I created.

Conclusion

Right! I think that’s about enough for now. To sum up this first post, we talked a little about my IT portal and the principle of "passive compliance". We examined OSISoft’s PI software and how it can be used to monitor your enterprise infrastructure. We then took a dive into SQL Reporting services and I illustrated how we can access PI historian data via OLE DB.

In the second and final post, I will introduce my IT Portal template in a brief overview, and will then demonstrate how I was able to integrate PI data into my IT portal to combine IT asset data with real-time performance metrics with no code

I hope that you found this post useful. Look out for the second half soon where this will all come together nicely

cheers

Paul

 

No Tags

A really quick note:

As of last month I am now a Microsoft Certified Trainer, and combined with being a certified MOSS07 technology specialist, hopefully means that my SharePoint bedside manner should be enough to charm and dazzle even your most difficult users, whether senior management or the most scary technical geek.

<blatant plug>

My training style reflects my writing style, so if you like any of the material presented on this blog and feel that it would be useful delivered in person or tailored for your organisation or circumstances, then please do not hesitate to get into contact.

</blatant plug>

thanks

Paul Culmsee

No Tags

Now, readers would know that I really lay on the pop culture references pretty thick. I find it works well and makes ordinary, sometimes mundane, topics much more interesting and easy to explain. I’ve used Brittany Spears, Ikea, Kung Fu, Death metal, Dr Phil and countless others.

But I have never used Star Wars references in my post and probably never will. Why? I would like you to take some time to have a good read of this blog. I am having trouble finding the words to convey how brilliant it is.

http://sithsigma.wordpress.com/

My own company is a play on words on the much hyped/maligned Six Sigma methodologies, but this is so much more clever!

On this blog, both Darth Vader and Darth Sidious offer advice on strategy, project management and general business leadership and management topics. Some absolutely brilliant content there too, all set against the backdrop of what it takes to manage an evil empire. When you think about it, a Death Star is a pretty serious undertaking and to build it on time and on budget takes some pretty impressive management talent. So, despite whether you are an Empire kind of guy, or prefer being rebel scum, you have to concede that Vader and Sidious know how to manage a team. Sure, they made some mistakes (certainly their disaster recovery and risk management strategy were definitely flawed), but most organisations have a misfocussed attitude to security.

Aside from laughing hysterically when reading their material, I am certain that both Sith lords read the same strategy and management books that I do.

Here are some classic quotes..

In this essay on how performance metrics impact employee behaviour, Darth Sidious cites a recent example

…if your compensation system is based on rewarding people for speed, but product or service quality is severely lacking for some reason - even though you’ve mandated quality, it doesn’t make a difference what you mandate if what you’re measuring doesn’t support that goal (or even worse, is opposite to it).

That may seem like an obvious example, but it’s more common than you think. For the Clone Wars we ordered 100M Clones, and we wanted them ready in time to trick Obi Wan, so the Clone factory sacrificed on quality and what we ended up getting was 35% of the Clones being totally useless.

Now *that* is a real-world example that I can relate to!  Here is another gem from Sidious, explaining how the empire maintains a skills inventory to help them understand a team’s strengths and weaknesses.

Say you’re in a team that specializes in using the Force to electrocute captured rebels, or run a Network Engineering team. When it comes to hiring your instinct is to focus on the obvious and primary skill of the team.

Need to fill in an electrocutioner position? Then you’re probably looking for someone who’s learned how to channel the powers of the Force into electricity. Need to fill in a Network engineer position? You probably are looking for a hardcore networking/router/firewall guy.

Probably my favourite article is the Sith version of my "Project Fail" series where Darth Sidious offers advice on strategy, vision and goals. He breaks it down to:

• Vision
• Corporate objectives - eg "Increase delivery time of star destroyers by 10% over the next 12 months"
• Nested Objectives
• Alignment of Projects
• Executive/Sith Lord Sponsorship - "if an executive sponsor, Sith Lord, finds out you spent a large amount of galactic credits and it didn’t pay off, now you’re in deep water with no one to support you. A Sith Lord is liable to feed you to a Panna Monster in such a case"
• ROI

I could go on and on, but I could never do the site justice. The thing I really like about whoever authors this site is that they have managed to find the perfect balance between entertainment value with really insightful and clever messages behind the humour. It is a goal I have been trying to attain in my writing also, but I have to take my hat off to Sith Sigma for nailing it perfectly.

If they would have me I’d write on that site about collaboration under the pseudonym of Jar-Jar Binks

Go take a look now. Tell em Jar-Jar sent you .

Paul

No Tags

Article originally published for EndUserSharePoint.com reproduced here.

Greetings, my cleverworkarounds kung-fu students. Paul here again to talk once more about Zen and the art of SharePoint. Now I don’t want to appear all arrogant and pretentious, but for this post you can all call me "sifu" :-). I don’t deserve the title in the slightest but since I am writing it you are all forced to live in my fantasy world for a while :-).

I have previously written extensively on SharePoint project failure. In some ways that particular series is just as much about "thinking SharePoint" as this series, but I really do not want to rehash the content there. At the same time, I must confess I was trying to think of a way to round off this particular series of articles with a nice logical conclusion and was lost for awhile. But after watching Kung Fu Panda, I realised exactly how I can end it. So this post is the last in this series - for now anyway.

The thing about using pop culture references as I tend to do is that there is always a risk that some readers may not have seen the movie or heard the album that I refer to. So, if you haven’t seen Kung Fu Panda yet, I want you to visit this website and watch the trailer. http://www.kungfupanda.com/. Having done that, I now want you to read this article, and picture my voice as one of those old kung fu dudes with the long wispy beards offering riddle-like advice that makes no sense. If you can’t picture that, use Yoda instead.

Continue reading “Thinking SharePoint Part 4 - Lessons from Kung Fu Panda”

No Tags

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

Hi all

[Quick reference: Part 1 and Part 2]

If you have followed the first two articles in this series, I have been attempting to talk about SharePoint "head-space". In other words, SharePoint success is so much more a people issue than a technical or architectural one. As a result, it can be a little difficult to write about!

As a MOSS2007 product specialist and architect, I have slowly developed a kind of spider sense that allows me to pick out likely problematic implementations fairly early in the process. This spider sense is most definitely not along the lines of "oh these guys know nothing about application development/security/collaboration/[insert word here]". Often there are excellent, really knowledgeable staff on hand with exemplary credentials. It is instead a feeling that I previously described as "organisational maturity". Want a better explanation than that? How about something like the "oh they are *so* not ready for what they are getting themselves into" factor.

In Part 2, I’ve touched on the potent combination of differing personality types and the different stages of learning along with all of the new SharePoint features and options at your disposal. If you did not read part 2, then I strongly suggest you do so before continuing with this article because I am going to revisit the learning types stuff here.

Another way to describe the "unconsciously incompetent" stage of learning (that sounds much less insulting ) can be summed up as "you don’t know what you don’t know". The "Ikea guy" example in the last post is a perfect example of low organisational maturity. In my example, the poor unloved Ikea guy turns up at a house to install an Ikea modular storage solution and has to satisfy the conflicting requirements of a family so dysfunctional that the Simpsons seem pretty tame by comparison. It is clear from an outside perspective, that they have called in the "Ikea guy" way too early in the piece and in fact he is completely the wrong guy to call anyway! Wrong guy? Who should we be calling then?

   

Who you really need is someone like Carson and the boys from "queer eye for the straight guy" - Either them or Doctor Phil. They might come on a bit strong at first, but they work by winning your trust, building your respect and slowly but surely give you the confidence to change your old, bad habits. Before long the dysfunctional family have turned a corner, to the amazement of yourself and those around you. As an added bonus, you had a lot of fun along the way and your dress sense has improved as your stress levels have dropped

You still need the Ikea guy, but at least now the family no longer argues so much over which drawer your socks should be stored in!

Of course, the ultimate SharePoint consultant is this mythical person. can deal with your emotional issues *and* install the system!

Workshops, workshops!

Where possible, I always undertake SharePoint engagements in an advisory capacity before any time and cost estimates are made. Why? Because invariably, many/most clients start from a position of unconscious incompetence. Not just in term of the product itself, but in terms of a shared understanding of the problem with their colleagues and co-participants. Anyone who has been to a Microsoft sponsored SharePoint seminar and thought that SharePoint is the answer to their prayers is definitely in the first stage of their learning. In fact, when a client wants to skip the advisory stage and get straight into the "just tell me how much it costs", my spider senses tingle…

Thus, I run *plenty* of workshops. I don’t believe that "IT Integrators" who, for example, specialise in Exchange, Cisco networking and firewall type security are overly well suited to perform SharePoint implementations. Equally, I’m not convinced that a "Web Design House" is also particularly suited either. Yes, there is a big technical/architectural component (Ikea guys), but most of the work is in the facilitation, dialogue and requirements gathering stage of the process (Carson/Dr Phil guys). In other words, getting people from that "unconsciously incompetent" phase to "consciously incompetent" stage of learning.

I tend to keep the workshops to no more than two hours in a single day, with a break after an hour for everyone to recharge their brain cells with a jolt of caffeine :-). I also keep the workshops to 4 people or less and split into multiple workshops if there are more than 4 participants.

My goal in these workshops are threefold.

• Teach some product basics, answer common questions and set the scene
• Get participants thinking talking about what SharePoint means to them, and what they want to get out of it
• Assess the personality/competency/maturity level among participants ("unconsciously incompetent" versus "consciously incompetent’)

Achieving these goals usually takes two to three workshops and it is unwise to pack all of those goals into one workshop anyway. The first workshop is all about the product basics (goal 1 above). I do not go into massive detail, just enough so that participants are not flying completely blind with their understanding of the product. Signs of success of this workshop are the shared realisation from participants of the huge potential of the product in certain areas, and an appreciation of the fact that there are a lot of organisational issues that will affect success, and thus it is much more than just whacking in the CD and running SETUP.EXE.

Politics, politics!

I prefer to wait a day or two before the second workshops, as it gives participants a chance to take in the content of the first. When we meet for the second time, I do a quick recap on workshop 1, and then we start talking through requirements, issues, constraints and risks. One sure sign of organisational maturity among participants is how long this workshop takes. This is a factor of the scope of the perceived "problem" to be solved, but more importantly, often this is the first time the participants have actually *talked though* a problem together (aside from previously all agreeing that it is sub-optimal in the first place). It is very easy for these workshop to go over time, or to finish unresolved.

Additionally in this sort of workshops, you can fairly quickly assess the political dynamic of the group (goal 3). Participants always have different agendas or belief on what needs to be done to solve organisational problems. Often participants have locked horns with each-other way before SharePoint came on the scene, and it doesn’t take long to see where the dynamics lie. Understanding this dynamic allows you to tailor your facilitation and teaching approach and build trust and respect among all of the participants.

This can be a frustrating stage among participants, especially while a shared understanding is still being developed. But right here is the root of project failure - not just SharePoint.

What I will do now is tell you briefly about two different client engagements that I was involved in some time back. Both of these client engagements happened at around the same time, and each client happened to be in the same vertical market, although they had nothing to do with each-other. Both were ultimately successful projects in terms of delivery, but one was much more successful in terms of laying a foundation for future projects. If any aspect of these two tales resonate with you, please send a comment through at the end of this article.

Client 1

The first client was a tender that had a fixed time constraint (spider-sense goes gangbusters at this point). However the client had attended one of my seminars where we talked about how to approach a SharePoint project. (The subject matter being a more distilled version of my various posts such as this one). Thus, I had the chance to sit down and have a long chat with the client in an informal environment and felt the theme of our seminar had resonated with them and they had a solid appreciation why we approach SharePoint projects the way we do. 

Despite the very tight time frame I was able to conduct a couple of workshops in two groups and we were able to agree on deliverables that were realistic and achievable. However the workshops were an interesting experience. There were too many people and the group dynamic was clearly political in nature and there was open, sometimes rigorous debate, about specifics of the deliverables. The skill levels varied, as did the agendas. This client also outsourced IT support, so was somewhat light on the ground in terms of infrastructure and application development skills. Thus, we made a conscious decision to stick to SharePoint designer and go out-of-the-box for this initial engagement as we felt that the timeframe and process maturity constraints meant that we would be better served using tools that were easy to make modifications to. We had made this clear (or so we thought ) to the client when we responded to the tender.

By the end of the project two deliverables had expectation mismatches in their functionality. A couple of sticking points were actually how SharePoint was architected as a product and the miscommunication stemmed from a lack of understanding of how the product worked in particular regards. To change the behaviour would require disproportionate custom development work that would very likely be redundant fairly quickly, once users started using the product. Additionally, custom application development for SharePoint adds to governance and they were not yet ‘ready’ to make that leap.

Now it is important to note here that the client was not really at fault. You can hardly blame someone when they "don’t know what they don’t know". The failure was on my part, in that I did not do enough to ensure that we had a shared understanding and full awareness of the constraints of our approach. At the time I thought that we had achieved this milestone, but looking back, it as clear that principally due to the very tight time-frames that we had to operate under, we under-invested in this part of the project.

Fortunately in this case, we were able to agree on workarounds that got the project over the line on-time, made logical sense and did not have any major impact on either party. But the major "lesson learnt" from this project is that we never actually guided the client properly to the "consciously incompetent" stage of their learning.

Client 2

Client 2 was an interesting case. They attended the same seminar as Client 1, principally because a competing integrator had sold them the idea of using SharePoint for their Internet site. Upon seeing the high cost of the licensing, the competing integrator then showed them "all of the other great features" that they would get from investing in SharePoint and overloaded them on recycled Microsoft "6 pillar" marketing material. The client liked all of these new features of course, and thus broadened the scope of the deliverables to help justify the cost.

Result? Even more confusion (and at this point they still had not actually *used* SharePoint). So they attended my seminar for some direction and I was subsequently engaged in an advisory capacity to help them make sense of it all.

I used the workshop approach as described above, and the first workshop was heavy going, because it took a while to sort out all of the marketing fluff from reality. They had been the victim of one too many PowerPoint slide decks and thus jumped around from topic to topic. I answered as best I could, occasionally having to use geek-speak but mostly was able to keep it pitched at the right sort of level. The client then had to reconcile the reality of SharePoint against this overly broad scope that they had created for themselves. It was frustrating for them, and I really felt for them. I even went as far as to offer to discuss things over a beer. (It’s amazing how much more progress you can make over beer .

A week went by, and the client called me back in. That week they had spent a lot of time soul searching and debating where, when and how SharePoint should be tackled. In the end they had re-examined the corporate strategy, which was a high level, 3 year plan that had been signed off by the organisation previously. They then examined the IT department’s 3 year plan which was developed to support the organisational strategy.

They came to the conclusion, that their external web site was not the place to start, for various reasons. Instead, they identified a much smaller scope project that slotted in perfectly with both the IT department strategy and more importantly, the organisational strategy. They asked me for feedback and I was very enthusiastic in how well they had done, considering the hard-slog workshops from the week before.

At this point, the transition from "unconsciously incompetent" to "consciously incompetent" was well underway

I met with them a few days later. Since the entire team was behind the agreed project, they had talked to the organisation stakeholders, mapped out and documented the process before I had arrived. They also were eager to learn SharePoint, and since the scope of this project was not large and the shared understanding was high, we were able to use this project as the training exercise to learn various concepts from Farm Administration, libraries, lists and columns, SharePoint Designer workflow and InfoPath Forms Services. When we hit an obstacle, we collectively were able to find creative, yet simple ways to get around them.

That smaller scope project was successfully delivered, and the benefits were significant. The team now has a much better understanding of the product, its constraints and limitations. It was now much easier to plan for and tackle the more significant project of web content management (Internet site) as there was a much greater level of shared understanding between participants. They felt more confident in their knowledge of the product, and now feel confident that they would be able to manage the expectations of the organisation.

All in all, it was a great engagement and I came away with a huge respect for that client. More importantly, the relationship continues to this day.

Conclusion

I wonder if the story of the first client is a familiar one to readers, either as being and end-user or being involved in the project itself? 

Certainly the second client had frustrations at the start, as they realised that SharePoint was not the panacea they were looking for, they stopped, took stock and co-operatively reassessed the situation. Unconstrained from a fixed time deadline, they realised that more thought was required. That action potentially saved them a lot of stress and heartache which they would have experienced had they ploughed on ahead with an ambitions project. It has now given them a great foundation to build upon for the future.

Thanks for reading

Paul Culmsee

No Tags

Those in the security community who have ever performed vulnerability assessment/penetration testing will know of the Google Hacking database. Google is actually a very handy tool to look for potentially vulnerable sites, due to the fact that it will crawl anything it finds. Therefore, if you have misconfigured an externally facing web-based application, at some point the crawler will come along and your misconfiguration will end up in Google’s giant cache.

Extending this risk to SharePoint is not such a stretch. For example, type the following into a Google search…

"view all site content" "sign in" "people and groups"

What do you see?

Scary, huh?

Now to be fair, I have to make some points here.

• Many of these sites are legitimately meant to be accessible to the public
• I am not disclosing a SharePoint vulnerability, or any issue with the security of the product. Hence why this is not posted to say, bugtraq and I am not making a big deal of it beyond this post.
• SharePoint is secure by default in the sense that privileged operations are protected by granular access permissions and anonymous access must be explicitly granted.
• It is extremely unlikely that you will be able to change anything - as this is read-only anonymous access explicitly granted by the SharePoint administrator. Areas of the site not marked anonymous (e.g site settings) should be safe from modification
• If there is an error here, then it is human error around configuration of the product.

But as a "bad guy", when you decide to target an organisation, you go through a phase of gathering as much information as possible. Some of these sites expose domain names, user account names and other personal details. Such information can be used to gather additional information. For example, knowing a person’s name, I could set up a fake email address, myspace or facebook account in that person’s name and target their colleagues using social engineering techniques. Using anonymity tools like tor in combination with say, WGET, you could sponge all of the data and documents on such sites for offline analysis.

Documents left inside public document libraries expose internal system names, acronyms and details that paint a fuller picture of the internal organisational set-up. Such information can be used for bogus telephone surveys for the purpose of obtaining more information, targeted Trojans disguised as patches, etc. On occasion, particularly sensitive information can be found within these publicly accessible lists and libraries. (Consider the risk if a data connection library or client list was contained in a site like this).

Additionally, when I see domain names, it gives me a pretty good idea of the topology of the SharePoint infrastructure also. Why? Well, for example, if I see domain names, then people are signing in using their domain accounts. Therefore, the SharePoint server has to be part of the Active Directory and is very likely residing on their internal network and published to the Internet via ISA or some other reverse proxy or port forwarding technique.

All in all, it should be a wake up call to SharePoint administrators about the risks of information disclosure when setting up public-facing SharePoint sites.

Google does not forgive (or forget).

Thanks

Paul Culmsee

No Tags

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

No Tags

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.

No Tags

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

No Tags