Before continuing with this blog, I would suggest that if you have stumbled on this without having read the first part of this article that you do so by visiting the following link:

Value Management in SharePoint Part 1

SharePoint Value Management is primarily concerned with ensuring that the needs concerning a solution is clearly defined, and that those involved know what is going to be produced. The primary objective is to create a understanding, and a common one, that covers the design problem, identifies the design objectives, and gets a group consensus about various courses of action.

Before getting to grips with understanding the objectives, two points:

First, I said the word ‘solution’.

In the context of implementing a SharePoint service one may be thinking I am talking about developing and implementing a SharePoint solution -i.e. a custom farm solution. No, I am not talking about the details of taking a solution created by a developer and deploying it to a farm. And no, I am not talking about a specific service application like say Search Services, Visio Services, User Profile etc. SharePoint solution in this guide describes what it means record the work necessary to get to architectonically design what the client requires. That requirement might end up as a business workflow; or it might end up as an implementation of Access Services; it might be part of the work in designing a SharePoint site for a department / division; it may even be the study into what features and components to be included in a new SharePoint farm. So this understanding and agreeing the business requirements reaching agreement and therefore includes the decisions made to agree what is going to be in the product, how and who is going to do what. Value management is key to this as it can be used within designing anything within the SharePoint platform which will deliver a service.

And before you think, “huh, this is a business process, there’s nothing for technical people here”. Wrong. Value Management is a journey of discovery where technical know-how meets business requirements; during which both have a full understanding on the abilities of the product to deliver the solution. It is applied to SharePoint workers from Administrators to Developers to Architects to Programme Managers.

By working with Value Management techniques in SharePoint, this will falsify a notion for both sides (the technical camp and business camp involved) that deploying SharePoint is perceived as ‘easy’, a click-done-finish project, that simply applying a quick design based at the start is enough.

So, a comment from one SharePoint admin was “Ya boo. That’s boring, why cant I just build the thing and think about it later?”

Who do you think he was representing? The user? Doesn’t sound like it.

When someone says ‘Hey, lets use SharePoint to solve our problem’, their ideas are often designed around pre-conceived solutions. For example, they may have seen the same solution carried out in another company. They may ‘assume’ that SharePoint has some component or feature that meets a business objective.

Whatever the reason, Value Management helps you challenge such preconceptions by questioning and testing the business objectives, and then distilling them into a list of key requirements that are independent of any solution – this means then SharePoint can be used to confirm whether these key requirements can be met.

Also, Value management is a key part of helping you determine a Return of Investment (ROI). If you recall, in the first part of this guide, I mentioned a question ‘What are we going to use SharePoint for’? Well, Value Management gives you that answer when applied to a specific solution that is going to be designed and delivered. It will inspire confidence that (a) the business understands and agrees the decisions made to deliver the solution and that (b) the technical requirements of the components being delivered by SharePoint can meet those requirements.

You should carry out this exercise near the start of an initial investigation stage. At the point where there is going to be a scoping-out of the project. As that stage you would also know who the key stakeholders are, and how soon the project needs to deliver.

The workshop will require the involvement of key individuals at an appropriate level of knowledge and authority. For example, in the design of a specific site the key users, SharePoint specialist. In the design of a new SharePoint farm the key sponsors, like the SharePoint Architect, key members of interfacing technical teams, project manager.

In each of these workshops it is strongly suggested that the use of a coach to facilitate is recommended. This will help ensure the participants stay focused on the key aspects and to challenge their conclusions.

To identify the key objectives of any SharePoint solutions means going through investigations. The best way I have experienced is to setup workshops and act as a kind of Project Facilitator. Interestingly, this works even better if there is a proper team identified. Anyway, that’s in another book of mine :p

When gathering requirements, making and agreeing on decisions, make sure that you state clearly what the objective is for the solution, and ensure that any ideas, suggestions, or points related to that key objective are captured as secondary and sub-objectives.

Secondary and sub-objectives are the key to working out the value of the solution; they give weightings, allows you to evaluate and assess the value of each.

By now, if you are reading this and thinking “hey I am a techie, a SharePoint Admin, what is all of this about objectives, secondary, sub-objectives and value – I don’t do any of those things in SharePoint”. I would argue that you are already doing that with your Sites and sub-sites – they are based on a topology, to the analogy you might want to think on is SharePoint site topology.

Like a site and sub-site, Each has a reason or a premise. The same thing goes with SharePoint objectives – to meet them you need to complete a number of secondary objectives. They are made up of sub-objectives. To explain this even further though, I’ll give you some examples of SharePoint objectives, each with a secondary objective.

• Build a SharePoint Farm which has good availability and good network performance.
  
• Build a Project Management site which has a Schedules management component.
  
• Build a Server Automation tool which needs to be audited.
  

These may seem rather nebulous, but, from the outset, SharePoint solutions start in that fashion – No-one is a SharePoint Seer.

Of course, ideas generated during meetings without facilitation can end up in a solution which has many pitfalls (cost / resiliency / compliance / storage / etc). Therefore, its very important that enough investigation has been done to define the system specification (more information about this is in my book!) that meets the objective/

Continuing with the theme of structuring the objectives, here’s some basic examples of primary objectives and sub-objectives:

As you can see from the above three examples, we have taken a key objective, and then, through discussion, agreed the secondary objectives and then decomposed them into sub-objectives hence:

By the way, Mind Manager is absolutely brilliant for brainstorming objectives in my SharePoint sessions.

Step 2 – Assign importance weightings

Ok, taking the previous example of a Project Management Site whose objective is to store content related to a particular project we could come up with something like this:

Even at this level, we need to be clear on what areas of the site get more attention than others. For example, Budget Overview may not be important there is another central site that is used record financial information – there may be a decision to connect and provide that detail without duplicity to this site. Project Plans may be multiple project plans, and may even require their own sites, and therefore be of critical importance.

We need to record these as decisions and apply value management to each, so we need to start adding weighting (relative importance) of each objective. Taking the above again, I’ve applied some weightings:

One thing you may have noticed is that Project Artifacts becomes a repository but is now more important than Budget Overview. Also, that all weightings when summed equals 1.0.

Applying weightings is a delicate matter sometimes requiring a strong application of SharePoint knowledge combined with business acumen. Some people will say hey this is a decision made using a business analyst. Not true, remember that some of the examples I gave are not in the bounds of a business analyst. Building a software solution may simply be a technical discussion requiring technical agreement. Building a SharePoint farm covers more than a vision from a client as that produces a system specification outcome. Whatever happens, when applying a weighting bare in mind that these are subject to change and that could be due to a one or more factors.

Now that weightings have been applied to all of the objectives and secondary objectives, you will need to calculate what is known as a “Utility” score.

Taking the example in Step 2, enter a code against each of the objectives. The first secondary objective is A, followed by B for the next secondary objective, C for the next and so on. For each of the sub-objectives start with the letter of the secondary objective followed by the number of that sub-objective. For example, is a secondary objective is C then the first sub-objective of that is C1. Take a look at the following and you’ll get a better understanding. You’ll need to do this to create the table to store the Utility Score and Assess Value.

 

Once done, turn the information into a table:

 

In the above table, CMS Product A seemed to fair good with Repositories but did not have all the features necessary especially against Objective A. SharePoint seems to cover the bases and achieves a higher utility score overall.

So how does this work? First, you need to enter the importance weighting values for each of the objectives. Then, for each objective, enter a value out of a 100 on whether the product going to be used can meet the objective. The higher the value, the better.

For the weighted score of each objective, multiply the importance weighting by the weighting score. Repeat this process for each of the objectives. Then finally, add up the score at the end to give a utility score. The higher the value the better the product fits the objectives.

In order to give this section the justice it deserves, make sure that you have the relevant knowledge resource – meaning, that you have someone who can give you objective advice concerning each of the products strengths and weaknesses against each of the objective. It is also extremely important that you show 100% honesty. If SharePoint does not meet an objective properly, it doesn’t.

Now onto Assessing Value. If you have followed all the steps so far, this section is a breeze. All you need to do is simply obtaining the present value (discounted) and whole life cost, a measure of the value can be derived:

 

In the above example, SharePoints life cost is 10 million, versus CMS Product A at 8 million, and Doc Mgmt Product B at 15 million. As we can see, SharePoint has the highest value.

The process of scoring and ranking is not always objective. You must assess the sensitivity of those scores which any in the decision making process feel intuitively are misleading. As these are assessed the results can be continually used as a basis for debate and discussion.

Be prepared to re-do steps 2 through to 4 as many times are possible so that before you agree on the final solution that all objectives have been addressed against all the possible alternatives.

Critical Success factors for Value Management are:

•  Senior management support and input – you need to make sure that at your workshops that decision makers are there to identify the priority of the objectives.
  
• Appropriate level of management so that the results are not undermined.
  
• Effective facilitation – make sure you have the right people to provide knowledge, ensure that you have a strong SharePoint specialist to answer queries and to help make decisions.
  
• Sufficient information available – when looking at the alternatives, make sure you have the right information available that allows you to understand how the product meets requirements.
  

End of this Article

Whew! Reached the end of this article. Hope you have enjoyed reading this second part of Value Management, in which we discussed what it is, and how you can apply it in identifying whether SharePoint can meet certain objectives and its value in doing so.

In the final article, we will look at Value Engineering – this is a very useful method in SharePoint in refining a selected solution to optimise its value for money.

Also, please note that this series of articles is all part of helping you get to grips with SharePoint implementation and is wrapped up in my book – Managing and Implementing SharePoint 2010 Projects, and can be used in any situation where you are thinking of building a solution in SharePoint but need to work out whether SharePoint can properly meet the objectives, and the value returned on going down a selected route.