Monday, April 24, 2017

SharePoint - New User group not showing in Site permissions

Referred Link -

Applicable on - SharePoint Editions 2010/ 2013

Recently we have a created a user group in SharePoint 2013 site and after adding, It is not visible in Site Settings - Site permission.

The root cause is Site Permissions link will display the groups which has permission level. So add a permission level.

To add Permission level
- Goto User Group
- Settings 
- List Settings
- Permission for the list
- Grant Permission 

Tip to identify
Cross verify the group is visible under Site Settings - People and Groups - More

Saturday, April 15, 2017


Referred Link -

1. Project Definition

This is a short statement saying what you are doing. It’s a quick overview of the project. Think: Executive Summary.

2. Background and Context

Now you can go into bit more detail. How did this project come about? What’s it going to achieve? Reference the business case and any prior documentation.
It’s always easier to reference other documents than try to reproduce them in here. You can embed them too, as an icon, so people can click to read if they want extra info. Keep this section to a paragraph. Your document is going to be long, so there’s no point in padding it out more than you have to.

3. Execution Strategy

This is the ‘how’. Talk briefly about your approach to delivery. You could mention the methodology you plan to use, whether it’s a big bang deployment or a phased rollout (and if phased, how you are going to split it).

4. Scope

In this part of the document include or at least make reference your product breakdown structure, and Work Breakdown Structure if you have them, key deliverables, or other products. Ideally you should list everything that is in scope in as much detail as you can. If you have a fully-fledged requirements document then you can always reference that.
It’s really important to talk about exclusions from scope as well. If you aren’t covering the work of the Sales team, or if you have no plans to include the Italian office, state as much.

5. High Level Schedule

This is always a hard part, but you should have some indication in here of the high level schedule.
Include a list of milestones. You can pull important dates from the business case, such as delivery timescales that the exec team has set. There is normally someone who has an idea of when it should be delivered, even if they have done no planning and won’t be involved in any of the actual tasks themselves.
If you do have the detail, pop in an extract from your rolled-up Gantt chart. I tend to use a graphics package to make my high level schedules as I think a rolled-up version of MS Project doesn’t look that great in a document. I use Vizzlo (read my review of Vizzlo here).

6. Organisation Chart

A project organisation chart is helpful. By now you should know who is doing what on the project, so pop them on a hierarchy chart.
This shows how the different teams fit together, who is on the Project Board, how the PMO fits in, who is leading the different workstreams and so on. Make one in PowerPoint or a mind-mapping tool and then slot a picture of it into your document.

7. Roles and Responsibilities

Leading on from your org chart, you should go into a bit more detail about what everyone is going to be doing. Setting roles and responsibilities clearly at the start of the project is a huge help when it comes to getting people to commit to the work.
Get a free Roles & Responsibilities template here. Then you can simply reference that, maybe pulling out a few of the key roles and responsibilities to add into your plan.


If you’ve never produced a RACI chart before, read my complete guide to RACI/RASCI charts. It’s easy when you know what it’s for. Drop a summary chart into your project plan document.

9. Monitor and Control Methods

This sets out what you are going to use to keep the project under control. For example, you might include your approach to status reporting, whether you are going to use Earned Value or not, what software you are going to use to manage the budget and schedule and so on.

10. Risk Management Plan

Here’s where you set out how you are going to manage risk. Think about the tolerances you are prepared to work with, what risk profile your sponsor feels most comfortable with and the strategies that will most likely apply to your risks.
Document how often you will review risks, what can be dealt with by the team and what should be escalated. If your company has a standard risk management process, refer to that here.

11. Risk Log

Part of managing risk is having your risks documented somewhere. You don’t want to list every risk in the project plan, but it is worth including the main ones that you know about right now. Then reference where all the other risks will be stored and managed.

12. Budget

You need to include an indication of the approved budget. You won’t want to mention much more than that here, but if there are any constraints about what you can spend in what tax year or how to get money authorised, then note them in the plan.

13. Estimating Assumptions and Methods

Record how you are going to create your estimates for the project (time and money) and note any assumptions. This is really important because if those assumptions are later proved to be incorrect you will find that the basis of estimates you’ve been working to is wrong – with all the catastrophic effect that will have on your schedule.
If you have company-approved estimating techniques, note which ones you are going to use.

14. Communications Plan

Who are you communicating to? When? In what way? A full comms plan is probably several pages and if you have another document that covers everything off just reference that one here.
Otherwise include the details about how you are going to manage communications on your project.
Get a project communications milestone calendar here. It’s not a full comms plan (I have a template that I’m working on to share with you later in the year) but it’s a high-level version that works for small projects or parts of projects where you need to map your communications against dates.

15. Reporting Schedule

A longer document does not make you look more clever or organised. It just raises the likelihood that no one will read it except you.
How often are you going to report and to whom? This could be a sub-set of your comms plan if you are trying to save space but I think it’s worth calling out reporting separately so that your stakeholders know what to expect when.

16. Procurement Plan

If you plan to buy something as part of the project, this section is for you to explain how you are going to go about it. It could be simply a line that says you’ll follow standard company procedures. But you could go into detail about the way you will source vendors, choose a vendor and manage the contract.

17. Health & Safety Plan

I don’t think I have ever worked on a project that had a health and safety plan but if you’re in any kind of industry where that’s important then you should include it. Construction, engineering, environmental projects, even those that involve workers going out to site by themselves or working at night alone should have some kind of formal approach for keeping the team safe.
There’s more information here about what project managers should know about health and safety.

18. Information Management Plan and Configuration Management Plan

Information management plans talk about how you are going to create, share and store project information.
You simply need a statement or two in here. Also talk about how you are going to control documentation and other project deliverables so that it’s easy to see which is the most current version.
Configuration management can be much more complicated than that if you are checking in and out code, for example, but in that case you’ll probably have team or company standards for doing the work that you can reference here.

19. Quality Management Plan

Note how you are going to manage quality on the project. If you have a full quality management plan separately, then you can reference it here. Otherwise talk about what your quality standards are and how you intend to hit them.
If you have a schedule for quality audits or other quality checkpoints, write the dates in the plan.
Alternatively, read this about why I don’t use quality plans.

20. Change Control Procedure

Finally, note the procedure that you’ll use for managing changes. This could be as simple as “This project will follow the standard process for change control.” If your business already has a change management procedure then just reference that. Don’t bother to copy it all out.
With everything here, only bother to do what you need. “Plan” does not have to mean pages and pages. A longer document does not make you look more clever or organised. It just raises the likelihood that no one will read it except you.

Saturday, April 8, 2017

Transformation: Setting goals with vision is important

Referred Link -

Most of the Organization transformations are successful successes or successful failures. The important point, I would like to highlight is to learn from the failures as an organization, rather than leaving all the failures.
In this article, would like to highlight the 4 important steps, that could be established by a transformation goal and continuously monitor and improve the business agility.
  1. Long-term vision: similiar to a product backlog concept, the long-term vision helps us to define at least 1year to 5year vision of the Product / Organization's plan to its employees and teams.
  2. Short-term goals: short-term goals are very important to provide working software, feedback on the long-term vision from Market, customers, internal employees and teams.
  3. Strategy to achieve these short-term goals: strategy needs to be agile (i.e., Be Agile) approach to the short-term goals, to align with long-term vision. since the long-term vision is not a heavy upfront planning exercise, the short-term goals, like iterations - using cadence and continuous flow approaches (i.e., Scrum, Kanban & XP and other agile practices) provide Transparency, Inspect & Adapt.
  4. Structure of the organization needs to be in sync with strategy, that is, the team structure, the inter-dependencies between teams, support teams needs to have a agile structure to be quick and effective - to be efficient in delivering working software and product improvements.
Long-term vision, Short-term goals, Strategy, Structure are very important for a successful transformation.