Wednesday, April 26, 2017


Referred Link -

7-S for Project Management

When it comes to project management things can move really quickly, and sometimes that means things get out of hand. When you’ve got a lot to do, ensuring that your project is aligned to your organisational goals becomes even more important – it’s too easy to let slip that strategic alignment that we have heard so much about in the project management press over the past year or so.
Staying on top of everything and staying aligned to the organisational goals is easier with the tools and techniques to help you.
This is where project management methodologies, models, techniques and task management software by TaskQue comes into play. They streamline your tasks and keep you on track to achieve success.

The 7-S Framework

One of those models is the 7-S framework, a tool that helps you understand the complexities of your organisation.
Introduced by thinkers at McKinsey in the 1970s, it was a revolutionary way of thinking about how organisations worked. Previously the focus had been on hierarchy and the physical structure of a firm. The 7-S model focused more on coordination, through a connected web of factors that affect how an organisation is able to work and change.

7-S for Project Management

The 7-S framework wasn’t designed with project management particularly in mind, but it is useful in determining how aligned your project goals are with your organisational goals and what needs to be done to improve the correlation further.
The framework breaks down into – surprise! – 7 categories, split into hard and soft elements. Let’s look at those with a particular focus on how they relate to project management.

Hard Elements

The hard elements cover three factors, Strategy, Structure and Systems.
Hard elements are easier to identify, define and understand for project managers because these factors hugely influence your projects. Everything from formal processes, strategies, reporting, organisational charts and IT systems falls under this category.

1. Strategy

Setting project objectives is not enough to achieve success. You should have a plan and strategy about how to be successful and how to achieve your objectives.
The project plan and strategy should be well documented and communicated to all team members. The project strategy should focus on how to build and maintain a competitive advantage over the competitors. Strategy can change with changes in situation and external environments: most likely your project sponsor and project board will steer your work here.

2. Structure

This element relates to who will report to whom. Organisational charts for your project and other related resource documents fall inside the Structure element of the 7-S model. Irrespective of the scope of the implementation, it is important that you and your team members are clear about who reports to whom.

3. Systems

The System element reflects how the tasks will be completed and what process will be followed. It covers areas related to business operations and the business of running projects.
As a project manager, you probably spend a lot of time removing bottlenecks for your team to ensure they can fulfil their responsibilities and achieve better results. That’s all systems work.

Soft Elements

There are four Soft elements: Shared Values, Style, Staff and Skills. Soft elements are difficult to quantify and are heavily dependent on the organisational culture, making the much harder to put into practice successfully in a project environment.

4. Shared Values

Shared values are the first soft element that deals with organisational culture. It is the shared values that bind the project team together and foster cohesiveness and teamwork.
These characteristics runs deep down the organisation; companies never let go of them, no matter how grave the circumstances. Both the corporate culture and general work ethic also reflects shared values.

5. Style

This element relates to leadership style. The leadership style you adopt as a project manager will directly influence your team. It’s important that you select the style carefully [the situational leadership model will help here – Elizabeth] after assessing the situation to choose a response that will get the best out of the situation and the team members involved. Flex your leadership style as your project requires.

6. Staff

People are the most valuable assets of a company. Managing your staff efficiently and getting the best out of them is the core responsibility of a manager, and even project managers without line responsibility for their teams have a huge influence over the individuals involved in the project.
Get to know your team so that you can help them develop their skills and provide them with the opportunities where they can grow as a professional.
This will also help you in retaining your best talent and reducing the employee turnover rate.

7. Skills

Closely related to the previous point, the Skill element of the 7-S model focuses on the number of skills and levels of skills your team members have. Good project managers spend time with every individual to get to know them better and evaluate their skill levels.
That goes for you as well: project managers should invest in their own personal development through training programs, workshops, seminars and visits. In today’s dynamic and competitive world of project management, you should always look for opportunities to learn new things in order to compete with your competitors. Investing in development activities for yourself and your team can reap rewards in future and will help you in getting most out of your employees in the long run.

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.