Powered by 3Roc
Technology delivery capability on demand. Configure the team a programme actually needs, find out what it costs while you are still deciding, and engage one partner accountable for delivering it.
No account needed to start building. You will need one to save a team or hold an estimate.
What are you buying?
The commercial model is the first choice rather than a field near the end, because it decides who carries which risk — and that is the part worth agreeing before anybody builds anything.
People, by the day.
You specify the roles, seniorities and skills, and direct the work yourself. 3Roc finds, supplies and manages the people, and replaces them when they need replacing.
Who carries the risk. You carry delivery risk. 3Roc carries the risk of supply.
A service, run to agreed levels.
You specify the scope, the hours of cover and the service levels. 3Roc decides what shape of team meets them and runs it as a service rather than as a set of individuals.
Who carries the risk. 3Roc carries the risk of meeting the service levels. You carry the risk of the scope changing.
A result.
You specify the outcome, the constraints and what must be true at the end. 3Roc proposes the team — which is why this route does not ask you for a role list.
Who carries the risk. 3Roc carries the delivery risk, including the risk that the work needs more people, different seniority or a skill nobody listed at the start.
Eight capability areas, and the roles inside each one are the roles 3Roc actually supplies. This is the range a team gets built from.
Designing, building and operating cloud platforms.
Server, storage and virtualisation estates, on premises and hosted.
Moving workloads, data and services from one platform to another.
Security architecture, engineering, operations and assurance.
First and second line support and the service management around it.
Microsoft 365, device management and collaboration.
Wide area, local area, wireless and network security.
Leading, planning and governing technology change.
Teams 3Roc already fields for recurring work, each with a stated composition and a reason for every role in it. Take one and change it, or build from nothing.
Programme Delivery
Stand up the leadership, planning and governance a technology programme needs to start well.
Currently covering Programme Delivery.
Four steps, and you can stop after any of them.
Step One
People, a service, or a result. This is the first question rather than the last, because it changes what is worth asking you next — and because specifying a team and a fixed price at the same time is the most reliable way an engagement goes wrong for both sides.
Step Two
Role by role, with seniority, quantity, duration, location and on-site days — or, for an outcome, the result and the constraints around it. Start from a Delivery Pod if one fits, and change it until it does.
Step Three
An indicative estimate, calculated by 3Roc against approved market benchmarks and 3Roc commercial policy, updating as the team changes. It comes with the assumptions it rests on, so it can be argued with.
Step Four
Commit the configuration and the estimate is held for thirty days, referenced and readable. Request a formal proposal when the business case is ready, and engage one accountable delivery partner rather than several suppliers.
Organisations that have already committed to delivering something, and now have to work out who is going to do it.
Winning work that needs more delivery capability than the bench currently holds, and needing the commercial shape of it before the bid goes in.
Assembling a delivery team across several technologies at once, under a programme that has already been sold and dated.
Standing up or scaling a managed service, where the cost of cover has to hold for the length of the contract.
Needing specialist capability — cloud, migration, cyber, networks — that there is no case for holding permanently.
Build a team, see the shape of it, and take the estimate and its assumptions into the conversation you were going to have anyway.