Here’s some magic for you. If you add an out of the box style to a view of an App (list or library) the links to the views disappear. We are not talking custom code here. We’re talking about selecting a view style from the Style drop-down.
View with no Style added.
Links to additional views are missing.
Style is applied, but your links to additional views have disappeared.
You can still get to the additional views by clicking on the List or Library tab, and clicking the drop-down for Current View:
This is NOT the type of behavior I expected. How about you?
Please comment if you see different behavior in your uncustomized environment.
It’s not very high tech, but it works. Create a spreadsheet with tabs for your SharePoint Groups/Sites Matrix and each permission level used on the site. You may need to expand the SharePoint Groups/Sites Matrix to include lists and libraries that are uniquely secured.
Here is an example of one I’ve used.
View and download a copy of the spreadsheet here.
While defining requirements for any project, you will run into scope creep. You get talked into adding little bits of functionality because “It shouldn’t take anytime.” Then you end up with an additional 900 requirements that “shouldn’t take anytime.” This happens A LOT in SharePoint projects, because SharePoint is so easy (according to some). If you don’t get a grip on this early in the process, you will run into this….
You are hired to build this within a specific timeline and budget
While defining requirements, the project morphs into this, but has the same timeline and budget
As you build, the requirements keep rolling in. Now people want this within the same timeline and budget
Here are 5 steps to manage scope creep before it becomes scope sprawl…
1. Figure out what you want to accomplish
- Clearly define what you want to see at the end of the project
- If you want to save time or money, figure out how much time and money you are spending now
- How much do you want to save? Pick a number or percentage. Example: We want to save 30 minutes per transaction. We want to reduce repair costs by 3%.
- If this is a new process or solution, figure out what the CEO wants to see
- All requirements need to map back to these decisions
2. Rate requirements
- All requirements should map back to what you want to see at the end of the project
- Rate requirements on three things:
- Relevance to project end state – Is this requirement needed to reach the end state? Would this requirement make the end state better? Would this requirement make the end state perfect?
- Effort – How much time and money with this take? Which resources do we need to complete this requirement?
- Other Systems – Will meeting this requirement make changes to systems not currently involved in the project? The more systems we touch the more challenging it will be to meet the requirement. Was changing these systems part of the original scope?
3. Next Version
- If a requirement is not integral to the end state, the effort would be too great, or would touch too many systems, consider making it part of the next version or update to the end state
4. Sign Off
- Get sign off from the sponsor before the build. Very surprised at how often this doesn’t happen in SharePoint projects
- Understand that even though you have sign off, there will be changes
- When there are changes requested, share with the rest of the team
- Run the request by the sponsor after clearly defining relevance, effort and effect on other systems
What steps do you use to manage scope creep? Add them to the comments below.
It should come as no surprise to anyone that how we switch views in SharePoint 2013 lists and libraries has changes.
To make it easier to spot the differences between 2010 and 2013 let’s do a side by side comparison.
What to click on to change views
Make the View Menu appear
View Menu from Library tab
With another web part on the page
Please let me know if I should add something to this side by side comparison for Views.
Your user isn’t stupid; SharePoint is stupid.
There I’ve said it.
Let the skies open up and lightning strike me dead.
- SharePoint is a tool.
- Tools don’t do anything. They are stupid.
People use tools to build things.
- The tool appears brilliant, but really it’s the builder, or the business analyst, or that team that knows the process/issue.
Teach people to use what was built.
- Remember how intimidating and exciting it was to drive a car or ride a bike for the first time?
- Did you try to do it on your own the first time?
- Did you have help?
If you don’t teach your user how to use what was built, you will need to point that stupid finger at yourself, not your user.
You were hired for your job, solving issues with SharePoint (if you are lucky). The sales team you are building a solution for was hired for sales jobs. They are not stupid because they don’t know SharePoint. You are not stupid because you don’t know sales. SharePoint isn’t stupid because tools can’t be stupid they are inanimate (unless you have enchanted tools).
Consider this the next time you want to call a user stupid because they don’t know SharePoint.