Reply to: Challenging the new HMRC guidance on SDC

[tomtomagain]

Everyone working for a customer of some sort would be subject to some level of SDC. If nothing else, the customer would expect delivery at some point, which could be viewed as an element of control.

That's not how the (unrealistic) HRMC scenario #1 reads.


https://www.gov.uk/hmrc-internal-man...manual/esm2057

Peter is not subject to SDC. The client ordered a website and gets his website at the end of the engagement.

Picking up on GB9's example of ordering the coffee. The coffee workers would not be subject by SDC from GB9. GB9 stated his requirements, they fulfilled them and handed him his coffee.

HOWEVER. If the Coffee shop worker was a contractor had had been told by his client ( the Coffee Shop ) that to make a tall-skinny-latte he must put it in a tall glass, put the milk in last, write the customers name on the front and say "Have a nice day". Then he would be caught by SDC.

So it looks like anyone working in a pure "customer-supplier" relationship is not subject to SDC but anyone who works within a team is under SDC ( or would have a difficult case arguing they were not ).

The question for me is : Does following a process ( also known as "How we do things around here" ) count as SDC?

For example if a project manager joins an organisation who have a PMO and defined project delivery practices which all PM's have to follow does that count as SDC?

[m0n1k3r]

Well if that is the criteria then everybody is caught.

By that definition everyone working in an organisation is subject to some level of SDC. Because that is what an organisation is - a collection of people, working together, following a common culture, practices & procedures, to achieve a common aim.

Otherwise a company would just be a bunch of people who turned up at the same place each day.

Everyone working for a customer of some sort would be subject to some level of SDC. If nothing else, the customer would expect delivery at some point, which could be viewed as an element of control.

[GB9]

Of course some of my points are daft. Not claiming to be perfect.

I am though trying to use an "extreme" positions to try and understand the case.

If I hired an Oracle DEV, then no, I wouldn't tell them to use SSIS.

But I have hired C# Devs and picked up on them using some "non-standard" OSS libraries which conflicted with the current design of the applications and skill-sets of the rest of the team. Shock, horror - sometimes for no other reason than "I wanted to learn something new".

Often there is a case for introducing a new technology but introducing a new technology into an app or team is something I would expect most organisations to keep control over.



Now that's an interesting point.

I remember back in late 1990's when it was all about adding "Deliverables" to the contracts. Previously a lot of them had been very lose, didn't define much except day rate and working times.

So is the answer to SDC more detail in the contracts? For example, not just verbiage around the end-deliverable but also around adhering to the existing corporate processes?

In other words : If SDC is implemented within an organisation as a set of well-defined procedures is that "good" as far as HMRC is concerned ( "Peter the IT consultant was left to his own devices to follow the corporate standards" )

As opposed to SDC being implemented by a "physical" manager?



Funny. I had the opposite experience. The bigger the team the more harmonisation is required.

Is there a difference between "working the same way" and "following the same processes"?

Firstly, apologies. Your posts deserve a proper reply but I'm on a mobile and haven't the time to attempt it now. I will try later.

What does seem to crop up a lot is the difference between requirements and control. From memory HMRC's website example is useful. Something about the supplier having no say in the website design meaning no control. This appears as if HMRC are trying to imply requirements equal control, knowing full well that all clients have requirements. The control aspect is in how they are met.

Example: this morning I went into the coffee shop and asked for a 3 shot, tall, skinny latte. A few minutes later that's what I got. I don't believe that at any time I had any control over the staff.

The way I am reading HMRC's example, by stating what I wanted I would be exercising control. The coffee equivalent of their example would be to ask for a random coffee and see what I got!

[tomtomagain]

Firstly, some of your points are a bit daft. Can you imagine hiring a bunch of Oracle Devs and then saying 'BTW guys, we're using SSIS for this'?

Of course some of my points are daft. Not claiming to be perfect.

I am though trying to use an "extreme" positions to try and understand the case.

If I hired an Oracle DEV, then no, I wouldn't tell them to use SSIS.

But I have hired C# Devs and picked up on them using some "non-standard" OSS libraries which conflicted with the current design of the applications and skill-sets of the rest of the team. Shock, horror - sometimes for no other reason than "I wanted to learn something new".

Often there is a case for introducing a new technology but introducing a new technology into an app or team is something I would expect most organisations to keep control over.

Secondly, under current definition it's about how work is being done. E.g. working to a plan isn't control in itself.

Now that's an interesting point.

I remember back in late 1990's when it was all about adding "Deliverables" to the contracts. Previously a lot of them had been very lose, didn't define much except day rate and working times.

So is the answer to SDC more detail in the contracts? For example, not just verbiage around the end-deliverable but also around adhering to the existing corporate processes?

In other words : If SDC is implemented within an organisation as a set of well-defined procedures is that "good" as far as HMRC is concerned ( "Peter the IT consultant was left to his own devices to follow the corporate standards" )

As opposed to SDC being implemented by a "physical" manager?

And from experience, the bigger the team the harder it gets to make everyone work the same way which is one reason I wouldn't bother.

Funny. I had the opposite experience. The bigger the team the more harmonisation is required.

Is there a difference between "working the same way" and "following the same processes"?

[SimonMac]

Could it be that HMRC are trying to just simply scare people into going "inside" they drag their heals on any tax tribunals while they take the money from those who have succumbed to the FUD

[GB9]

Seriously? You had a team of 45 and everyone was allowed to work without supervision, direction or control? No common practices, shared architectures, code reviews, centralised bug-tracking,time-tracking, UAT processes, project plans or budgets.

No trying to learn lessons from past successes or failures. My reading of sceanrio 2 in the HMRC link I provided is that trying to pass on some shared learning would count as "Direction".

All of the above seem to point to SDC.

Scenario 2 is more realistic. Jacqueline ( although they portray her as a micro-manager ) set's Paul a task and then checks it once he's completed it. If it's not right ( doesn't pass the tests ) she can ask him to do it again.

But the key thing for me is this: It's entirely up to the hiring company to decide whether someone is under SDC and I really cannot imagine that many companies hiring 3rd parties would say:

"We hire 3rd parties, we do not supervise them, we do not direct them and we do not control them". That's just not realistic.

Imagine this : The project goes tits-up and when the budget holder says "Why have you spent all my money Mr IT Director and not delivered what we needed?" the hapless IT director replies "Well, we had this independent guy in but we didn't bother to supervise him and we didn't give him direction and we thought it would be better if we didn't enforce any control".

Firstly, some of your points are a bit daft. Can you imagine hiring a bunch of Oracle Devs and then saying 'BTW guys, we're using SSIS for this'?

Secondly, under current definition it's about how work is being done. E.g. working to a plan isn't control in itself.

And from experience, the bigger the team the harder it gets to make everyone work the same way which is one reason I wouldn't bother.

[jamesbrown]

I think are missing an essential detail here. If everyone has to adhere to the same requirement - for example, which software stack to use or which quality standards to meet - then there is no control in the sense of "you, Mr Contractor, will do it my way". The SDC test is (or should be) applied to the individual contractor's engagement; if he's doing the same as everyone else he is not being controlled individually. It's no different to HSE policies in that regard.

As for Supervision and Direction they are so nebulous that you can argue they don't exist, until someone takes a case and defines what is reasonable. For example, checking someone has actually delivered work on time compared to checking what time they came through the door when they went out. Both require supervision...

Agreed. At this stage, I think there are three things worth noting:

1. SDC is not concerned with what services are delivered, when, or where, but with how they are delivered. If the technology stack is part of the specification of the services to be delivered, it will come down to the degree of control exercised by the contractor in delivering within that remit.
2. The "SDC Test" is not based on strict deeming criteria, but a test in case law, which will look at the complete picture w/r to how the services are delivered. This will build on case law surrounding control, or a specific element thereof. Historically, it is the degree of control exercised that has mattered, i.e. whether, on balance, the level of autonomy afforded to a contractor makes them more analogous to an employee or an independent professional. The minimum degree of control for an employee-type relationship is a relatively high bar ("bound, hand and foot").
3. SDC is most definitely more restricted than the combination of RoS or MoO or D&C, but HMRC won't get their own way in defining SDC, as long as it remains a test built in (future) case law. In other words, everything you've read so far is presenting HMRC's side of the story. That is far from the end of it.

Bottom line, SDC is bound to catch more contractors than the current IR35 if it's ever extended to the private sector (many of whom will be wrongly designated as employees) but, if you can exercise a reasonable degree of autonomy over how the services are delivered, that should be sufficient. At the risk of flogging a dead horse, the crux of this is about who decides whether SDC applies upfront (because the vast majority of cases will never get to tribunal) and what implications that might have for demanding certain employee rights and benefits (i.e. whether the separation between tax law and employment law manages to persist).

[northernladuk]

Not everyone working as a contractor or freelancer is in IT plus IT roles evolve. So they cannot simply have traditional IT roles.

Hmm. Good point.

[SueEllen]

So would it be helpful for HMRC to categorise SDC e.g 1st line vs PM vs Service Manager etc. They can consider the SDC implications and predefine the SDC applied?

Not everyone working as a contractor or freelancer is in IT plus IT roles evolve. So they cannot simply have traditional IT roles.

[northernladuk]

I think are missing an essential detail here. If everyone has to adhere to the same requirement - for example, which software stack to use or which quality standards to meet - then there is no control in the sense of "you, Mr Contractor, will do it my way". The SDC test is (or should be) applied to the individual contractor's engagement; if he's doing the same as everyone else he is not being controlled individually. It's no different to HSE policies in that regard.

As for Supervision and Direction they are so nebulous that you can argue they don't exist, until someone takes a case and defines what is reasonable. For example, checking someone has actually delivered work on time compared to checking what time they came through the door when they went out. Both require supervision...

So would it be helpful for HMRC to categorise SDC e.g 1st line vs PM vs Service Manager etc. They can consider the SDC implications and predefine the SDC applied?

[malvolio]

I think are missing an essential detail here. If everyone has to adhere to the same requirement - for example, which software stack to use or which quality standards to meet - then there is no control in the sense of "you, Mr Contractor, will do it my way". The SDC test is (or should be) applied to the individual contractor's engagement; if he's doing the same as everyone else he is not being controlled individually. It's no different to HSE policies in that regard.

As for Supervision and Direction they are so nebulous that you can argue they don't exist, until someone takes a case and defines what is reasonable. For example, checking someone has actually delivered work on time compared to checking what time they came through the door when they went out. Both require supervision...

[tomtomagain]

Everyone has their own nuances. If the code passes test and the documentation is good then I don't care how they did it.

Seriously? You had a team of 45 and everyone was allowed to work without supervision, direction or control? No common practices, shared architectures, code reviews, centralised bug-tracking,time-tracking, UAT processes, project plans or budgets.

No trying to learn lessons from past successes or failures. My reading of sceanrio 2 in the HMRC link I provided is that trying to pass on some shared learning would count as "Direction".

All of the above seem to point to SDC.

Scenario 2 is more realistic. Jacqueline ( although they portray her as a micro-manager ) set's Paul a task and then checks it once he's completed it. If it's not right ( doesn't pass the tests ) she can ask him to do it again.

But the key thing for me is this: It's entirely up to the hiring company to decide whether someone is under SDC and I really cannot imagine that many companies hiring 3rd parties would say:

"We hire 3rd parties, we do not supervise them, we do not direct them and we do not control them". That's just not realistic.

Imagine this : The project goes tits-up and when the budget holder says "Why have you spent all my money Mr IT Director and not delivered what we needed?" the hapless IT director replies "Well, we had this independent guy in but we didn't bother to supervise him and we didn't give him direction and we thought it would be better if we didn't enforce any control".

[tomtomagain]

Here's some stuff from HRMC.

https://www.gov.uk/hmrc-internal-man...manual/esm2057

Anyone else think Scenario 1. Is completely unrealistic? A Company hires a 3rd party and agrees that he has complete control over what the "website" for that company will look like. Without any reviews or intervention allowed.

[GB9]

Does it matter how it was done? I'd say "Yes absolutely". You can achieve the "right result" but in the wrong way.

You can make the sale through bribery. You can get agreement through coercion.

Or a more mundane example you could ask a developer to build a site to do "X" and he could build it using a completely different technology stack to the one the rest of the organisation uses. That would be the right outcome, the wrong way.

Every client I have ever worked with has managed to get resource in that uses the correct stack. Oracle organisations tend to look for Oracle developers etc.

Everyone has their own nuances. If the code passes test and the documentation is good then I don't care how they did it.

[tomtomagain]

I tend to state the outcome I want and let people get on and do it how they want. As long as the outcome is acceptable what does it matter how it was done?

Does it matter how it was done? I'd say "Yes absolutely". You can achieve the "right result" but in the wrong way.

You can make the sale through bribery. You can get agreement through coercion.

Or a more mundane example you could ask a developer to build a site to do "X" and he could build it using a completely different technology stack to the one the rest of the organisation uses. That would be the right outcome, the wrong way.