Dedicated teams

A dedicated team is a team put together for your project that works only on it for the term of the contract. It includes an analyst, who works with your staff to write down what the system should do and turns that into tasks. It includes developers, who build the system, and a tester, who checks every change before it reaches users. And it includes a lead, who plans the team's work, keeps track of deadlines and answers to you for the result.

We run the team: you set the goals and their order, and the lead turns them into a plan and assigns the tasks. Individual specialists who join your own team and report to your manager are a separate scope.

We record the scope as goals for each billing period and as a task list in your tool. The team works in short cycles and shows a working part of the system after each one. In every period the board receives a written report: what has been built, what is in progress, what the risks are and how much of the budget has been used. At the meeting with a board member, the lead shows the working system.

The team works in your systems, on accounts set up under your rules: with permissions limited to the project, a record of changes and access withdrawn at the end. The code, documentation, configurations and environments, meaning the servers on which the system runs and is tested, sit in your accounts from day one. The contract transfers to you the rights to everything that is created.

When a dedicated team, and when a fixed-scope project

A fixed-scope project is an order with a set scope, price and deadline that ends with acceptance of the finished system. It makes sense when the scope can be written down before the start and will not change along the way, and you want to know the price of the whole in advance. A dedicated team makes sense when the requirements will become clear along the way, when the order of work depends on the previous version, or when the project is a series of changes with no single end point. If the analysis shows that the scope is fixed, we propose a fixed-scope project.

We bill the team's working time per billing period, at the role rates set in the contract. The budget for each period is fixed and known in advance, and you decide the scope within it. Changes to the team's make-up or ending the cooperation follow the notice period set in the contract. What gets built: successive working parts of the system, documentation written as the work goes on, and a task list that shows what is left.

1. We agree the goal, the team and the rules. We write down what the system should change in the company, which roles are needed and who on your side makes decisions. Result: a contract with the team make-up, responsibilities, reporting schedule, and access and billing rules.
2. We start the team. You set up accounts for the team under your rules, and the analyst writes down the first tasks with your staff. Result: a plan for the first period and a working part of the system after the first cycle.
3. We work to a fixed rhythm. After each cycle we show what has been built, and you decide the order of further work. Result: successive parts of the system in use and a report for the board in every period.
4. We close and hand over. We check that the code, documentation and environments are in your accounts, withdraw access and name who runs the system from then on. Result: the system, and everything needed to run it, with you. Maintenance of the system by our team, or a wider transfer of knowledge to your staff, are separate scopes.