TL;DR
You have already decided, a priori, that team member C is the problem. This is based on information you have not provided in your post. As a result, this appears to be a false conclusion that papers over a process problem that you (as the project manager) are responsible for uncovering.
The Problem
Given a task X, developers A and B would each take about a day to do it. Developer C will take a full week.
And this is caused by...what? Difference in typing speeds? Perfectionism in C? Sloppy work from A and B? You have thoroughly failed to define a root cause, so I will define one for you.
This "performance gap" is not necessarily a performance gap. It is a communications gap where the project manager lacks understanding of the team members individually and the team's gestalt dynamics, and has failed to address underlying process issues.
The Solution
You need to inspect (and possibly adapt) your process. Until you thoroughly understand why members of your team are performing at different rates, you can't formulate a different approach. In short, you need to fix your communications problem with the team quickly, so that you understand all of the contributory factors to this disparity between your team members.
Once you understand why your team members are developing at different rates, you can adapt your process as you see fit. For example:
- You can fix whatever underlying process problem is causing this differential (e.g. skill deficits, poor specifications, poor communications, lack of time-boxing, or lack of product ownership, regardless of which team member is exhibiting the problems).
- You can acknowledge the problem, and take it into account in your scheduling. You can create aggregate estimates for the team that average out speed differences, or you can assign more realistic targets based on actual, historical values for the team or its members when updating your project plan. Either way, you must get away from assuming your desired targets are delivery guarantees, when clearly they aren't realistic based on your team's current overall output.
- You can replace team members that are under-performing. Whether this means replacing the slower developer, or replacing the two developers that are turning in faster (but potentially less-complete or less thoroughly-tested work) is entirely up to you. You need to base this decision on what the project and the organization value, and no one outside your organization can make that determination for you.
"Holding people accountable" for management targets is a common project smell for projects that will fail. It's much better to work with accurate estimates from the task performers, and to ensure that the schedule has accounted for as many variables in its processes as possible, including human variables. Always examine the root cause (or causes) of a process problem before assuming its a people problem. While people can sometimes be the real reason, more often than not it's the process or framework that is at fault. Your mileage will of course vary.