Building a Solid Foundation for your New SharePoint Farm

Building a Solid Foundation for your New SharePoint Farm
SharePoint can be a powerful tool for any business. With on premises, Office 365 and hybrid options available, now is a great time to look into implementing this in your organisation. However, if you don’t start off on the right foot you can wind up in the all too common position of spending time and money on a system that your employees fail to see the value in. Here are 5 points to help avoid this:

Take the Time to Plan
The root cause of any failed or underwhelming SharePoint implementation generally stems from one place; a failure to take the necessary time to plan. This mistake is usually a result of budget limitations and time constraints. The focus is too often on getting SharePoint implemented as quickly and cheaply as possible. However, this approach will usually result in poor user adoption. This point is crucial as it greatly reduces the complexity of the following steps.

Don’t Deploy and Walk Away
With how easy a basic SharePoint install is now, there can be a temptation to take the out of the box setup and leave it at that. This is never a good idea. The business needs will change over time and require SharePoint to change with it. Even with a small, well planned solution, SharePoint will still require care and attention when given to the end user to ensure they can get the best of the features provided.

Start Small
SharePoint can be an extremely useful tool in many different ways. It can be used to help collaboration between team members, provide workflows for common tasks and processes, manage and control content and provide powerful Business Intelligence and Project Management tools. All of this can be customised to suit exactly what a business needs. However, all of these advantages can quickly cause headaches when not properly managed. Your focus in the beginning should be a solution that is small, simple and allows team members to see the benefit or the system. Don’t try to throw everything and the kitchen sink at them right away, expand after team members have a basic understanding and feel comfortable with it.

Poor training for a new system results in poor user adoption for that system. That is a fact. If the first experience a user has is one of confusion and there’s no clear reference to reduce this confusion, they will resent the system. They may be able to use the system, but not to its full potential. There are three main points to prevent this:
1. Organise small training sessions of no more than 15 people per session. Keep the sessions under two hours.
2. Create short videos for the main features of the site and share these with users.
3. Provide a digital manual and share this with the users.
This may seem like overkill but it allows users a choice of how they learn about the system, letting them choose the one they prefer and ultimately being more willing to accept the system.

SharePoint Team Leads
Having an enthusiastic member in each team to act as a power user in your SharePoint solution is a useful way to ensure your transition to SharePoint runs smoothly. Giving these users one to one training and having them act almost as administrators for the system will prevent frequent repeated questions to the IT department as well provide a certain amount of visibility into the system. With these users included in the process people will be more understanding if you run into issues implementing the system. Without this your users can quickly change from supportive to disinterested in the solution.
SharePoint is the ultimate example of getting back what you put in. Rushed setups will leave users with a negative image that you will struggle to recover from. But, through clear planning, a willingness to listen to your users and communicate with them effectively you can provide a very effective tool for your organisation.

For more information on SharePoint solutions and other services Aspira provide, you can contact a member on the team on:

Requirement Gathering – Overcoming Obstacles Along The Way

One of the crucial first stages of any project is the seeking out and to collect all-important business requirements. Establishing an entire set of needs at the beginning allows for superior planning, shorter delivery cycles, authentic estimates of project costs, along with
increased client satisfaction and the better adoption of the end product or service.

One of the main duties that a business analyst will perform is to successfully bridge the gap between the technical and business requirements. They are expected to fully comprehend the requirements of the company within the given context, then adjust these needs with the objectives and goals of the organisation. It is also essential that these results be communicated to either a development team, stakeholders or perhaps both.

In order to accomplish this successfully, the project requirements must be clearly and concisely written, in a way that is entirely comprehensible to both groups of people. It is expected that the business analyst, project manager or whoever is responsible for the analysis will have to deal with conflicting views and opinions from the stakeholders; there will frequently be challenges along the way to working out the exact plan and obtain a crystal clear picture of exact requirements.

1. Not defining the success criteria clearly
It is entirely natural for stakeholders to be aware that there are issues which need to be addressed, but not to fully comprehend what they require as a solution. One key element to help them to reach this point and address the issue is to break the project down into bitesize pieces. There are numerous collaboration modelling tools, which allow this – providing the clients with a high-level overview of the vision.
What is key, is to try to fully ascertain what they like, you can ask them to give you examples of products they prefer, and to elaborate on why they like them. Making the requirements fully quantifiable and conclusive.


2. Stakeholders may have a conflicting interest or priority
When introducing a new process, system or product, it is essential that it adheres to the requirements of multiple groups of stakeholders, these could be senior management, investors or even end users of the product. It is possible, and almost probable that these groups of people will have conflicting priorities or views on this. We have found one of the best ways to tackle this challenge, is to always have an assigned authority within the business. This is somebody who can take charge of the negotiations, and also who has the final say in making the decision. Without this person, it is often exceptionally challenging to resolve this type of conflict.
This part of gathering requirement is crucial, it ensures that any proposed terms are not out of scope, nor do they promote any individual agenda – as opposed to the overall company vision at the heart of the project.
3. Stakeholders who are over forceful or do not speak up
If you are dealing with this issue, rest assured – it is likely that it is nothing at all to do with your project. These issues are frequently experienced to be political issues within a business. People might even be afraid to get pinned down by expressing their views or solutions. Sometimes, the project may be of particular importance, and as such this will be driving everyone to want to be involved and have a say. Participation from stakeholders, along with active communication is a recipe for success when we look at the requirement gathering processes. Having these key people provide you with honest, open information will first mean you having to establish rapport and trust. Being well prepared for these meetings, listening whilst you are in them and learning from them will imply professionalism, interest and will also enable you to understand their challenges, which will enable to you focus on solving their issues.

4. Stakeholders may have a change of heart
From time to time, this can happen. It could be that the initial project requirements have not been entirely understood, or communicated, or perhaps, over the course of the project – they have evolved. Realistically, the only way you can approach this objective or challenge is to remain flexible and try to embrace the change. Any amendments will need to be correctly prioritised and there will most likely be new budgetary and timings which would need to be relayed and confirmed with the client before any modifications can take place.

5. Stakeholders insisting on a specific solution
This challenge will often surface when the stakeholders are limited with their technical knowledge in specific areas, if they had a particular technology in a past project work well for them, or perhaps, they are just unable to articulate in a concise manner what requirement they are needing to address. An ideal way to deal with this is to aim to divert their focus back to the definition of what the system should do. One way to do this would be to ask a question such as “if you were to have that system in place, which one of our problems would that specifically solve?”. Essentially it will be the technical team who work out how the system will do what it needs to, not the stakeholder.

For more information on Aspira’s Business Analysis services check out our website or contact us on

The Secret (?) Life of a Business Analyst

Back when I worked in a telecoms company, there were various well defined roles – system engineers, software developers, testers, support engineers and project managers. We never used the term ‘Business Analyst’. Later, when working for Aspira and dealing with lots of different industries, it was a role that I heard mentioned a lot, although I noticed that different organisations seemed to define the role differently.

Some organisations seemed to consider a Business Analyst to be a System Tester – someone who would be familiar with system requirements and carry out detailed testing against those requirements. More often, organisations suggested the main responsibility of the Business Analyst (or BA) was to define and document the requirements and then hand them over to the system developers. A few organisations used the BA role exclusively to carry out Business Process Analysis, identifying the “as is” process and defining the “to be” process as part of managing change projects. Some organisations seemed confused about BAs versus Project Managers often using the same people to fill both roles. In order to figure out how to join this secretive Business Analyst club, we first need to understand how to define the role.

At its simplest, the Business Analyst role is to elicit and define requirements, whether that solution is a technical system or a business process. This means pulling people together to figure out what the desired solution needs to do, so the ability to run workshops and organize people is important – a trait the BA shares with Project Managers. Once the BA has completed the requirements definition it proves really useful to have the BA then review the Testing Strategy. This ensures that the Test Cases will give the solution a comprehensive verification and validation prior to the solution ‘going live’.

So it’s easy to see why different organisations emphasise different aspects of the Business Analyst Role – it is a very wide ranging role. What I find interesting is that it is a role that has historically been under-resourced. When Aspira are asked to take over a troubled project and recover it, one common theme we see is that the project’s requirements have not been clearly defined. No project can ever deliver against requirements if nobody knows what those requirements are. I know that sounds obvious, but I bet you can think of some projects you’ve worked on (or are working on!) where there was no proper set of requirements.

What do I mean by “proper” requirements? There are seven criteria that need to be met before I am happy with a set of requirements:

“Some organisations seemed confused about BAs versus Project Managers often using the same people to fill both roles.”

The Secret Seven

Comprehensive: Requirements must be detailed. If you were building a house, would you agree on a specification that just states “a bungalow”? No – you would want to specify the size, the aspect, the number of bedrooms and bathrooms, the build quality, etc. etc.

Complete: Requirements must be all-encompassing, covering all aspects of the solution. This means including both the functional requirements (e.g. the use-cases) and the non-functional requirements (e.g. the level of performance required, the level of data security required).

Coherent: The Requirements must be understandable and make sense. Some people go on an ego-trip when defining requirements and use loads of technical jargon that may not be understood. It is important that the people who will be using the requirements to design and build a solution can understand those requirements.

Testable: A good requirement has to be testable, otherwise it shouldn’t qualify as a requirement. We have to be precise enough in our terminology that when a tester goes to write a test case, there should be no ambiguity. The system either does or does not meet the requirement – there is no ‘in between’, and this should make our tester very happy! Ambiguity exists when a requirement can be interpreted to mean different things. Multi-Billion dollar international space exploration projects have failed because of people specifying distance in numbers but no units. The French team assumed it meant metres, the USA team assumed feet. When I moved to Cork and asked if it was possible for an engineer to deliver a piece of functionality, I was told “I will, yeah”, so that was great… I thought. I have since learned that “I will, yeah” is Cork ‘slang’ for “No”. So be careful to define your requirements clearly and with zero ambiguity so that they can be tested.

Realistic: While I may yearn for world peace and to end world hunger, it is unlikely that my next project will achieve such lofty targets, so it would make no sense to state them as requirements of the project. Any requirements specified must be realistic achievable, not a fantasy wish-list.

Achievable: Part of the Project Manager’s job is to balance the project constraints of scope, cost, time and quality. The Business Analyst role is to define the scope into a set of detailed requirements. But that should not be done in a vacuum – the BA must check what the expectation is for the project schedule and budget, and aim to define a set of requirements that can be delivered in line with those constraints.

Non-conflicting: It’s easy to spot conflicting requirements for a small project – if you are told to meet “a tall, small, dark stranger” you will immediately seek clarification on whether the stranger is tall or small. But if you have a list of hundreds of requirements, or if you are passing on those requirements to a bunch of different people to implement, it is quite possible nobody will spot the conflict and will build a solution that doesn’t work. So it is up to the Business Analyst to ensure that the requirements are all in alignment and do not contradict each other.

“A good requirement has to be testable, otherwise it shouldn’t qualify as a requirement.”

Internationally Recognised Standard

Over the past few years, the role of the Business Analyst has become much better defined and standardised. An international body, called the International Institute of Business Analysis (IIBA®) has defined the Business Analysis Body of Knowledge (BABOK®). This is analogous to the PMI®s PMBOK® for Project Managers – a collection of best practices that have evolved over time. The IIBA® have established a set of certifications for Business Analysts, which require the candidate BA to have completed 3 days of approved training, have a certain number of years’ experience, and pass a multiple choice exam. Once this is complete, the candidate becomes a Certified Business Analyst, internationally recognised.

There are fewer certified BAs than there are PMs at the moment, but the rate of growth for BAs is far higher as the industry recognition of the value of qualified Business Analysts has grown considerably.

Aspira has invested heavily in building a range of Business Analysis services, from consultancy to help our clients create better requirements, to provision of BAs, to provision of the 3-day certified BA training courses, we offer wide range of BA services.

For technical Project Managers, we have found that attending the 3-day BA course is very useful. It provides the PM with a far deeper appreciation of the BA role and how to elicit requirements, and even if the PM is not interested in becoming a certified BA, the training will deliver 24 PDUs to help the PM retain his/her PMP®  certification.

If you are interested in talking to us on how to de-mystify the BA role, or for advice on the most suitable BA training, please contact us at

Mission Complete!


The Project Management Professional (PMP) is a registered mark of the Project Management Institute, Inc.

How to Estimate a Job for a Customer

The three-point estimation technique is simple yet can be very powerful when planning a project for a client. Aspira CEO, Pat Lucey, was asked by popular business planning website, to contribute a piece on estimating a project for a client.

Planning and estimating a project

When it comes to planning and evaluating a project, the three-point technique is much more efficient than wild guesswork. When planning a project, the estimation phase should happen early on, when there are a lot of unknowns and uncertainty is high.
A three-point estimate can give a good indication of the cost, duration, and effort that will be required, without tying anyone down to the last cent. For example, if I’m thinking of implementing a new CRM system, and come up with an early estimate that says it will cost somewhere between €20,000 and €50,000 – that may well be all the information I need if my budget is only €5,000. There is no reason to get the exact figure because I know I can’t afford to do the project.

“It is useful when estimating to get a few people involved, precisely so they will remember all the different aspects of the project and help build out a comprehensive estimate.”

How long is a piece of string?

When it comes to planning and evaluating a project, the three-point technique is much more efficient than wild guesswork. When planning a project, the estimation phase should happen early on, when there are a lot of unknowns and uncertainty is high.

A three-point estimate can give a good indication of the cost, duration, and effort that will be required, without tying anyone down to the last cent. For example, if I’m thinking of implementing a new CRM system, and come up with an early estimate that says it will cost somewhere between €20,000 and €50,000 – that may well be all the information I need if my budget is only €5,000. There is no reason to get the exact figure because I know I can’t afford to do the project.

Don’t forget all the elements of the job

Other things to note when estimating is that there is a tendency to forget ancillary activities. For example, it is very common for software developers to include the technical tasks, like defining the system requirements and the architecture and writing the software. They may even remember to include an estimate for the testing. But they will often forget to include the effort to deploy and support the system, to create any documentation required by the system users, to deliver training to those users, and the time needed to project manage the whole thing.

It is useful when estimating to get a few people involved, precisely so they will remember all the different aspects of the project and help build out a comprehensive estimate.

The final step is to effectively communicate your three-point estimate. Some clients will just want to see a single number, but it is more useful to walk a customer through the three-point estimate. It will help them appreciate that there are uncertainties and that perhaps they can make some decisions (or set constraints) that will contribute to reducing the effort and cost of the project. This allows the client to see a range of possible outcomes and lets them see the most uncertain – and therefore the riskiest – parts of the project.

The ‘three-point’ is a simple technique but one of the most powerful and efficient you can use. Try it out for yourself and watch the success rate of your projects soar. Article by Pat Lucey, CEO.
Original article available at

Kick-Starting a Project | Pat Lucey, CEO and Founder of Aspira

Getting started on a project is tough. Usually people are still busy focusing on other projects that are being delivered, or supporting projects that have just been delivered. For a new project there can be lots of uncertainty and people will tend to procrastinate in the hope that the uncertainty will resolve itself. It won’t.

The challenge is a by-product of the 80/20 rule, which is that 20% of the work takes 80% of the time. For projects, that 80% of the time can be taken up by delays in getting started and delays in getting finished. Of course, it is precisely at this early stage that you need the experts involved – the people who have the battle scars and are best placed to put a realistic set of estimates and a realistic plan together. But because those people are like Hen’s Tech (i.e. extremely rare) there can be pressure on the Project Manager to just get going and use whoever is available to build the plan. Are that approach generally means you are storing up trouble for later in the project. In Aspira, we developed the Project Kick-Start service as a way to accelerate through the ‘getting started’ phase.

Novel Project Tools

We found that by combining a streamlined process with novel use of project management tools, we are able to generate 3 months of progress on a project within 2 weeks duration. Aspira has achieved that degree of acceleration consistently, across different industries and across projects of different size.

The process centers around approx. 2 days of direct engagement with stakeholders. There will be a couple of hours with the project sponsor, a day with the project manager and then a day-long workshop which requires the project team (or relevant stakeholders if the team has not yet been formed). The workshop is focused on building out the project Work Breakdown Structure, with the goal being to define the breadth of the project. This is a hugely important activity as it forces the team to consider all aspects of the project. It often unearths elements of work that people didn’t realise would be required. In parallel with doing that, our consultants leverage the existing project team dynamics to identify a comprehensive set of dependencies, risks, assumptions, constraints and action items to populate the project logs.

One point to note here is the importance of having the right people and right degree of management commitment in the workshop. You cannot just pluck random people from the canteen and send them in. It has to be the right people, with the expertise to answer detailed questions and the influence to make decisions. The biggest commitment for an organization in running the Kick-Start process is that they will commit to freeing up the right people for that 1-day workshop, and that might be a challenge for organisations as certain people can be in demand across multiple projects.

Once we have identified all the work packages we investigate different ways of structuring the project to make it easier to manage – for example by group related work under the same work unit, and therefore minimizing delays and dependencies.

The next step is to use that data to automatically populate our estimation worksheet. This is a tool that uses the expertise of the team to come up with effort estimates for the work to be done, even when there is a high degree of uncertainty involved.

Finding Problems, Not Solutions

We finish up the 1 day workshop by carrying out a risk pre-mortem session. This is a technique where we use people’s creativity not to find solutions, but to find problems (I bet you don’t get asked for that very often!). In other words we get people thinking about what might go wrong. We find taking this approach will lead to a different type of risk getting identified early – the type of risk that people may voice in the canteen but not raise as part of a formal risk identification meeting.

At this point, the participants go home having emptied their brains. Our job is then to take all that data – the work packages, the estimates, the dependencies, the risks, and use them to create a high level schedule (MS Gantt chart) for the project, plus create a RAID log (Risks, Assumptions, Issues, Dependencies). There will be some to and fro with the project manager to get this right, and for smaller projects it might take 5 days rather than 2 weeks, but usually within two weeks we have a project charter, WBS, High Level Schedule and detailed RAID log. This gives the project great momentum, and puts the PM in a position where he/she can push the team to maintain that momentum.

Aspira then provide options to our clients. Sometimes we just stop after the Kick Start and the client PM just takes over. Other times, we provide an enterprise project planning service, where we take the high level schedule further and work alongside the PM to build out a detailed schedule, including resourcing, etc.

One of our clients likes to use the Project Kick-Start approach as a way to evaluate different project options. Rather than just kick off a project, they have us work with their team to complete a Kick start for 2 or 3 different approaches to implementing that project, and then they have lots of data to help them decide which approach is likely to be faster/cheaper/less risky.

Applies across Industry Segments

Hopefully this gives you an idea of how it all works. We have used it for projects in a host of different areas – Medical Devices, Software Development, Natural Resources, Construction, IT, Manufacturing, Financial Services, and we have found that it consistently delivers. I can never predict exactly how any one individual session will go – sometime we have projects that we expect to be straightforward but during the workshop a question is asked which turns everything on its head. Other times there are projects which seem to be full of unknowns, but just getting the right people in the room can bring clarity and structure.

There is an apt saying “A good start is half the battle”. By using Aspira’s Project Kick-Start service, you can make use of a proven technique to get a great start on your project. If you’d like a specific discussion about how this might apply to your project, please contact us at – our door is always open to you.