SharePoint Notifications using JGrowl

Slick little bit of code, full of AJAX-y goodness!

SharePoint 2010 Popup Notifications

http://zieglers.wordpress.com/2011/07/28/jgrowl-notifications-for-sharepoint-2010-part-1/

http://zieglers.wordpress.com/2011/08/22/jgrowl-notifications-for-sharepoint-2010-%E2%80%93-part-2/

SharePoint Governance a bad Idea?

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?

Danger! Do not implement SharePoint in your Organization! REDUX

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”!

Make Your SharePoint 2010 Master Page Extensible with Delegate Controls

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.

image

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:

image

After I deploy my Feature, we see that the default content is replaced with the Feature’s control’s output:

image

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.

image

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.

Why are you still not focused on the business when implementing SharePoint?

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:

  1. Collaboration
  2. Document management and file-share replacement
  3. Portals
  4. Intranets

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.

SharePoint 2010 Workflow Example – Custom Association and Initiation Forms

A year of so ago I wrote a couple of posts on MOSS 2007 workflows, specifically around the creation of custom Association and Initiation forms using InfoPath. While neither of these tasks are really very difficult (once you have figured out how), I think most would agree that the whole process is a great deal more messy that it should be.

Now that we are near the release of SharePoint 2010 (it went RTM last week and ships May 12, for those who have not seen the 2 million other posts letting you know), I thought I would revisit these same activities in SharePoint 2010 to demonstrate the fact that the process is whole lot less messy.

(Note that I have not had time to do screen captures as I did in my previous examples. If you have trouble following what I have done, leave a comment and I will add the pictures in).

The first couple of steps are identical to the previous version:

1) Create a new site.

2) Create a new document library (make sure you add at least one document to the library for testing later).

Now things get a little different.

3) Run SharePoint Designer 2010, and open your site.

4) In the Site Objects list on the left hand side, select Workflows. You will see the list of workflows defined on the site, which at this point will just be built in workflows. You can edit these workflows (though I wouldn’t) or you can create a copy of one of them to serve as a starting point. In this example, however, we will start from scratch.

5) In the Ribbon you will see three choices for creating a new workflow:

  • A List Workflow: Creates a workflow associated with a specific list. These workflows can only be associated to one list, and cannot be re-used
  • A Reusable Workflow: Creates a workflow which is not pre-associated with a particular list. These workflows can be later associated with one or more lists or content types. They can also be exported as WSP packages and reused across multiple sites.
  • Site Workflows: Site workflows are not associated with a list or content type. They are initiated from the Site Actions menu, and their instances are not connected to list items.

In this example, we will create a Reusable Workflow. Give your workflow a name, a description if you want, and leave the Content Type selection at “All”, and click Ok.

6) You will now see the workflow editor in SharePoint Designer. The main canvas is where you design the logic of your workflow. Make sure your insertion point is in Step 1, and from the Action gallery of the Insert section of the Ribbon, select “Log to History List”. Click on “this message” in the design area, and enter text to be logged. I used “My Workflow Started”.

7) Now for the point of this example – we will create an Association and Initiation parameter. In the Ribbon, click on Initiation Form Parameters.

Click Add…, and define a new parameter. Mine is called “MyParameter”, is of type “Single Line of Text”, and will be shown on both the Association and Initiation forms (you can also have a parameter which is only shown on Association, or only shown on Initiation). Once you have defined your parameter, click Ok.

8 ) Now you can add a reference to your parameter to you “Log to History List” activity. Open the message to be logged, and click the ellipses (…) to display the string builder tool. Click Add or Change Lookup, and select “Workflow Variables and Parameters” as the Data Source. Then select your parameter in the “Field from Source” drop down, and select String as the “Return Field As” selection. Click Ok, and then Ok again.

9) Now we should be ready to test things. In the Ribbon, click Publish. This will make the workflow available in your site.

10) Navigate to your site in the browser, and open the document library you created for this example. At the top of the page, under Library Tools, select Library. On the far right side of the Ribbon, select the Workflow Settings drop down, and select Add a Workflow. Select your custom workflow from the list, give your workflow association a name, and leave all the other settings at the default values. Click Ok.

11) A custom association form will now be displayed, asking for your parameter. Enter a default value for the parameter (I used “Default Value”). Click Save.

12) Now return to your document library, and select one of your documents. From the menu for the document, select Workflows. On the Workflows page that is displayed, select your workflow. A custom initiation form is now displayed, asking for the parameter you defined. Enter a value and click Start.

13) You will now be taken back to your document library. Notice that the document you used for the test now has a column named for your workflow, and has a value there of Completed. Click on Completed to view the workflow status page. You should now see the status for this workflow instance, and at the bottom you should see your logged message, with the value you entered for the parameter in your Initiation form.

While this procedure has almost as many steps as the previous examples for MOSS 2007, it is obviously a lot less messy to create and access Association and Initiation parameters in SharePoint 2010. From here, you can go back to SharePoint Designer, from which you can see the actual form (.XSN) used for your workflow, and you can open it up and customize it in InfoPath.