Top 25 Most Popular Project Management Blogs of 2013

Below is a list of the most popular top 25 project management blogs that have been visited from ProjectNewsToday.com over 2013:

1. Herding Cats
2. PMI Blog - Voices on Project Management
3. QuantmLeap
4. Arras People - How to Manage a Camel
5. A Girls Guide To Project Management
6. Virtual Project Consulting
7. Zilicus
8. The Tao of Project Management
9. ProjectManager.com
10. Ron Rosenhead
11. Leadership Freak
12. Mike Clayton
13. The Program Manager
14. Brad Egeland
15. Musings on Project Management
16. Leadership Thoughts
17. Gina Abudi
18. Sensible Project Manager
19. Better Projects
20. Software Project Management
21. Ahha Moments
22. Guerilla Project Management
23. Lazy Project Manager
24. Henny Portman
25. EarthPM

I highly recommend that you check these sites out and subscribe to their updates.

Case Study: SharePoint Governance Lessons Learned

Christy Punch, Senior Intranet Strategist at SCANA Corp and Share Conference speaker tells us about the lessons she learnt when implementing a governance plan in her organisation and shares her tips on what (and what not) to do.

Times are tight. You'll have to make do. We hear it all the time in business and unfortunately there are not many organisations or industries that are exempt from hearing these phrases.

When faced with tight budgets and limited resources, sorting out SharePoint governance can be a daunting task. Especially if you're largely managing it yourself. But SharePoint governance is an important piece of the puzzle to get right and resource strain should not be a reason to forget about it altogether.

The good news is that it can be done with limited resources and virtually no budget. With some careful planning and strategic positioning, you too can create a solid governance plan that everyone can get on board with.

Here are three lessons Christy Punch with SCANA Corporation shared with us that she learned from putting together a SharePoint governance plan at her organisation that may help you when thinking about your own plan.

Do your homework  

Christy found that the best approach for her organisation was to do a lot of the work ahead of time and keep it very simple.

Based on her experience of managing the intranet and working with different people across the organisation, she developed and documented processes, guidelines, training plans, security levels and roles- all the elements she knew her intranet stakeholders were going to be concerned about. Christy made sure this governance documentation was simple and succinct. For example, the SCANA Corp. intranet guidelines for what content belongs on the intranet is only eight bullets long.

Once you have all your governance elements together, you’re ready to talk to the business.

Don’t get everyone in the same room  

One mistake Christy thinks a lot of people make is pulling 10-20 people representing each area of the company together in a room to decide on a governance strategy. What happens here is there are too many cooks in the proverbial SharePoint kitchen. Most people don't know where to begin, in fact most people don't even understand what SharePoint governance is!

Christy instead created processes and documented everything ahead of time before meeting with stakeholders. Then she met with stakeholders individually and walked each through the governance plans and documentation. She explained what they had set up and what risk mitigation plans were in place to address the stakeholder’s unique concerns. Christy then had each stakeholder sign the document to say they had seen it and that they gave their approval to go ahead.

A key consideration here is to make sure to explain how each part of the governance plan acknowledges their concerns and issues. What Christy found was that most stakeholders were so impressed that the team went ahead and did the work upfront and were willing to own governance. It made the governance buy-in process go very smoothly.

Have a retention policy 

 Christy told us that if they could have done one thing differently, it would have been to build a retention policy into the governance plan from the beginning. For example, what do you do with content that is no longer relevant on your intranet, but you need a record of it? What happens to that PDF form that’s been updated? Does the older version need to be archived?

This is one thing Christy and her team at SCANA did not do when they created their initial governance, but something they are currently trying to get in place before the upgrade to SharePoint 2013 next year. The company has existing retention policies for email, personal drives, and shared drives, but the team didn’t consider creating a policy for the intranet. Christy admits that it is an easy need to overlook, because when you launch your new intranet with updated and new content, you don’t really think you’ll need a retention policy.

Even with audits in place to keep content up-to-date and to ensure governance is being followed, four years later we make retention decisions on a case-by-case basis. Content is only growing and we realize that a formal retention policy is needed more than ever.

Three Common Mistakes with SharePoint Governance

Most organisations understand that a good governance policy is essential for any SharePoint deployment. So they create a governance plan. Done. Unfortunately that’s not the way it works. SharePoint governance is a complicated beast and many-a-plan has failed to be implemented because of lack of communication, over complication or producing an epic document that no one reads.

Let us outline three common mistakes people make with governance plans and how we can avoid making them.

1. People don’t know why they should follow your governance policy What often happens with 

SharePoint governance plans is that they’re produced (usually a lengthy document), uploaded to SharePoint along with an email to staff saying it’s there and they should refer to it for any SharePoint related guidance. This method of communication is what I call "toss it over the fence and hope that someone catches it". Do this and it’s very unlikely that your SharePoint governance document is going to be read, let alone followed.

Fix it 

Once your SharePoint governance policy is finished, make sure you communicate why you want people to follow this. Simply stating that people should follow it is not going to cut it. Telling people that they have to follow these policies just because is not going to be as effective as telling them if you tag your document it will make it easier to find later on. Or by following this policy you are helping us avoid legal issues.

Think about your own governance policies and what positive effects will flow from following them. Are there some time consuming tasks that can be sped up by following correct SharePoint governance policy? Will complying with these policies improve business productivity? Will it help staff build better working relationships with their colleagues? Most people have a commitment to making the business work as well as to their colleagues but only if they understand why they are doing it.

2. You make it hard for people to be compliant 

Complying with a governance policy is important, especially when there are legal ramifications. For example, one of the bigger issues especially in the US is that if you have a governance policy and you're not following it, you have created a big litigation risk. So one of the real reasons to focus on governance is to avoid the risk of not meeting legal requirements or having to spend a lot of money in the eDiscovery process when you get sued.

But perhaps people don’t know about this risk (see number one above) or the process for complying contains so many steps and is so time consuming that people are not going to bother with it.

Fix it 


Automate as much as possible to take the hard work out of complying with your SharePoint governance policy. Use templates so that all sites start with good governance built right in. When possible, use a third-party tool to make it easier to ensure compliance.

3. Your SharePoint governance policy is a beast of a document 

We’re really good at writing 100+ page governance documents. Even if you believe it’s a masterpiece and you can think of nothing better than pouring a good glass of red and settling in for the night to read it, I don’t know many people who would agree. It’s a shame because your governance plan actually contains valuable information that people need to know.

Fix it 

No one reads long documents so don’t create a SharePoint governance plan as a long, boring document. Think about creating small bits of consumable information. Wiki pages and quick guides are a great way to easily great small, visually appealing consumable bits of governance guidance.

But if you really want to make it easy for people, deliver your governance content in the context of where people work. For the most part, people won’t pay much attention to governance (or training) until they need to know how to do something. Try to go for “just in time governance”: small chunks of SharePoint governance information delivered at the moment you need it.

For example, if I’m creating a document, I’m probably concentrating on writing the document, not thinking about what file naming convention I should use. I’m only worried about this when it comes to saving my document. So ideally you want your quick guide about file naming conventions to surface when I’m about to save it. Like magic!

A simple, “no code” way to do this is to use Content Editor Web Parts (CEWP) on document library pages. CEWPs allow you to surface information “in place” for this kind of thing.

Although SharePoint governance plans can be seen as just a necessity, the information in your plan is extremely valuable and can help make life easier, not harder, for your users. Make sure you’re communicating the value to your users, making it easy through automation tools and providing “just in time” governance and training.



 

Infrastructure Design Changes in SharePoint 2013

Great presentation from Michael Noel "Infrastructure Design Changes in SharePoint 2013" 

No Code SharePoint Strategy

We will not do anything that involves custom code. We will restrict ourselves to what we can do with out-of-the-box SharePoint and associated tools.

This is somewhat controversial. I can already hear rumblings of discontent from distant IT strategists. IT strategy should be derived from business strategy, right? An IT strategy should put in place systems and practices that support the business in achieving its objectives. If we say “we won’t do any custom code” this is surely a classic case of tail (technology) wagging dog (business). Why should the constraints of a technology be used to tell the business what they can and can’t have?

That is perfectly true. But, and it’s a big but, SharePoint also gives us the following to consider:

• The number of things that SharePoint can potentially do for a mid-size to large organisation is pretty large. It encompasses collaboration, intranet, document and content management, social features, search, business intelligence, and business application delivery. Deciding where to start can be a challenge.
• As soon as you start custom coding within SharePoint (or anything else), the cost and risk both go up considerably.
• For almost all organisations there are some real “quick wins” that can be delivered without custom code. For example, we often build one or two form and workflow driven business applications. These can be delivered in a matter of days and provide tangible value. The appropriate use of third party products such as those from K2 and Nintex can also facilitate the delivery of more complex workflows without custom code.
• Users and stakeholders want to see something. Custom coding projects can take months. A no code approach gives them rapid visibility of where all that money they spent on licencing has gone.

I should make it clear that I am not advocating that custom code should never be used. If for example you have a requirement with a compelling business case that can only be delivered with custom code, then make the case and go for it! However if you are looking at SharePoint, and have numerous possible projects under consideration, then an initial no code approach will allow you to derive some quick benefits at low cost and low risk.

You can then revisit your strategy later once users have got used to the system. At this point you’ll probably find that business requirements have changed anyway, as once people have started using and benefitting from SharePoint, their thoughts about where they need additional functionality almost inevitably change. So when you decide it is time to crack open Visual Studio and start custom coding, the chances are you’ll end up with a better custom coded solution than you would have had if you’d done the custom work up front.

Information Architecture

What information architecture (IA) is.  To be more precise, we need to explain a handful of topics around the subject:

1. What is information architecture?
2. Why is information architecture important?
3. What is information architecture, specific to SharePoint?
4. What is the difference between information architecture and information management (IM)?
5. When should information architecture be addressed?

I will attempt to answer these questions with two goals in mind:

• For those new to the concept of IA, provide an introduction to core concepts. 
• For the more initiated, provide a framework (a checklist?) or at least a starting point to make sure the main points are being addressed in their own projects.

This isn't meant to be fully inclusive but will, I hope, get readers thinking about their own requirements to make sure they've addressed all the areas they need to.

What is Information Architecture?

 

For an "official" definition a good place to start is provided by the Information Architecture Institute.  They describe IA as "the art and science of organizing and labeling websites, intranets, online communities and software to support usability."
I quite like this definition.  It truly is a little art and a little science.  But it's a tad narrow.
Another definition I'm fond of is one I've heard Randy Williams use, which is "your company’s way of describing, organizing and discovering your content."  This is a lot more high level, which I like as it leaves room to include all of the things that make sense in your project.
More specifically, IA tends to include the following aspects of a website:

• site taxonomy/structure
• metadata
• search schema
• navigation

These are all interrelated.  In fact in many cases, one drives or informs the other. For example, if you're employing navigation that is automatically driven by the site's structure, your site taxonomy will impact the usability of your navigation.
Further, though I won't focus on it in this blog, a key driver of your IA may be another topic of interest (and confusion): SharePoint governance.
As an example, imagine a company has created a governance plan, which states that SharePoint sites containing customer data must have auditing and content expiration policies applied to them.  Because these sites represent a small subset of the overall application, it may be wise to segregate them in their own site collection where the policies can be applied, while other sites can reside outside of this "special" site collection without the overhead of these policies.
For more on governance, I recommend reading A Definitive Guide To SharePoint Governance: Whitepaper by SharePoint MVP Jeremy Thake, Randy Williams, and Richard Harbridge. But for now, this should illustrate the point that governance may impact IA.

 

Why is Information Architecture Important?

 

This is a good question.  Why should you care about IA?  Is it just an abstract exercise or does it have an impact on your site's users?  The answer is that it is absolutely crucial, and in many ways.  To name a few:

1. Usability - Sites that lack a well-thought out IA tend to be less usable.  It's more difficult to find information and site navigation tends to be substandard or confusing.
2. Adherence to Governance Plan - As alluded to earlier, your IA may be one piece of how a governance plan is executed or adhered to.
3. Compliance - Policies that allow us to adhere to compliance regulations are quite often driven by metadata.  If the metadata design is lacking, it may be difficult or impossible to stay in compliance, which can have tremendous legal and financial repercussions.
4. Site Management/Administration - A strong IA will help prevent site sprawl and may help address storage requirements or goals.

Simply put, without an IA in place, your site will be inconsistently tagged, poorly organized, and difficult to use.  And depending on the criticality of your site, this could be either a small annoyance or have much more grave significance.

What is Information Architecture, Specific to SharePoint?

 

In general, SharePoint IA requires attention to the same topics that any other website does.  But SharePoint does warrant a specific discussion because there are SharePoint-specific mechanisms and structures that must be addressed and because SharePoint's nature is to empower users to create sites and content on their own.

If the IA is not well thought out (as well as executed and adhered to), site sprawl and other undesired results are sure to emerge.  Some of the SharePoint-specific topics that must be addressed are these:

Content containers - By this I mean, deciding whether content or sites will reside in a specific farm, web application, site collection, or subweb.  Decisions about where to provision a specific site will include, among other things, configuration requirements, compliance/data segregation/encryption, specific SLAs, and navigation.

Metadata Structure - This includes defining Managed Metadata term sets, site columns, content types, content type hubs, and more.

Search Schema - SharePoint Search managed properties and crawled properties (and their mappings) must be well thought out to ensure quality search results as well as setting the system up to create search-based applications.

Now, I mentioned this isn't a full list, but even so, you might have noticed there are some obvious things missing.  Which leads me to the next topic.

What is the Difference Between Information Architecture and Information Management?

 

At a high level, I think of IA as the design and planning of your application whereas IM is the implementation, application and execution of that design.

So as an example, your IA may define a metadata taxonomy for tagging content and a content type hub to manage those terms centrally.  The IM part of this would be, perhaps, configuring auto-tagging on this library to make sure that the tags are actually applied.

Another way to look at this is that IA describes where and how content is organized, while IM is an application of tools and configuration that describe how this information behaves.
Some of the areas of IM that need to be addressed follow:

Permissions/Security - Who has access to the content?  What different permission levels are available to apply?

Content Lifecycle - When does an item become a record?  When and how is old content archived?  Is content ever expunged from the site?

Policies - What type of auditing and reporting is required for the content?  Can the information be printed or emailed?

Provisioning Process - How are sites provisioned?  Which site templates are made available?  Where can sites be created?

Again, there's more to consider here, but this should get you thinking about the types of things to plan for and configure in your implementations.

When Should Information Architecture be Addressed?

 

There's an easy answer to this question.  You should address IA early and often.  If there's one thing to take away from this blog it is that last sentence.
IA should be planned for very early in the project.  In my opinion, it should follow the initial governance planning.  This is because the governance plan will in some way or another define then IA.

IA should be revisited often.  Requirements change over time, sites change over time.  Your SharePoint application is a living breathing thing and your IA (as well as many other aspects of your SharePoint solution) should be reviewed and updated on a frequent basis to make improvements and address the current needs of the business.

Wrap Up

I hope this has been a good intro or refresher on the basic tenets of SharePoint information architecture.  The key takeaways I hope you'll get are as follows:

1. IA describes where and how content is organized, while IM is an application of tools and configuration that describe how this information behaves.
2. IA should be addressed early and often.
3. IA and IM are two major components used to apply and execute your governance plan.
4. A strong information architecture will result in a highly usable site that adheres to compliance regulation, is easy to manage, and where it's easy to find data.

Refresh of SharePoint Server 2013 IT Pro training now available

I would like to announce a refreshed version of the technical training materials for Microsoft SharePoint Server 2013. This training package is for administrators, architects, and business analysts for learning all the new capabilities and functionalities in SharePoint Server 2013. Content doesn’t only concentrate on SharePoint configuration, but also covers the different new functionalities from user experience perspective.

This training package is publicly available from the SharePoint TechCenter and contains multiple videos and downloadable presentations that are used with the videos.

What was actually released?

The released package contains many technical details across the SharePoint Server 2013. This is the refreshed version of the previously released training package, and all materials have been updated to match the RTM version of SharePoint Server 2013.
All videos include slide shows, and most videos contain at least one demo that shows the covered concepts in detail.

• 51 presentations and videos
• Over 17 hours of video
• 790 PowerPoint slides about SharePoint Server 2013

The material has been separated into to 14 modules. Each one contains one or more videos lasting anywhere from 5 minutes to more than an hour.

• Introduction
• System Requirements
• Architectural Changes
• Farms and site architecture planning
• Office Web Apps 2013 architecture and deployment
• Service application architecture
• Enterprise Search
• Social Features
• Enterprise and Web Content Management
• Customization options and management
• Authentication and authorization
• Business Continuity Management
• Upgrading to SharePoint Server 2013
• Project 2013 for IT Professionals

 

Frequently asked questions

Here are a few frequently asked questions related to the refreshed package.

• Can I use these materials in my own presentations?
• Yes. These are made downloadable so that you can use these presentations for explaining the awesomeness of SharePoint Server 2013
• Is there a download option for the videos?
• Unfortunately, no. These videos are currently only available online. We are investigating how to make them available for offline download.
• Is there some additional information related on Project 2013?
• Yes. Check the new Project 2013 training for IT pros and developers training, which was also just released.