Archive for October 2008

Windows Azure Services

October 28, 2008

During the keynotes for the 2008 PDC the Windows Azure Services Platform was announced and more detail was provided on it. For those of you who knew it as Red Dog, the name has changed. Honestly, what is with that naming? Red Dog, Azure Services? Anyways…

What this basically means is that Microsoft is focusing more attention on their cloud OS (as relating to Software as a Service and Cloud Computing), has clearly labeled it as an OS (glee!), and provides a big boost to SharePoint’s online services. White Paper here:

If you look at the above diagram (taken from: it’s pretty clear cut in what it represents. I think everyone saw this coming, and I do honestly believe that hosted services, online services, and service platforms are the future for most business solutions.

The reason? All new technology is focused on empowering business users, and those without technical know how (not to mention technical know how is becoming more and more general knowledge). If you look at the SharePoint platform, Dynamics platform, or any of the other services it’s no longer necessarily the developers who are building solutions, but the business users themselves. Architects and Administrators help manage and guide these business users and developers build out the platform further in areas where gaps are identified. This is a smart, effective and scalable way of doing business that enables the organization to grow more rapidly, be more flexible, and as a result much more profitable.

The other big reason is the cost and headaches that go with trying to manage the hardware, and staff it takes to keep powerful IT solutions running. Online services are the smart choice for small and medium sized businesses that can’t afford to keep training IT staff.

The other great thing about all of this is that Microsoft is just lifting the work they already are working on, not really introducing anything new. Improve the online services. Improve the offline services. Improve the ways in which these systems can integrate and talk to one another while building towards the expectation that the future of cloud computing is going to be realized soon.

With Microsoft focusing more on virtualization and online services I really do believe the future looks bright, beautiful, and yes, cloudy (get it? Cause it’s an internet-scale cloud services platform),
Richard Harbridge

P.S – A few people have asked me what cloud computing is (and why is it a big deal?).
Look at Wiki (, or something like this youtube video ( I could go on about it at length, but honestly just watch the youtube video, and you’ll get an idea of it.

Excellent Training on SharePoint Designer

October 21, 2008

If you are new to SharePoint Development, or SharePoint Administration, or just a business analyst or business user who wants to know what some of the powerful things SharePoint Designer can do for you, and HOW you can do it I highly recommend these demonstrations provided (if I remember correctly) back in august.

Hope this helps,
Richard Harbridge

Lesson Learned: Outlook and Changing SharePoint Site URL’s

October 21, 2008

In outlook connected libraries, calendars, tasks, contacts and synchronized SharePoint areas information will no longer synchronize (and rightly so) if you change the related SharePoint site’s url.

So if you notice you cannot see newly added calendar events, or documents and the synchronization is off, double check the URL of the site has not changed.

The solution’s seems pretty simple if this does happen to you, you just reconnect the libraries using the out of the box SharePoint connect options and the existing outlook entries will now be properly connected (no need to delete and re-add for document libaries), but Calendars DO seem to need to be removed, and then re-added to update appropriately, and seemingly the same result with tasks, contacts, etc…

In fact I would say the key here is to really think about the impact changing a URL has, from bookmarking to services, applications, and things that reference the url externally (in this case, outlook 2007).

So why am I sharing this?

So during a conference this weekend I was setting up for my presentations (on SharePoint as an Idea and Innovation Platform) and opened up my synchronized sharepoint libraries in outlook.

I immediately noticed something that makes any presenter groan. The version of my presentation that was synchronized was several versions back. Well of course I connected through a VPN tunnel to my exchange and SharePoint environment and performed an update… but for some reason all of my SharePoint Lists in outlook didn’t update.

I navigated to the SharePoint site, downloaded the presentation and continued on for the next several hours with the different groups and presentations but then as soon as the presentations were over and I had resolved any outstanding questions I sat in the corner and scratched my head as to what had happened.

Then it hit me: Recently I had changed the site properties of the SharePoint site housing the connected library. In SharePoint 2007 you can modify the title, logo, description, and “URL” of the site.

What I had done was cleaned it up a little bit to account for a new managed path and architecture I was putting in place, what I forgot to think of is how this could impact anyone who has synchronized the libraries and calendars within the site.

In this case it was a minor hiccup, but could you imagine if this had been a site with important data hundreds of people were viewing? Now all those off site who might rely on Outlook synchronization would be unable to see new changes, and because it might not be immediately obvious this could happen for sometime creating a huge cost in misinformation. Not to mention that obviously I had not fully considered the impact other services might experience if they are referencing that previous site url.

(To be fair I also knew I was the only person using this site, and the only person who has access to/uses the site’s materials right now, so (and this could be me trying to excuse it) really I fully expect had this been a different situation I would never have changed the URL without considering the impact in far greater detail.)

Well I won’t make that mistake again! And hopefully someone else out there reading this avoid the potentially extremely costly and dangerous mistake I made.
Richard Harbridge

Internet Presence Scenario

October 14, 2008

These were updated a few days ago and certainly worth a read if you are planning on implementing or assisting in the implementation of a SharePoint Internet Presence.

Not only have they broken down the important phases well, but they have also explicitly provided real examples for many of the different actions and responses necessary to have a successful enterprise internet presence.

Very cool stuff,

Project Management Processes, Phases, and Personal Notes

October 10, 2008

(Cross posted from Project Analysis Blog:

One question I am asked often is how I manage my SharePoint projects, what stages I go through and how I perform/manage each phase of a project. This is probably something you already do, but perhaps it’s good to see some examples of how other people manage projects, so feel free to read along.

Personal Note:

This is a high level summary of what I do in a typical project and is not every individual item. SharePoint is also mentioned throughout this article because it is the technology I most often use when working on projects and organizing information.

Before the Project Starts

Before I start a project I create areas to capture knowledge (KB, and lessons learned), following that I begin the process of the project itself. This is important to do right at the start because even during the pre-project phases you can come up with some interesting notes, concepts, or lessons learned.

Right now I always do this knowledge capture using SharePoint with a mixture of wiki’s and related concepts. So this area is already built and all I need to do is create a ‘project’ and ensure the ‘customer’, ‘client’, and ‘area of business’ represented is also within the knowledge area to ensure anyone who comes up with something new can create articles, upload documents and basically create content that will be associated to that project, client, or business area.

Personal Note:

I normally break a project down into the following phases. Every project, regardless of the size. The good thing is that I do NOT enforce specific templates for each phase. I love the idea of templates in that they can save you time and certainly have some that I can make use of, but it’s important to not force yourself to fill out a document and certain content placeholders just because ‘its part of the template’. This can often create confusing statements, is a waste of effort, and really can detract from the important parts of the document.

Definition Phase

Domain Analysis

I always start off with some sort of domain analysis. That is analysis of the current environment, configuration, and system that is in place. How do things interact with one another? What applications already exist? What version are they? How are they used?

The results of this analysis will should contain an overview of the current servers, third party applications, shared service providers, configurations, and web applications, and existing site collections. I personally like to use excel documents for this (I know I could use SharePoint lists and may consider doing so in the future). Once these have been identified and cataloged the next phase of work can begin.

Requirements Analysis

Based on the objectives and target audience a series of business requirements must be retrieved. These requirements can come from business stakeholders, potential administration, and end users. It may be necessary to hold requirement gathering workshops with various involved parties in order to better understand how people would like to use the eventual system and how the system can provide them the most benefit.

Important things to note from personal experience during the requirements gathering phase:

  1. Involve every stakeholder in this requirements gathering. Even if it’s just to briefly talk about the requirements you have gathered from a high level. This will allow them to feel more involved in providing any input and requirements they might have and ensures that later when the system is being developed or implemented there are no significant surprises or missed requirements.
  2. Ensure you document the motivational reasons for a requirement as well as the requirement itself. This can really help you or the individual drafting the technical specification determine the correct solution for that individual requirement. This sounds simple but you would be surprised at how many people just document Requirements 1A-200C and forget to explain why these requirements even exist. This also can help you if later down the road someone says why did we do this?
  3. Prioritize the Requirements. Its important to identify ‘must have’, ‘would like to have’, and ‘if there’s time’ categorizations for every requirement. Its also a good idea to have further priority information. This extra priority information combined with the motivational reasons should make it clear where you need to spend most of your time, or make sure that the solution absolutely covers these areas.

Functional Specification

These requirements and the knowledge you have gained from the client now allows you to create what is often referred to as a functional specification. This outlines how the users expect to interact with the system, outlines their requirements and ensures that unanswered questions are resolved.

Some important points:

  1. Only one person should OWN (and write) the functional specification. This is very important. This ensures one person is responsible, one person can be referenced for information, and that the creative ideas and concepts represented (while based on many peoples input) is written and communicated by one individual. If the project is very large and this doesn’t seem feasible for one person break it into two smaller projects and have each person write their own specification for a part of it.
  2. Always have a developer or someone who will be writing the technical specification review your functional specification. This review should help point out gaps in the document, or knowledge so that you can interact with the client and retrieve answers without disrupting the technical specification process. (You don’t want the technical specification to start until the functional requirements have been hammered out if at all possible, that way you will not potentially need to redo some technical specification work if requirements change.)
  3. There should never be a question mark in the functional specification. Everything written in here will be signed off on and it should be complete. Ensure if you aren’t sure about something that it is classified as out of scope.
  4. The functional specification must not contain details on how it will be technically implemented. This is the kind of information that should be contained in the technical specification which is developed from the functional specification. The functional specification should contain a ‘from the user’ perspective.
  5. If possible provide scenarios. Scenarios are one of the easiest ways for any reader to understand something. It gives a real world example for how something works and can provide addition insight into why, and how it could be done.
  6. Make it READABLE. This one is very simple. If possible make it fun to read, or if that’s not possible ensure the language it is written in is to the point and easy to read. Never complicate it with business jargon or add extra adjectives to describe something just because you want to sound savvy or the document to seem ‘more professional’.
  7. Include a sort of ‘executive summary’ or overview that is short, to the point and describes high level what the functional specification outlines in more detail. This will allow those who don’t need to read the entire thing to still understand the information it contains.
  8. Include as much detail as possible. If you outline that there is a requirement for notification to be sent to a user make sure you write exactly what the notification will say, and identify any options or actions that can result from this notification.

Design and Architecture

Technical Specification and Architecture

Developer or Architect creates a technical specification or a ‘design doc’ as often I hear it being referred to as. Content contained in the technical specification can include how the solution will be built, what technologies will be used, what the server requirements and hardware requirements are, stuff like that.

Provide specific instructions for how things will work and if possible their dependencies. As an example if you know your end solution will most likely utilize a notification service that will require email provide this information in a clear manner so that upon sign off (or even before sign off) the analyst, consultant, or account manager assigned to interact with the client can begin getting you the things you eventually will need.

Graphic Specification, and Visual Design (or Screen Engineering)

With the technical specification complete we can now document how the screens, components, messages, and features will look to the end user. To be honest, I am not a graphic designer, or even really a designer. So my advice on this area is going to be limited in scope.

What I would recommend here are these few things:

  1. Make a specific note that these are recommended screen designs but that the end result may differ slightly. The initial screen designs rarely capture every single aspect of the solution and do not get modified at some point. They are the guideline and really help clients, developers, and anyone else involved understand what to expect. Since this is setting their expectations make certain they realize that minor adjustments may be necessary to make it more functional or user friendly down the road.
  2. Notify the client of any graphical changes. If you do make a graphical change or desire to make one after the client has signed off and the project has started in earnest, make certain you notify them. Get them involved even if it’s not an active role to make sure that it reduces potential trouble down the road.
  3. Do not add extra functionality to make things look nicer. Keep in mind you have a limited amount of time for this project. The designs should mirror what is outlined in the functional and technical specifications. Often (by accident) a graphic designer may adjust something to make it look nicer but not realize the implications that adjustment can have. It’s important to think about everything that might be effected by visual adjustments.
  4. Have technical staff review the design. Don’t just have the analyst, or consultant review the design make sure the developers also review it. They may point out inconsistencies or potentially better ways of presenting information or taking user input. They know the tools available to them, and in SharePoint as an example will know the effort required to style and adjust certain items, over others. (Example changing the way a list presents information as opposed to adjusting a master page.)

Development Plan and Project Plan

Based on estimates for how long tasks should take and a logical rational breakdown of responsibilities create a project plan. I normally use Microsoft Project because it makes it easier to modify later, tell what’s on the critical path, manage resources across projects, and so on and so forth.

Important Note:Don’t forget your communication, training and support plans! These should be all elaborated on and clearly identified at this stage along with their time and associated cost. SLA agreements might be created here, or communication plans. So keep in mind that while I am only describing briefly the project plan and development plan that there are a great many other potentially required plans and agreements necessary before you should move beyond the planning stage.

Include clear identification of how the system will be governed in a governance plan. This is especially important for SharePoint deployments and is probably the single biggest thing I often see missed. Here is a TERRIFIC sample of a governance plan created by Joel Oleson and Mark Wagner:

Create a development plan based off of the technical specification and the design specification. Ensure all estimates, times and tasks have been delegated under this plan.

Depending on the environment I like to use a RACI model for both plans.

RACI in this case stands for Responsible, Accountable, Consulted, and Informed. Basically for each developer/team member I make sure that it is clear whether they are responsible, accountable, need to be consulted, or need to be informed of each and every task. This is normally pretty easy to do, but it makes sure that everyone always knows who needs to be consulted with, informed of changes, or who is accountable for a task being complete etc.

Personal Note:

This doesn’t always make sense. There are some teams that may take offense to the concept, and it isn’t always the easiest thing to keep track of. However in important projects I believe this is an integral piece because without a RACI model implemented you cannot always determine what might have gone wrong, or how it can be resolved in the future. Personally I always use one and fill it out regardless, but it is best if each member has input and agrees to the RACI for each task.

One thing I also do is often use Project Server to really expand my capabilities in regards to being able to show the project plan, baselines, etc without actually requiring a user to download project. This is especially important because project can really be a scary big thing for most users upon first beginning to use it. It also saves lots of cost and some space on all the developer and related project personnel.

Specification and Project Plan Sign Offs

All stakeholders sign off on the functional, technical, and design specifications as well as the project plans. Everyone must be in agreement from the customers to the teams that will be implementing it. This saves time down the road, as it’s more costly to make changes to projects further into the project and ensures that all involved parties have been included and have taken responsibility for the solution.

Personal Note:

If there is trouble making the technical specification most of the time it is because the functional specification and requirements have not been fully identified. If the design specification has lots of trouble then it’s probably the functional or technical specification that might be at the root of these issues.


The development phase is fairly straight forward. The technical specification has broken down the technical details. The design specification has broken down the look and feel. The development plan has broken down the tasks and responsibilities.

With all of those in place this is a smooth and easily managed phase of the project. It also has HIGH visibility of where things stand because you can always compare against the development plan, technical spec and visual designs.

Personal Note:

Standards are a wonderful thing but continue to evaluate them to ensure that they remain current, relevant, and useful. Keep things structured if possible as this helps you keep estimates more accurate. However do not crush your teams with impossible to meet standards. These provide no benefit and detract from the important of standards. Make sure all goals and standards are attainable and have clear indication of why they assist developers and team members.

Security Testing

One thing that I have seen over the past few years is a new more specific form of testing for security. In today’s world security is becoming more and more specialized and more and more important. To this end it might make sense to have a security team perform security tests, provide input on potential vulnerabilities, and often elaborate on ways to improve security for the code, application or system.

Unit Testing and QA Testing

There is unit testing and there is Quality Assurance testing. These are totally different things. In unit testing you will test individual components, and then STILL in unit testing you will test things integrated with one another often in a SIT environment. When all of this testing is completed and everything looks perfectly solid you move it to QA for testing. But only once you have fully tested the components.

QA will evaluate whether it matches the visual designs, and the functional specification. In some cases also the technical specification. Their job is more to just assure that the quality is there and come up with tests that the development team would not have thought of. Unexpected user inputs, or ways in which the user can use the system (still using the functional specification as a guideline) that maybe the development team missed.

Personal Note:

It is important to have a SIT (integrated testing area for all the individual modules and components) environment for development as well as a seperate QA environment. Keep in mind that all these environments should match as best as possible the client’s environment to avoid environmental issues and troubleshooting that might be needed down the road.



Before you deploy anything anywhere it should be clearly documented what you will do, what performance and outage’s it could result in, and how the changes you make can be undone.

Along with all of this you should also have any help documentation, user manuals, administrator manuals, and other documentation that is produced in your project complete or very clearly defined before implementing any solution on a client’s environment.

Lastly, document exactly what you do in that environment so that you can diagnose issues, or protect yourself from being blamed for unrelated issues.

UAT Testing

User Acceptance Testing is very important. This is where users review the solution in their own environment and ensure that their expectations have been met and that it is a usable beneficial system. Earlier in the plan it was important to note that any communication and training should be clearly identified. It is also important to note that if at all possible preliminary training at least should be done before UAT. This will ensure that your resources at UAT are not teaching people how to use the system as much as ensuring it meets or exceeds all of their expectations.

Personal Note:

For projects where the client doesn’t have the money or interest in training I normally expand the UAT cycle to account for the fact I (or my team) will also be training while performing the user testing.

UAT Fix and Testing Cycles

Taking any exceptions from UAT and ensuring that they are fixed and fully tested and then if needed ensure that the user has accepted the changes as well before moving on to the final deployment.

These cycles can often go back and forth more than once depending on how good communication with the client has been, how well client expectations have been managed, and how accurate the initial specifications and plans were.

Final Deployment

Your last deployment (aside from updates and new releases). This follows the same documentation rules as before.

Communication and Training

This is the full training, and communication phase. Often this could be workshops, webcasts, training sessions, assisting the organization with posters and improving internal user acceptance or user adoption etc etc.

Support and Feedback

SLA’s might contain what your support details are. Often this could be fixes, warrantees, upgrades, or even live support. It really depends on what you identified with the client. I also like to ensure that feedback is gained from the client. This provides a wonderful opportunity to create business references, case studies or other great marketing tools because the solution is new, exciting, and in (hopefully) most cases the client is very happy and satisfied.

Hope this helps someone or stirs some ideas for how to better manage your project through it’s phases,
Richard Harbridge

Usage Analyis or Site Usage Statistics with SharePoint Designer

October 9, 2008

Previously I posted a post on getting usage statistics beyond 30 days (for those who use the default SharePoint usage statistic pages) located here:

After receiving some questions on what else is possible on SharePoint designer and answering many of them I figured I should post this to help anyone else who might be curious as to some of the easier reports you can get out of Designer:

Hope this helps someone in the future,
Richard Harbridge

Content Editor WebPart Absolute URLS and No Version History

October 9, 2008

There is a great guest post I highly recommend checking out on the ECM blog by Andrew Connel. Basically what Andrew says is that it is always best in most publishing scenarios to use the Publishing Rich HTML Editor Field Control over the Content Query Webpart if Version History, and Relative URLs are important to you. (Which let’s face it, they pretty much always are in a publishing scenario (especially if you have staging and production).

You can find the post here:

Thank you again Andrew and the ECM team,
Richard Harbridge

Project Management Solutions in SharePoint

October 6, 2008

Decided to copy some of the thoughts I tossed out in the forums today here.

Some point for how to deal with managing projects in SharePoint. Should you separate it by customer? Organize it by area of business?

This really depends on what kind of projects these are and what is being presented in these areas. How will you probably reference the material contained in these ‘project spaces’? Will you be creating management dashboards for tracking project budgets and deliverables? Is this more important in some ways then the project material? Identify priorities and let this influence how the architecture will be, that way you can ensure you are satisfying the majority.

Let’s start with the basics. You have either a controlled area or a collaborative space. Controlled areas present information and are sort of a knowledge center where you can use previously completed work to help your current work, think of it as a place where templates and finished/polished work goes for future reference. The collaborative space can become more wild west in that it isn’t centrally controlled and moderated (to ensure it’s up to date and relevant). These areas are more for creative collaborative work such as responding together to an RFP or working on ongoing projects.

What I would do is create a collaborative space for projects with templates that allow managers and higher business users to see the status and dig down to existing/past/and proposed projects. Think of the webparts for a second and you could easily have a project list filter many other webparts on page that display project issues, tasks, documents and content from various sub sites (dataform webpart, content query webpart or custom solutions).

SharePoint/WSS has templates that can really help you get some ideas on how you can implement issue management, task management, document management, and the such here: and here:

Some notes from personal experience:

    1. Everyone actually manages projects quite differently.
    2. Project Needs dictate what information is produced throughout each project and it does not always follow a specified process.
    3. The technical savvy of specific project teams and more importantly project managers can be VERY different.
    4. Project Management includes working in projects but also managing and getting reports on project metrics (especially important in larger corporate deployments). Take the time to identify through analysis just what data people need, want, and could use to provide the most benefit to your business.
    5. Think about what gets created in a project. The content that is produced in a project should be fully evaluated to ensure the project management system stays in line with project goals.

      So it’s important to seperate content and offer several templates from the simplest to the most complex. Create a template for example that has issue management and milestone tracking but don’t impose this for small projects that don’t require it. The system has to improve people’s use, and if you overload the template trying to please everyone it will become confusing and create lots of wasted ‘space’. Architect these tempates based on the information produced throughout the project process in your organization and keep in mind that this process should be flexible as often it changes as can the results of a project.

      The possibilities are really endless and it depends on the kinds of projects you manage. If these are development projects I like to organize content in libraries that follow the developer methodology (Domain Analysis, Analysis, Architecture etc) and then include most of the things you find in those templates along with expanding on a sort of lessons learned concept where I use a wiki library.

      Another terrific thing is because it’s all built in SharePoint it keeps communication, training and maintenance down and if it’s been well designed it should be easy to adjust SharePoint and the templates to include new features and functionality that further improves use.

      Hope this helps get you started in the right direction, and try investigating other project management systems, it can give you some good ideas that are very easy to implement with SharePoint’s versatile framework.
      Richard Harbridge

      Calculated Column Dynamically Updated (When using [Today])

      October 3, 2008

      Today I was asked a fairly common question that everyone who uses calculated columns eventually runs into. “How do you get a column to calculate automatically when using a reference for a date, or something that dynamically changes like [Today]?” Out of the box this isn’t available because the calculated columns ONLY calculate when an item is updated.

      The solution is simple, you write a custom solution that updates all items as desired. So this could be something that runs daily or every time you view the data (using a dashboard). You could even write the code so it adds and removes the column instead of iterating through the items. Do some performance testing to see which is faster in your case.

      A terrific Article was posted by Dink that answers exactly how to do it too with free samples:

      There is also a post here by Chris where he uses the DataView and JavaScript:

      Hopefully this helps someone out,
      Richard Harbridge

      AD, Audiences and AD Group Memberships

      October 2, 2008

      Today I was working on attempting to determine the impact of various AD changes to SharePoint. This is because (like many many organizations out there) the AD structure must be revised and groups must be removed and renamed as a great many are no longer used (such as SharePoint Admin 2001 etc).

      First of all “How can I find out the memberships (or the users) who are contained in an AD group?” This should be a simple thing to answer but if you don’t have access to AD directly (as I do not) then my recommendation is to use the Audience management functionality of SharePoint as a good alternative.

      1. Add a new “Test” Audience.
      2. Add a new rule with “Member Of” being the AD group you want to know more about.
      3. Compile this new Audience.
      4. Click “View Membership”

      Now you can see the users in various AD groups from within SharePoint and you don’t need access to AD directly (with your user).

      So now you can start to look over AD groups (in SharePoint) and you can see them all listed (ignore the nickname ones etc created by SharePoint). You might notice a couple odd things next.

      The first one that stands out is multiple listings of an AD group. I struggled with this one for a bit and found this article: (Thanks Monty for writing this one.)

      So let’s summarize: “What do you need to know about AD and SharePoint?”

      • Changing an AD Group’s canonical name can result in duplicate entries in the audience targeting searches.

      If I discover anything else I will be sure to update this post and let all of you know,
      Richard Harbridge