Welcome to the third and final part of my Value Management article concerning how to define and apply a model for solution architecture in SharePoint.

If you have just jumped into this article, without reading the first two I urge you to go back and read the first two articles – here are the links:

Value Management in SharePoint – Part 1 of 3

https://serviceautomation.online/managing-value-for-sharepoint-solutions/

Value Management in SharePoint – Part 2 of 3

https://serviceautomation.online/value-management-in-sharepoint-part-2-2/

In this final article, we’ll take a look at how Value Engineering methods can be used to help make decisions in crafting a SharePoint solution to the business.

Demonstrating HOW something will be achieved and WHY it is going to be achieved is one of the most compelling ways in which as a SharePoint specialist can convince the client to understand why a decision to apply a feature, component or set of processes will help solve a business requirement. Particularly, it will also show where it will save capital, improve ROI and act as a measurement to demonstrate where decisions have been successful (or even unsuccessful) in the long run.

What is the objective of Value Engineering in SharePoint

Value Engineering is all about how the decisions we make are based on meeting objectives and how they can be structured in a easily understood fashion.

Typically, the decisions we make to meet any SharePoint objective can be boiled down to a number of situations.

• The business requires SharePoint to meet a specific business objective which in turn will make their staff more productive in managing and creating content.
  
• The business has a large number of requirements using SharePoint, but it’s difficult to see the wood for the trees in determining what should be done first.
  
• The business has a clear set of requirements using SharePoint, but it’s difficult to see what feature will provide the best functionality.
  

For each of these scenarios, you could apply Value Engineering to help analyse, record and prioritise requirements.

The objective of Value Engineering is to refine a selected solution to optimise the value for money. This can be achieved by:

• Removing unnecessary functionality and cost
  
• Increasing functionality at no extra cost
  
• Maintaining functionality at lower cost
  

If you work in delivering SharePoint solutions, whether you are an analyst, administrator, architect or project/programme manager you will continually have to make decisions user experience, adoption, sustainability, availability and configuration management of the platform.

Value Engineering helps by providing a method to structure these decisions, to plant priorities and thereby determine which alternatives and solutions best optimises the decisions you take. As said earlier, the client gains from this since there is a historical, audited approach and knows that the cost (and benefits) associated with each solutions agreed upon can be measured.

FAST Value Engineering Methods

No, we are not talking about FAST search service functionality in SharePoint!

Within Value Management, a technique called the Functional Analysis Systems Technique (FAST) can be used to define the basic functions that are required for the deliverables from the project as a whole or from any part of the project. You start by stating what you are trying to achieve and then, by asking a series of “how” questions, you decompose this into increasingly specific statements of functionality.

This method can be used for virtually any objective where there is the requirement to advise how an objective will be achieved. For example, if the objective is to increase user adoption in SharePoint a method in how to achieve this would be to provide a Proof of Concept / Sandbox environment where users could try out SharePoint out of the box features and, if necessary any third party solutions. Value Engineering can be used to not only decide on that approach, but also what should be used to ensure that approach is a success, by drilling further into that proposal and optimising it.

Additionally, the technique can be used in reverse where you have been given a set of discreet functions. You list them and against each ask the question “why have this element”. You can then derive the relevant diagram, eventually arriving at the basic objective. This technique helps you identify and filter out un-necessary functionality.

An example of the technique used in reverse with SharePoint is when needing to decide which Service Applications to use in a new SharePoint farm, which needs to provide lean services to ensure the performance and availability of the environment. For example, in a SharePoint farm where one application server is used with limited infrastructure performance on that server, one would not enable every service application unless that service application was required (that is, it has a premise). So, if one of the basic objectives was to provide the business with the ability to create dashboards using Microsoft PerformancePoint then the objective would be to enable the relevant service. However, by doing this one would then need to decide on the level of infrastructure required (for example, positioning on another server to provide services, increasing infrastructure capacity RAM, CPU etc, all to ensure availability and maintain performance).

To help explain and to provide a method of helping you build a decision matrix, I’ve provided three basic scenarios below, which show (without going into too much detail) the process of mapping out through brainstorming the basic objectives into sub-objectives. The basic objective can also be called the solution; the sub objectives are known as elements.

Scenario 1

The objective is to deliver a SharePoint farm which is subject to high impact usage and a medium level user count.

   

Scenario 2

The objective is to deliver a RFP (Request for Proposal) SharePoint site for the company to manage business cases.

 

Scenario 3

The objective is to deliver a user profile enhancement to an existing SharePoint platform.

 

 

Identifying Possible Cost Savings

Once you have a defined solution, you will need to identify and assess the whole life cost of each element in that solution. You should consider each of the elements in turn, starting with those with the highest cost and hence, greatest opportunity to make savings.

This stage is important to proving to the client that the cost burden is commensurate with the solution they are happy with, and forms the basis for further projects which are related. For example, in creating a SharePoint farm the whole life cost can be used to define the next level costs for specific elements that may need to be created, assuming that the engineering of that SharePoint farm includes the features that project may adopt.

Let us consider this scenario:

You have been asked to provide a SharePoint farm which requires custom development. This will cost an extra 10k including annual support costs of 2k. It is assumed the lifetime of the SharePoint requirement will be reviewed in 3 years; therefore, the life cost of the custom development (one element in the solution) will be 12 * 3 = 36k. Other elements include the Proof of Concept SharePoint environment which will cost 20k plus licensing costs of 4k and which will not be expected to be required after 2 years. As an alternative you could build a SharePoint farm without the custom element, using internal features which will fall short of the full client requirement, but is expected to save 20k (albeit that there will be costs bourne by the business to use other alternatives to address the shortfall of not having the custom element).

With the above scenario, let us record the custom development and Proof of Concept elements and assign costs to these. When doing this, be mindful that drill further to understand what functionality needs to be in each element. For example, a Proof of Concept element does not just mean ‘slap a server and put SharePoint on it’, there’s more work than that considering that users may need to be trained (for example), you will have to source the server, use resources outside of your direct remit (networking, SQL, security etc.).

 

 

Continue adding the core elements to the table, once done, identify where you can optimise the solution by streamlining elements, by either re-prioritisation, identifying alternatives (for example custom development could be offset by using out-of-the-box features), reducing infrastructure costs by confirming the licences required (for example).

When ‘Value Engineering’ a proposed solution use the following pointers:

Significant Element Decision Making

• Understand the current proposed solution – no guesswork – analyse the solution and remember no-one is a SharePoint superman – get help!
  
• Brainstorm alternative approaches – with the client and other technical teams use their combined knowledge to find alternative solutions that can enhance the solution and without increasing cost (or if the cost is going to increase ensure you can justify it!). For example, if you are going to build a farm and have separated technical teams use the knowledge of those teams to build various approaches.
  
• Assess the most promising options and discard unworkable solutions – don’t fall into the trap of scope-creep, and don’t assume you get better value for money if you start adding more solutions the client will ‘like’ – stick to the proposal.
  
• Estimate the cost of any alternatives together with any pros and cons; for example, building physically separated farms may increase data integrity but also increase admin complexity and license costs.
  

Deciding Whether To

• Continue with the original proposal – SharePoint may be only limited by ones creativity but that doesn’t mean you force it to. For the proposals look to the bigger picture and think topology, structure, governance, support. Don’t be scared to indicate to the client that the proposal is untenable.
  
• Investigate one or more of the options further – as part of the decision process for the elements confirm the viability of the options. For example, if there is a need to build diagrams to show a business process and have that turned into a workflow in SharePoint there are at least four ways of doing this – Visio, SPD, Nintex, K2. However, for each there are further implications; some technical, some platform and each have different costs. At the same time, remember that you are not SharePoint superman and if one of the options does not fit discard it for the proposal; you can always pick up that discarded option for another proposal later.
  
• Adopt one of the alternative solutions –
  

Optimising the Solution

• Test any assumptions you have made
  
• Assess the implications of any relevant risks
  
• Consider delivery aspects
  
• Consider the quality criteria and testing
  
• Take account of corporate architectures – note this is not just technical they include system or process
  

Critical Success Factors

• Obtain input from all involved, don’t leave it to your technical team
  
• Ensure those participating have the authority to speak for their domains
  
• Use coaches in meetings; good facilitation pays dividends
  
• Have sufficient information to hand
  

End of this Article

In conclusion, Value Engineering is vitally important in aiding your decision making so that you can optimise the solution required and at the same time measure the cost and resources needed to deliver the solution.

As a SharePoint specialist, the key points to remember are:

• Check the proposed functionality is really needed
  
• Determine where the money is spent
  
• Identify alternative approaches for high cost aspects
  
• Test your assumptions
  

I hope these three articles have been useful and given you some insight into Value Management and Value Engineering in SharePoint. It has been an absolute pleasure writing this guide, and I’m sure there is so much more I can add – I’ll eventually turn it into a free e-book and add it for download.

To recap, there are three articles that make up this guide:

Value Management – Introduction

Value Management – The Process

Value Engineering – This Guide.

If you need further information, would like to comment or feel you have more information to offer, please feel free to contact me.

A great reference (if you are interested in the science of Value Engineering and F.A.S.T) is here: http://www.value-eng.org/pdf_docs/monographs/FAbasics.pdf