SharePoint PnP PowerShell Renaming

For those of you who haven't updated your SharePoint PnP PowerShell in the past couple of weeks, please note that the cmdlets have been renated.  They are now using *Verb-PnPNoun instead of the *Verb-SPONoun naming pattern.

For the time being, all old cmdlets have aliases so that old scripts wont break.  However, new cmdlets may not have them, so if you're upgrading scripts, consider upgrading the naming convention as well.

Building a SharePoint Online site from start to finish using OfficeDev PnP

I recently posted an article that discussed various deployment methods for SharePoint Online.  In this article, I’ll share what worked for me in the past when creating entire sites from the ground up.  You could leverage parts of it as needed to develop your process.  Most of the process leverages PowerShell and the OfficeDev PnP PowerShell library.  My process is broken down into the following three steps

1. Gather Requirements

I always begin with identifying the needs of the users.  Those include both configurations as well as information architecture.  When I work with the users to define the information architecture, I prefer tools that are simple and efficient at gathering this data.  For any information that is tabular in nature, I use Excel, while either Excel or an XML editor work well for hierarchical information.  Excel is great because most business users have a basic understanding of how to fill in the sheets and use drop-down choices.
The information architecture components I gather are:

1. Taxonomy (Managed Metadata)
2. Site Columns
3. Content Types
4. Lists & Libraries
5. Views

I like, to begin by defining the site taxonomy.  SharePoint saves me some trouble here by providing me with an Excel structure that can be used to pass the information into the term store. As a first cut, all I need to do is select the worksheet and, if there are no errors, my term groups and term sets are created.  You can get the template by navigating to https://<you rtenant>.sharepoint.com/sites/portal/_layouts/15/termstoremanager.aspx and selecting View a sample import file.

I work with the users to fill in one of these files for each term group.

Once I’ve defined the taxonomy, I move onto gathering information about the site columns and taxonomy columns.  For the columns, I ask my users the following questions

• What should the name of the column be?
• How are the columns grouped?
• Is the column required?
• What type of data will the column hold?
• Is it a multiple choice column, and if yes, what are the choices for the column?

For taxonomy columns, instead of asking for the type and options, I request the association of columns and term sets (based on what they’ve provided me earlier on).
To reduce errors, I present the Required, Type and Multivalue columns as drop-downs for the user.  I calculate the InternalName column by removing all spaces and special characters.  I then add the GUID for each column.  By providing the GUID, I make sure that for each deployment, the column can be referenced by any part of the site using the same ID.



Next, I collect the Content Type data.  Similar to the columns, I use an Excel document to capture the name, group, Field names, and whether they are required.

However, because it’s hierarchical structure, I prefer to convert the content types to XML to simplify the code in PowerShell.

After the content types are defined, I gather the lists, libraries, and views specifications.  I’m capturing only specific settings about the lists, such as whether versioning and check-in/check-out should be enabled.  However, it’s relatively easy to use PowerShell to modify additional information architecture settings.  Just make sure that you capture the information in Excel and alter your import code to apply these changes.
Capturing information about the configurations is a bit more involved as the available options for the configurations vary significantly.

2. Build Master Site

Now that I’ve gathered all the necessary information from the users, I begin to build my master site.  As the first step, I create the empty site and then apply to it all the configurations using specific PowerShell scripts that will match my requirements.  The settings will include

• Turn features on/off
• Set the global and site navigation parameters
• Modify regional settings
• Configure search settings

There are a lot more configurations available, but those are the usual suspects.  Next, I tackle the information architecture by leveraging the Excel and XML files.  Using a combination of OfficeDev PnP PowerShell functions and simple loops, I iterate through these files and build the site in the following sequence:

1. Taxonomy
2. Site columns and Taxonomy Columns
3. Content Types
4. Subsites
5. Lists and libraries
6. Views

Once finished, I deploy a minimum amount of data for each site and taxonomy column for the search indexing.  The sample data is utilized by SharePoint during its scheduled crawls and will enable the site to leverage search-driven configurations and customizations.  At this point, my master site is ready to be exported into an OfficeDev PnP provisioning template.

3. Build Template Sites

I can now take these templates and deploy them over and over to create new sites with the same configurations and content.  Typically, I’ll use the template to create the QA and production environments.  If I haven’t introduced any crazy customizations, then I could even apply the same templates in an on-premises environment.  Finally, I deploy the content to the sites.

NOTE:  It is possible to create the provisioning templates manually, as they are simple XML files.  However, I find it a bit risky as any errors could cause the entire template deployment process to fail.

Benefits of using this approach

I’m sure many readers can weigh into this article and provide their perspective and experiences on deploying sites.  That’s great!  By no means am I trying to imply that this method is better than others – it just works well for me.  A few benefits that I’ve seen using this approach are:

• Gathering user requirements is easy. Depending on the comfort level of my users, they can even provide a lot of the information without my direct involvement.
• It’s very easy to make changes to the information architecture and redeploy a new master site
• By building the master site and using its template to create the QA and production environment, I’m in essence, testing the deployment process

The Agile Misconceptions

I’m on my way home from a great SharePoint Saturday event in Ottawa Canada, where I attended an amazing session by  on "Leading Practices for Planning and Implementing a SharePoint Environment".  His guidance around requirements gathering, stakeholder engagement, technical roll-out, governance, and adoption was excellent.  However, when he was comparing waterfall to agile project management approaches, I was surprised at some of the comments and questions that were raised by the audience during his presentation.  Agile has been around for some time, but I find that there are still some common misconceptions around what Agile really means, which compelled me to share my thoughts on the topic.  Here are some of the classic examples

The Invisible Client
Some clients expect to give you their requirements and then deliver a project that will meet their needs.  In most cases, if you deliver to your client exactly what they ask for, they will realize that what they asked for is different from what they need.

Agile projects run in short iterations called sprints, which typically last 2-4 weeks.  At the start of each sprint, there is prioritization and refinement of user stories (that’s agile requirements) to ensure the developers know what they need to work on.  At the end of the sprints, you review the solution with the client and give them a chance to provide feedback.  With these iterations happening throughout the project, it’s important that you get the necessary participation from your client.  As well, there may be questions that need answers while a sprint is in mid-flight.  If your client is not available, your sprints and overall delivery are bound to delay and fail.

Change Happens!
If your client is expecting to get all the requirements they defined in their scope, STOP!

Clients are often stuck in the past where they commit to a budget and timeline and expect a certain set of scope (if not more!)  This reality works when you are executing your project using a waterfall approach. However, when you’re agile, your scope is, and will most likely change throughout the project.  When discussing the budget, time, and scope with the client, you need to make them aware that the budget is assumed fixed. The timeline, which is broken down into sprints will vary based on the resources required for each sprint but is directly controlled by the budget.  Scope, on the other hand, is flexible.  Create your backlog of user stories and review them at the start of each sprint.  The only certainty of scope should be what gets delivered in the current sprint.  Everything after that is subject to change.

Don’t Document – Just Code
The whole idea behind agile is to be light-processed and not create any documentation.  Right?  WRONG!!!

Although one of the four core pillars of the Agile Manifesto is “Working Software over Comprehensive Documentation,” it does not mean that you don’t create any documentation.  Yes, you eliminate for the up-front investment of heavy, detailed requirements and/or specifications document.  However, you still need to capture the requirements at a high level as user stories in a backlog and prioritize them with the client.  Once a sprint begins, business and technical details for the sprint tasks also needs to be documented.  You create your document piecemeal as opposed to in one large step.

Agile Requires Smaller Teams
By being agile, you achieve more with fewer people.  That’s like saying you can work twice as fast by having two keyboards.  No true.

The skills required and responsibilities are different.  However, to achieve quality results, you still need to have the right people and allow them the necessary time to complete their work.

I hope my thoughts help clear some of the misconceptions around the topic.  I'd like to hear if anyone else has experiened similar scenarios.  Please reach out to me if you'd like to discuss this further.