On 27th June we delivered a CPD event for the Law Society of Northern Ireland. The below article is a summary of the session delivered on the day and will cover:
- Why is procurement so important?
- Why do projects fail?
- Types of procurement
- How to approach procurement
- Running the process
- Contracting
Why is Procurement so Important?
It may sound very simplistic but in our experience IT projects tend to fail for one of two reasons:-
1. The selection of technology went wrong and the firm purchases either a solution which did not deliver the functionality required or engaged a partner who didn’t match their expectations of service delivery.
2. The implementation or use of technology fails as the leaders of the project did not engage deeply enough with the firm to undertake the necessary change management and adoption.
Why do Projects Happen?
Before embarking on an IT purchase, it is important to understand the motivation behind the decision to invest, as motivation will have a significant impact on the firm’s approach and behaviour during the selection process.
For example, if a firm becomes frustrated with one solution or vendor, they are more likely to be persuaded by a competitor’s cold call and look to move to that product without considering that the challenges with the current solution could be replicated in this new shiny offering.
We would suggest there are five major forces which drive a firm to make IT purchases:
Why Do Projects Fail
As mentioned earlier, one of the key reasons IT projects fail is due a poor procurement exercise. There are three primary reasons why projects get off on the wrong footing:
The Project Lifecycle
It is often the case that people in law firms who are responsible for making IT purchase decisions are busy legal professionals who are under pressure from disgruntled colleagues who just want better/easier/quicker IT solutions.
This situation can lead to what we call the “cycle of despair” and sadly a lot of projects end in disappointment, or with original aims underdelivered
Silver Bullet Optimism
Given that Lawyers are typical cautious decision makers, it is surprising that this is not always the case in technology projects and very often technology starts as the “silver bullet” to solve all problems and ends up being the biggest problem of all.
Selection processes can become “sales presentations” rather than well thought through selections, resulting in the wrong product or a bad product, including the spectre of “Vapourware”. As a result, law tech procurement projects are often derailed due to:
- Over optimism that IT will solve business problems.
- Assumptions on how systems will operate or integrate into the environment.
- Expectations on vendor delivery, product performance and staff acceptance.
- Loss of business focus so that the selection is focused on what technology can do rather than what the business needs.
- Lack of detailed requirements leading to misunderstandings between vendor and client and product capabilities vs business needs.
- Lack of planning leading to project delays, resources and people not available at the correct time.
Knowledge
One of the hardest elements that firms face is their lack of knowledge relating to the purchase they are going to make. This could manifest itself in lack of:
- detailed understanding of business requirements.
- what solutions are available in the market.
- what other firms are doing to address the challenge.
- the reputation of the suppliers and how they manage their client relationships.
- the “Ecosystem” of the solutions.
- why other firms are not taking some options which are available.
It is often the case that firms make their decision based on seeing a couple of marketing campaigns or demos rather than having the fuller knowledge required to make a balanced and informed decision.
Types of Procurement
The approach taken in the procurement exercise also varies widely depending on what you are purchasing.
Physical devices (PCs / Laptops etc) these tend to be commodity purchases where there are several options available and price or personal preference (e.g. Mac vs Windows) tend to be major drivers in the decision.
Virtual Services (e.g. Software as a Service) the decision is much more likely to be around risk and exit points – how confident are we that our data will be secure and how do we get our data should the worse happen.
Professional Services (e.g. consultancy services or hands on technology configuration) is much more likely to be a decision based on trust, ethics and cultural fit – our human assessments of whether we want to do business with individuals and how can we trust the individuals to deliver the services they are proposing.
Factors of Influence
When undertaking a procurement exercise the firm faces three main factors of influence:
- Reason for Purchase.
- Nature of Purchase.
- Value to the Firm.
Value to firm isn’t just financial, this is an assessment on:
- How the purchase underpins the business strategy.
- Impact of not making the investment.
- The value the investment will bring to firm performance / efficacies.
- Risk of not doing / risk of doing.
- Cost of investment / potential returns.
Pressure on Decision Making
Given these challenges it is also useful to think about the human element of procurement exercises and the pressures those making the decision are under.
Ultimately, they will feel responsible to the firm and users of the system but will need to deal with pressures such as pushy salespeople, limitations of market options, expectations (often unrealistic) of project stakeholders.
How to approach procurement
Getting the right match for you is about putting your needs/hopes and aspirations front and centre. Just like a personal relationship selecting technology must work for both parties. It is essential that:
- Technology projects support business objectives.
- Key success criteria is defined before selection.
- Deliverables are clearly communicated.
- Expectations are understood and met or managed.
Practical experience of the purchase process
Tackle the hunters before the farmers
Dealing with vendor sales teams is part of the process, but with a bit of awareness and preparation you can get the most from this phase:-
Start your due diligence before speaking to Sales.
There is no point in including a supplier in a tender if, during the process, it is clear that they are too small, too unstable, have a bad reputation for service, etc.
As consultants we can have a good idea of what’s happening in the market. If you are managing the process yourself, it might be a case of doing a bit of googling, perhaps look at the vendors web site for testimonials and send someone at the referenceable firm a message on LinkedIn to see if they would be prepared to have a quick call.
Speak to someone at a senior level directly, bypassing the sales team, let them know that you are considering including them in a tender and ask a few direct questions about the size and nature of the business, the types of clients that they have, etc. Find out if they are a ‘fit’ for you.
Company checks at this stage are always helpful.
Sales patter does not always equate to the product or service you will get – make a note of all discussions, even note the features that it would seem obvious for the product to have.
Be wary of the previews of new features. These can often be ‘wire frames’ of features that may or may not materialise, and most feature development takes much longer than the timelines initially discussed.
To avoid implications of over enthusiastic sales:
- Be blunt with pushy sales people, let them know that you don’t appreciate their approach, and what approach would work for you.
- Stay focused on your list of requirements rather than their list of features, and repeat this list back to them frequently.
- Update your requirements list after sales discussions as this will form your complete list during the contract negotiation.
- Ideally, your requirements list would be added as an addendum to the contract, but that is very rare these days. However, if any of the verbal “promises” made during the sales cycle are significant influencers in your decision making, then it is reasonable to try to ensure they are detailed in the subsequent contract or sales order. If the supplier refuses to agree to this, then you can assume they have no intention of making the feature / promise a reality.
To Tender or Not to Tender
Cons
- Time consuming.
- Costly (Consultant’s time or your own).
- You aren’t always comparing like-for-like.
- In complex systems vendors can often “tick the box” that functionality is available, but it is easy to overlook how a system operates and if its functionality is efficient for the firm.
Pros
- Opens your eyes to the variety of solutions and their costs.
- Ensures that you gather like-for-like information (as far as is possible).
- Forces vendors to prove themselves through the process.
- Confirm their features and services against your requirements.
- Allows you to collate the information into a formal report.
It is rare for us to not to recommend going through any sort of tender process. You learn so much about the products available and what it is that really matters to your firm.
Note that there are a couple of options open when running a formal procurement process:-
‘Request For Tender’ (RFT) also known as ‘Invitation to Tender’ (ITT) process
A ‘Request For Tender’ (RFT) or ‘Invitation To Tender’ (ITT) process is where the process is based on a formal list of your requirements and vendors are required to match their product and services against this list (allowing options for them to expand on this by suggesting additional features or services). They are required to confirm how they would achieve each requirement e.g., in core product, by customisations, by development or 3rd party solution. A RFT process is best used when the firm has a clear vision for what they want to achieve and there are several viable options in the market. A good example of this is a purchase of a new car, there are several viable options, but which one achieves your particular needs – speed, comfort, number of seats, size of boot etc. The “winner” is the solution which matches the needs the best.
‘Request for Proposal’ (RFP)
A ‘Request for Proposal’ (RFP) is still based on your formal list of requirements but there might be a range of different solutions, or you aren’t sure what the best solution might be and therefore you are looking for suppliers to take a lead and put forward their recommendations. Often, different options can achieve the same desired outcome (e.g. hosting servers on site, in private cloud or public cloud are all viable options which would give you a server infrastructure). An RFP process therefore allows the vendor creativity to offer what they consider to be the best a solution (or solutions) to achieve your requirements list. A good example of an RFP process is where you want to build a new home, you have the requirements – kitchen, lounge, X bathrooms, Y bedrooms etc but you cannot draw and ask a couple of different architects to put forward some design concepts to help zone into the solution.
Managing the Process
Vendors |
Your Business |
|
|
Identifying Requirements
We would recommend that requirements are gathered and put into a formal RFT requirements document. At this stage we would then weight the requirements using the MoSCoW rating:
Typical Selection Process
Most vendors in the software market – even the big practice management vendors – will agree a proof of concept (trial period) provided there is a very clear process and agreed success criteria. It demonstrates several things:-
- They are committed to you as a customer.
- They are convinced that their product will do everything you need and are happy to put that to the test.
- They believe that you will get to grips with their product with minimal training, enough so that you can do some simple but relevant testing.
Importance of Cyber Security
This is obviously of key importance given the unprecedented rate of increase in cybercrime.
The best cyber defences are made up of layers – secure data, leveraged in a secure application, delivered in a secure desktop, using secure network access by user devices that have their own security applications on them. Even the smallest software or hardware project has a part to play in this layering.
Cloud products put more emphasis on this, so getting comprehensive security information as early as possible from the vendors is essential, such as location of data, encryption of data, access control such as MFA. A great product may fail on that one point.
There is a lot of advice on the ICO web site to help with this. They also recommend completing a Data Privacy Impact Assessment when you change the way that you process client data (i.e. moving from an on-site system into the cloud) and the ICO web site provides a template document.
It is also well worth going through Cyber Essentials, if you haven’t already. It is the basic recommended accreditation, but it can often highlight some critical issues that expose you to cybercrime. Your vendors should have higher levels of accreditation such as IS0 97001.
Contract negotiations
- Go back through requirements and notes from meetings to ensure all needs and expectations are covered in the contract.
- Put cyber security at the core and consider elements of support and how you are protected from accidental or malicious data breaches caused by the vendor’s employees.
- Consider how and where data will be backed up.
- Include any key requirements (preferably all) in the contract.
- Decide on handling of implementation fees – will these be paid up front, spread across a period (or the whole of the term) or payable at agreed milestones.
- Separate your legal review of the contact documents from your technical review – given the nature of law firms, the technical solution can often take a back seat to getting the contract terms in good order!
- Ensure that you have a Service Level Agreement (SLA) which clearly indicates how the vendor will handle issues on a priority basis. Be aware of the difference between expected response times and expected fix times – the fix time is the most important.
- What recompense do you have if they don’t meet their SLAs? Often ‘service credits’ are offered for missed SLAs, but what happens if this happens consistently and effectively becomes a material breach?
- Agree the account management structure and meeting frequency.
- Think about what will happen when you exit (whether that be at the end of the term or during the term due to issues). This is often not agreed up front and the exit becomes uncertain, unpredictable and often expensive!
Considerations : For Managed Services For Infrastructure
-
- Hours of support and what happens outside of those hours.
- On-site support – still needed for desktop issues.
- What software and hardware belongs to you –v- what belongs to the MSP (who is responsible for licensing, updates, upgrades, warranties, etc).
- Will they manage your 3rd parties
- Extra costs in the migration from 3rd parties – software vendors will often charge to move their software from one location to another.
- Provision of Backup and Disaster Recovery services.
- Cover Cyber Security in the agreement and ask them to confirm what is out of scope – you may then need to consider engaging with a security specialist to plug any gaps.
Supplier Risk & Compliance
We have a duty to consider our supplier and the supply chain
If the supplier’s agreement doesn’t cover everything below, then create your own agreement with them.
- Set out your expectations for:-
- Compliance with GDPR / Data Privacy regulations.
- Anti Bribery.
- Ethical practices – child labour, human trafficking, etc.
- IR35 (if consultancy services).
Whilst many firms will not meet the regulatory thresholds that require them to provide a formal statement, asking suppliers to provide confirmation that they and their suppliers adhere to regulations and ethical practices, ultimately protects your reputation.
© 2016 PricewaterhouseCoopers Singapore
Conclusions
We would recommend that you:-
- Develop a procedure which dictates your approach for purchases and how you decide which procurement process to follow (RTP or RFP).
- Regardless of the approach ensure all purchases are based on your requirements and wants over what solutions a supplier has to sell.
- Understand your firm’s motivations for embarking on the project and the pressures on those making the decisions.
- Seek to fill the “knowledge gap holes” before embarking on the procurement process.
- Ensure all requirements are captured and prioritised in an RTT document.
David Baskerville
07769 946883
Cathy Kirby
07388 027471
Latest Articles
Baskerville Drummond Updates – April 2024
Welcome to the latest edition of our newsletter, where we share some of our recent articles, training tips and case studies. In this issue, you will find: The pros & cons of standard and bespoke training The pain of going through Cyber Essentials Plus...
A discussion of all things AI – with Document Direct – Webinar | Thu 18 April
Save the date - Webinar A discussion of all things AI - with Document Direct - Thu 18 April @ 10.00During this webinar we will be discussing the impact of AI on the legal sector with our friends at Document Direct. We will start by defining what “AI” is and the...
Standardise or Bespoke
Have you ever attended a training session and thought “Why am I being taught something I don’t use?” or “I/my team does not work like this”. This is something that sits in the back of my mind when I am preparing for any training session. I want to make sure that...
Talk to us today
Get In Touch
