I have only ever seen it work once. It was a three or four month long project that was projected to run an extra two months over the original delivery date. The project got fast-tracked and things ended up getting back on track for the release.
...keep in mind though, that was only once. I've been on many more projects where the PM tried to use one of those two methods and they failed miserably and dragged the project out for months beyond already extended date.
It can work. But there's a price to be paid: lower quality (more bugs, less testing) and turnover of burned-out programmers.
And in many cases, a fast-tracked project will both fail to deliver on time and will still pay the full negative price, for the reasons stated in Mythical man-month.
Things I'd want to see before I thought it might be feasible:
1) Staff available with suitable skills and approach. By that I don't mean ".NET programmer", I mean detailed technical skills, business domain skills (so they understand the problem), personality fit and understand the tools and the approach (source control, methodology and so on). This can happen in large companies where there are common tools, standards and knowledge but you need to be sure that they're ticking pretty much all the boxes.
2) Tasks must be nicely divisible. The best situation is where there are whole modules, applications or tasks unstarted and you can put new people on that. It minimises upskilling, additional communication and so on. If you can't separate out what the new people will do you're likely to majorly disrupt the existing team.
3) The whole team must have bought into the approach. If the existing team don't agree that bringing people on board will be right they'll likely fight it and you're doomed.
4) You need to be sure you've addressed why it was running late in the first place. If it was just bad estimates then are you confident the new estimates are good? If it was scope creep have you got the scope and change control in hand now? If it was because the deadline moved, are you sure it won't move again?
If you can't tick all four of those off, it isn't going to work.
Crashing and Fast-Tracking are two very different things...
Fast Tracking is where you take something (tasks or work packages) out of sequence and do it early. This may because of hardware delivery lead times, availability of resources, risk or whatever. So you might do things in parallel where originally you had planned to do it sequentially. I've fast tracked a lot of projects.. and yes it works.
Crashing a project is different in that you typically throw more resources at a problem to get it done quicker... this can be tricky. If it's done as a crisis response it can be painful adding extra people as you are already under the pump. In some situations you just add more problems.
Another alternative to crashing is to reduce scope. This is not always possible, but it should be considered.
With fast tracking or crashing... the sooner you know when you need to make a schedule change the easier to manage. This is why early deadlines are so important, they indicate how the rest of the project will go.
Both of these project management techniques work well to maintain a schedule, but they should be used intelligently by judiciously analyzing the network diagram:
study the variance,
study lead and lags;
decide what suits to your project: ‘Crashing’ or ‘Fast-Tracking’.
There is a software management principle that says adding manpower to a late project makes it later.
That said, as long as the measures taken are sensible it should be ok. Don't expect too much of your staff and provide reasonable incentives and don't take short cuts. It won't make miracles happen but if you're practical and want to push things just that little bit faster it can definitely be done.
When people have a stake in the potential success of something it's amazing how much more effort they're willing to put in.
It depends on what you mean by "work". I don't think I've ever seen it make a way late project deliver on time, if that's what you are asking.
However, I have seen it make way late projects deliver only a bit late. From the fuzzy perspective of management, that might be called "working". I've also seen it significantly lower the customer-based pressure on the company. Some might also call that "working".
Of course the price is rather high. Employees burn out, develop health problems or big problems in their neglected personal lives, etc. All of that has large financial repurcussions to the company. So I doubt the company comes out ahead in the long run. Is that "working"?
发布评论
评论（7）
我只见过它工作过一次。这是一个为期三到四个月的项目，预计比原定交付日期多运行两个月。该项目进展很快，最终又回到了发布的正轨。
...不过请记住，那只是一次。我参与过很多项目，PM 尝试使用这两种方法中的一种，但他们惨遭失败，并将项目拖到了已经延期日期之后的几个月。
I have only ever seen it work once. It was a three or four month long project that was projected to run an extra two months over the original delivery date. The project got fast-tracked and things ended up getting back on track for the release.
...keep in mind though, that was only once. I've been on many more projects where the PM tried to use one of those two methods and they failed miserably and dragged the project out for months beyond already extended date.
它可以工作。但这是要付出代价的：较低的质量（更多的错误，更少的测试）和精疲力竭的程序员的流动。
在许多情况下，一个快速跟踪的项目既无法按时交付，而且仍将支付全额负价格，原因如神话人月中所述。
It can work. But there's a price to be paid: lower quality (more bugs, less testing) and turnover of burned-out programmers.
And in many cases, a fast-tracked project will both fail to deliver on time and will still pay the full negative price, for the reasons stated in Mythical man-month.
我见过它有效，但这不是常态。
在我认为这可能可行之前，我希望看到以下内容：
1）具有适当技能和方法的员工。我所说的并不是“.NET 程序员”，而是指详细的技术技能、业务领域技能（以便他们理解问题）、性格契合并理解工具和方法（源代码控制、方法论等）。这种情况可能发生在大公司中，那里有通用的工具、标准和知识，但您需要确保它们几乎满足所有要求。
2）任务必须能够很好地划分。最好的情况是整个模块、应用程序或任务尚未启动，您可以让新人员参与其中。它最大限度地减少了技能提升、额外的沟通等。如果您无法区分新员工将做什么，您可能会严重扰乱现有团队。
3）整个团队必须都接受这种方法。如果现有团队不同意让人员加入是正确的，他们可能会与之抗争，那么你就注定失败。
4）您需要确保首先解决了迟到的原因。如果这只是糟糕的估计，那么您是否有信心新的估计是好的？如果是范围蔓延，您现在掌握了范围和变更控制吗？如果是因为截止日期变了，你确定不会再变吗？
如果你不能把这四项都勾选掉，那就行不通。
I've seen it work but it's not the norm.
Things I'd want to see before I thought it might be feasible:
1) Staff available with suitable skills and approach. By that I don't mean ".NET programmer", I mean detailed technical skills, business domain skills (so they understand the problem), personality fit and understand the tools and the approach (source control, methodology and so on). This can happen in large companies where there are common tools, standards and knowledge but you need to be sure that they're ticking pretty much all the boxes.
2) Tasks must be nicely divisible. The best situation is where there are whole modules, applications or tasks unstarted and you can put new people on that. It minimises upskilling, additional communication and so on. If you can't separate out what the new people will do you're likely to majorly disrupt the existing team.
3) The whole team must have bought into the approach. If the existing team don't agree that bringing people on board will be right they'll likely fight it and you're doomed.
4) You need to be sure you've addressed why it was running late in the first place. If it was just bad estimates then are you confident the new estimates are good? If it was scope creep have you got the scope and change control in hand now? If it was because the deadline moved, are you sure it won't move again?
If you can't tick all four of those off, it isn't going to work.
崩溃和快速跟踪是两个截然不同的事情...
快速跟踪是指您不按顺序执行某件事（任务或工作包）并尽早完成。这可能是由于硬件交付周期、资源可用性、风险或其他原因。因此，您可能会并行执行原本计划按顺序执行的操作。我已经快速跟踪了很多项目......是的，它有效。
崩溃项目的不同之处在于，您通常会在问题上投入更多资源以更快地完成它......这可能很棘手。如果这是为了应对危机，那么增加额外的人员可能会很痛苦，因为你已经陷入困境。在某些情况下，您只是添加更多问题。
崩溃的另一种替代方法是缩小范围。这并不总是可能的，但应该考虑。
通过快速跟踪或崩溃......您越早知道何时需要更改时间表，管理起来就越容易。这就是为什么提前截止日期如此重要，它们表明了项目的其余部分将如何进行。
Crashing and Fast-Tracking are two very different things...
Fast Tracking is where you take something (tasks or work packages) out of sequence and do it early. This may because of hardware delivery lead times, availability of resources, risk or whatever. So you might do things in parallel where originally you had planned to do it sequentially. I've fast tracked a lot of projects.. and yes it works.
Crashing a project is different in that you typically throw more resources at a problem to get it done quicker... this can be tricky. If it's done as a crisis response it can be painful adding extra people as you are already under the pump. In some situations you just add more problems.
Another alternative to crashing is to reduce scope. This is not always possible, but it should be considered.
With fast tracking or crashing... the sooner you know when you need to make a schedule change the easier to manage. This is why early deadlines are so important, they indicate how the rest of the project will go.
这两种项目管理技术都可以很好地维持进度，但应通过明智地分析网络图来明智地使用它们：
Both of these project management techniques work well to maintain a schedule, but they should be used intelligently by judiciously analyzing the network diagram:
有一个软件管理原则说，向较晚的项目添加人力会使项目更晚。
也就是说，只要采取合理的措施就应该没问题。不要对员工期望过高，并提供合理的激励措施，不要走捷径。它不会让奇迹发生，但如果你很实际并且想把事情推得更快一点，那绝对可以做到。
当人们对某件事的潜在成功有利害关系时，他们愿意付出更多的努力是令人惊讶的。
There is a software management principle that says adding manpower to a late project makes it later.
That said, as long as the measures taken are sensible it should be ok. Don't expect too much of your staff and provide reasonable incentives and don't take short cuts. It won't make miracles happen but if you're practical and want to push things just that little bit faster it can definitely be done.
When people have a stake in the potential success of something it's amazing how much more effort they're willing to put in.
这取决于你所说的“工作”是什么意思。我想我从来没有见过它能够让迟到的项目按时交付，如果这就是你所要求的。
然而，我看到它让迟到的项目交付只是晚了一点。从管理的模糊角度来看，这或许可以称为“工作”。我还发现它显着降低了公司基于客户的压力。有些人也可能称之为“工作”。
当然价格也是比较高的。员工精疲力竭、出现健康问题或被忽视的个人生活出现大问题等。所有这些都会给公司带来巨大的财务影响。因此，我怀疑该公司从长远来看是否会领先。这就是“工作”吗？
It depends on what you mean by "work". I don't think I've ever seen it make a way late project deliver on time, if that's what you are asking.
However, I have seen it make way late projects deliver only a bit late. From the fuzzy perspective of management, that might be called "working". I've also seen it significantly lower the customer-based pressure on the company. Some might also call that "working".
Of course the price is rather high. Employees burn out, develop health problems or big problems in their neglected personal lives, etc. All of that has large financial repurcussions to the company. So I doubt the company comes out ahead in the long run. Is that "working"?