Slick little bit of code, full of AJAX-y goodness!
I am curious how many SharePoint Developers (individuals, IT groups, consultants, and ISVs) are making use of any or all of the Microsoft Patterns and Practices SharePoint Guidance.
Wow! Just wow! I was reading this post by Paul J. Swider, and I kept waiting for the punch line that never came.
I have a great deal of respect for Paul – I have seen him speak, and follow his posts and tweets regularly. While this presents an interesting counterpoint to conventional thinking around governance, I am afraid he lost me on this one.
First off, lets look at the comparison to Y2K. Is he saying that no one should have invested in fixing Y2K issues, and that no systems would have failed if nothing had been fix? That seems to be what he is saying, since he is comparing Governance to that, and obviously governance is only good if it does not cost anything.
Then there is this statement:
“Many companies haven’t had governance and compliance features in place for there information systems for years. This has been true since I started working with software in the early 90’s”
This is like saying “for many years, most companies did not have software development processes”, and using this as justification that no investment should be made in such processes. Ditto for QA, or project management. We survived without much investment in any of these silly processes.
Just because lots of organizations are using SharePoint and do not have governance, does not mean that they are doing so effectively or the best way they can. It is also still too early in SharePoint’s lifetime to truly assess the long term costs of doing it wrong.
Finally, lets look at
“Most CIO’s and managers I speak with are tired of hearing about soft dollar calculations and want hard dollar cost savings immediately, after all these are complex and challenging fiscal situations they are managing.”
It is true that most CIOs and managers are being pressured into short-sighted approaches to many things. That does not mean that they should abandon meaningful and appropriate processes just because times are tough.
(would you suggest abandoning corporate governance and controls because money was tight? oh wait, I think many on Wall Street did)
Paul’s example needing a new purchase process to respond to funding cutbacks is a good one, and provides a good segue to what I see as a more positive takeaway from this discussion, which is the appropriate use of process.
Through much of my career, I have been involved heavily in process – whether software development, QA, test engineering, innovation, or otherwise. For many years, I worked on military and aerospace projects, which are noted for extremely heavy processes. What I learned from all of that was that you can invest in all the process in the world, and still fail miserably. And even when you succeed, the overhead involved in such processes makes them untenable.
This has led me to what I have referred to previously as just enough process (I know I am not the first to use the term). The software development process must match the context – the type of organization, the type of solution, the potential impact of failures of the system, the potential lifetime of the system, etc. A software development process appropriate for a social networking web app is hardly acceptable for medical devices.
The same is true of SharePoint governance. Cookie cutter approaches will not do. Off-the-shelf consulting processes will not do. This is not a one-size-fits-all kind of thing.
Rather than encouraging the total abandonment of governance processes, or treating governance as a “nice to have” luxury that you do away with in favour of short-term perceived cost savings, it is far more appropriate to encourage clients to find the level and type of governance process which suits their situation.
After all, isn’t that what a good consultant does? Helps the client find the solution that is right for them, rather than applying the same solution to all clients?
This is a re-post of a column I wrote over on Legal IT Professionals a couple of years ago. Just posting it here so that I have a local version.
This column I want to deliver a warning to all of you out there – do not implement SharePoint in your organization! If you ignore this warning, and implement SharePoint anyway, beware. You run the risk of any number of problems, including:
- User dissatisfaction
- Maintainability and support issues
- Data silos, making information hard to find, hard to share, and hard to maintain
- Lots of rework
- General chaos
- Projects that take 10 times longer than you had planned, if they finish at all.
I do a lot of work helping organizations build solutions using SharePoint – is that all a lie?
Not at all. The problem here is the way you think about your projects. If you are consistently talking about “implementing SharePoint” you are going in the wrong direction. If you are talking about implementing any platform, you are setting up for failure. Many of the problems we run into with SharePoint and other platforms arise from focusing on the technologies.
SharePoint is a technology. It is a platform. It is a pretty good platform, in my opinion. Not without its problems, but a pretty good platform.
So what should you be focused on? The answer is obvious, isn’t it? The focus should be on implementing solutions to real business problems, bringing real business value. That was obvious to everyone, wasn’t it? If this is obvious, then why do I still have conversations with potential clients who come to me saying “Help us implement SharePoint”, when they cannot clearly articulate why they want to implement it? Sure, they can spout a lot of vague statements about documents, collaboration, communication, workflow, etc. but where are the clear statements about how this is all going to help their firm?
I think there are a number of reasons this happens. Firstly, maybe I am just talking to the wrong people (too many techies!). However, I have these discussions with many business people as well. Microsoft’s marketing is also a problem (though it is not Microsoft’s fault). People see Microsoft’s SharePoint marketing information, but they typically only pay very superficial attention. They see all these demos of interesting solutions that seem like they must be useful in their world. Then they go to their IT department (or decision makers) and say “Hey we need to implement SharePoint!”
Even worse, they go rogue and implement SharePoint on a small scale within their groups or departments. Then the IT group has to manage all of these emergent SharePoint deployments, so there is a decision to “implement SharePoint” firm wide.
Finally, there are those firms (hopefully very few these days) who really do not understand that they should not be thinking in terms of the technology.
So when is SharePoint not dangerous? Well, that is driven by how you got to “SharePoint” in the first place. I am not going to go into much detail here, because most of this should be pretty well engrained process (if not, call me – I can help ), but here are the big steps:
- Identify clear business objectives/problems to be solved
- Is SharePoint the right technology choice to solve them?
- Don’t try to do everything at once – build a foundation and grow from there
- Pick initial projects with high impact/visibility
- Determine specific ROI goals, success metrics, etc. so that you know if you are meeting your goals
- Make sure to consider the “human” side of things – introducing a platform that touches business processes and how people work requires detailed planning as to how to introduce it.
- Get help! Hire it, rent it, grow it – whatever you have to do, get help. SharePoint is a big platform that does a lot of things, and if you do not know the platform well, you will end up building things that already exist. Also, as with most platforms, there are 6 different ways to do almost anything – some of them are better than others.
The first step, though – change your thinking and your terminology – and stop talking about “implementing SharePoint”!
I have been playing a lot the last little while with SharePoint 2010 Delegate Controls. I have known about them for a ling time, but have never really delved into them all that much.
Most of the examples I have looked at, and the usage ideas I have seen, involve using the existing delegate controls in V4.master to do things like:
- Modify the Welcome Menu
- Customize the Global Navigation
- Add useful code to the page header
Last week, I used a delegate control for something a little different.
For a project I am working on, the client wanted some functionality displayed just below the Quick Launch, on every page in the site collection. I know there are lots of ways to do this (put a user control on the master page, put a web part on the master page, or just put links on the master page, since that’s all the content was in this case).
But then I thought of a little bit more elegant (to me) solution. Rather than explicitly putting the content on the master page, I added a delegate control of my own to the page, and placed it just below the Quick Launch, as shown below.
Several things to note here:
- I gave it a ControlID specific to my application;
- I set AllowMultipleControls to true, which will be useful later
- I included default content in the <Template_Controls> element, so that I could see it change when I activate a Feature with an appropriate control.
- Next, I implemented a Feature in Visual Studio 2010, with a control to replace the default content. The details of how to do this are covered in other places (such as here), but to summarize:
- I created an empty Visual Studio 2010 project;
- I created a user control inside the project (this automatically mapped the ControlTemplates folder for me). It is a very simple user control, and simply displays “Hello, Delegate!”
- I created an appropriate elements.xml file to map my control to the Delegate Control’s ControlID.
So, here we see the how the delegate looks before I deploy my feature:
After I deploy my Feature, we see that the default content is replaced with the Feature’s control’s output:
But wait, there’s more! Remember that I set AllowMultipleControls to true? That allows me to deploy multiple features with controls that map to my ControlId, and instead of only displaying the one with the lowest Sequence attribute, it will stack them all in order of Sequence number, as shown below.
This means that I can add any number of things to the area under the Quick Launch without further customizing the the Master Page.
Maybe I am just easily amused, but I thought that was pretty neat!
The source for this, including the master page, is available here.
I recently wrote a user self-registration solution for SharePoint 2010. As part of this solution, I needed to validate the requested password to ensure that it met the requirements of the authentication provider (in this case, Active Directory).
The code, while hardly rocket science, is something I do not want to figure out again. So I thought I would post it here for my own benefit. If anyone else finds it useful, that’s cool, too!
I wanted to validate that the password met various requirements from the AD policy:
- 1. Length
- 2. Complexity (contains a combination of lower case, upper case, digits, and special characters.
- 3. Content (does not contain all or part of user name)
I did not need to check against old-passwords to prevent repetition, since this solution is creating new users.
Checking for length is blatantly obvious, so I won’t bother showing that.
For complexity, the default AD policy is as follows:
“Passwords must contain characters from three of the following four categories:
- English uppercase characters (A through Z).
- English lowercase characters (a through z).
- Base 10 digits (0 through 9).
- Non-alphabetic characters (for example, !, $, #, %).”
This is pretty simple to do. In fact there are several ways to do it, depending on whether you want to use regular expressions, built-in methods of the string class, etc.
- For digits and special symbols, I simply created character arrays for those two groups, and used the string class’ IndexOfAny method.
- I could have done the upper and lower case the same way, but I decided to take a different approach (just for variety). For a string S, if S==S.ToLowerCase(), then S contains no uppercase letters. Similarly for uppercase.
- Having determined the presence of the 4 classes of characters, I can then simply add up the number of character classes found.
So, code I have used for these conditions is:
The next interesting part was the content check. To check that no more than 2 consecutive letters of the user name or full name are used in the password, I iterate over the username, taking three-character substrings, and checking to see if the password contains them. This is then repeated for the full name. If any of the substrings is found, then the password fails:
That is about it. I make no representations that this is the best way of validating passwords, or even the best. This is just what I thought up over the weekend!
Over the past week I have been reading a couple of recent SharePoint-related papers, and thought I would share some of my thoughts.
The first paper is entitled SharePoint – strategies and experiences from AIIM. This document presents the results of a survey of 624 AIIM members last spring regarding experiences and plans with SharePoint. I strongly recommend downloading and reading the entire report, as I do not intend to cover all of it in this post, only those items that seemed interesting to me (which is actually difficult, because there is a fair amount of interesting stuff in there!).
The findings I found most interesting were:
- Lack of business-case justification for implementations
- Governance challenges
- Perceived ROI
- Implementation challenges
- The number of organizations planning to upgrade to SharePoint 2010
- The ranking of most popular uses of SharePoint
For me, the most startling result in the report is
Half of SharePoint implementations went ahead with no business case being made to justify the
investment. Only 23% were required to make a financial justification. Where a business case was
made, improved collaboration and better knowledge sharing were the main benefits assessed.
Is it just me, or is this insane? As I said last year in my column Danger! Do not implement SharePoint in your Organization!, the focus of your SharePoint implementation should be solutions to real business problems, bringing real business value. A business case is not just something you do in order to get funding. It is something you do so you understand what functionality you are implementing and why. Not doing a business plan is setting the project up for failure, but for a failure you may never know about. After all, if you have nothing against which to measure success, how can you even know if you have failed, or at least failed to live up to potential? I guess I am optimistic, but I thought everyone understood this by now.
The second point is equally astonishing to me. While the first links I saw to the AIIM document had headlines implying some weakness in SharePoint governance was found (here for example), the real finding is that many of the organizations implementing SharePoint simply do not put appropriate governance in place. A great many organizations have a lack of definition of governance of features, sites or content.
Surprisingly, despite the lack of business case and governance, most of the organizations surveyed were happy with the ROI achieved (which is amazing if they had no definition of what they were trying to accomplish!). Only 9% said that the ROI was worse than expected. Then again, maybe this is just a reflection of having no real idea of what you expected the ROI to be.
The results also identified some of the challenges faced when implementing SharePoint. Among the key issues identified were:
- Managing process change
- Took longer than expected
- User resistance to new UI
- Technically more difficult than expected
- Cost more than expected
- Poor performance/infrastructure capability
All of these, in my opinion, are reflections of lack of planning and lack of business case. While many of these challenges are common even in the best of circumstances, a lack of a clear, business-focused vision and plan will invariably make them worse.
There were also a couple of positive results from the report (more than a couple, but 2 I will mention here).
The results indicated that 13% of the respondents are planning to upgrade to SharePoint 2010 almost immediately, while half are planning to within a year. I see this as positive, anyway.
It was also interesting to look at what SharePoint features are most popular in these organizations. While I always tend to think of SharePoint primarily as a portal platform, and a solution development platform (hey, I am a developer), the most popular usages found in the survey were:
- Document management and file-share replacement
These are just some of the points I found interesting in the report. Again, I strongly urge anyone looking at SharePoint to real the whole report.