In brief, this is exactly why a PM cannot be replaced by a piece of software or methodology. Finding trade-offs between different constraints and matching them to opportunities or team abilities constitutes design and projects are designed in a way similar to software that comes on the other end. The scope and quality requirements will differ depending on the PM personality, knowledge, experience, influence, ability to negotiate and convey his or her vision especially in the software development world where few regulations or hard and fast rules exist. Moreover, project scoping is as much political as rational exercise.
That’s why project plan is an intellectual artefact reflecting individual perspective and project conceptual integrity always hangs on the shoulders of a few key individuals.
Usual inputs and tools used in the scoping process apart from specific requirements are:
Cost and benefits analysis and various financial measures indicating how profitable or prudent specific requirements are.
Organisational strategy what exists exactly for the purpose of showing direction and giving focus to the efforts.
Various regulations. Their role in software is a somewhat less prominent than in lets say construction. However, financial, entertainment, safety critical software are all subject to regulations.
Industry guidelines
Company Principles (Don’t be evil, Treating Customers Fairly etc)
Even department with the same name within different companies would usually have different amount of power to influence project requirements. This depends on organisational structure and PM needs to be aware of and understand such power configuration really well. For instance, some companies would have a very influential marketing and sales, in others finance would be mostly in charge of the direction. Political requirements can be dissected using a three-dimensional scale of
Legitimacy — indicating whether the claim is valid and claimant actually has a lawful interest in asking for something to get done.
Power — whether claimant has the authority and muscle to have the things done their way.
Urgency — indicating if the claimant actually has the need or attributes importance to their claim.
If would be very difficult to ignore requirements that have all three: legitimacy, power and urgency. However when looking at the repercussions of this division, most interesting are scenarios where one or two of the elements are missing:
Combination of urgency and power without the legitimacy results in some really bad heavily political requirements.
Urgency and legitimacy that lacks power will be looking at making a union or bringing a powerful player on their side to make sure the requirements are heard and acted upon. It might be better to make a deal before hand, since it’s likely to be on much more favourable terms.
Power and legitimacy are unlikely to pursue specific requirements until there is urgency. A PM has to be clever about deciding whether these requirements can be safely ignored or assigned a lower priority.
One mechanism (which has similarities to a mechanism described by Joel as being used at Fog Creek) is essentially an auction.
Start by getting everyone who should have a say together. This is likely to be one or two representatives from each of sales, development, support, marketing and so on.
Each of these representatives or teams is given a "budget" according to their say. The way the budget is divided up is unlikely to be even - Sales should probably have a far larger say as they represent the users, or the prospect of more money - but that's up to you. The only thing I'd suggest is that no-one team should have 50% or more of the budget.
Get all the possible changes in the next release on the table and describe them, their benefits and how long they'll take to develop so that everyone understands them. They should be broken down into similar size chunks as far as possible and no one chunk should take up 50% or more of the time available in the next release.
Now people get to spend their budget. Each team / individual divides their money up between the things they want to do. You can spend all of it on one thing or divide it between many.
Once that's done you work out what fits into the release, starting with the thing with the total most money against it, going down until you run out of time in the release.
You might then want to allow them to adjust their "bids" and repeat but generally you want no more than three rounds.
Why does this work?
Most importantly for me it taps into the knowledge people have about what's important and allows them to make choices based on that.
If the developers and / or support know that, say, refactoring the database is key to them, they can spend their whole budget on that (note: this is why no-one should have 50% or more of the budget and no single change should be more than 50% of the release - if you breach those then individual team's ability to say "this is really critical" falls away because they don't have the clout to make them happen even if they sacrifice everything else).
What you're not doing is forcing them to quantify the benefit in ways that don't really make sense to them, they just get to say "we know this is important and we back this up by saying to us it's more important than anything else and we'll sacrifice everything else (or a bunch of other things) to do it".
Similarly if sales absolutely must have that holographic interface they can do so but they will have to make sacrifices (in the form of having less money to bid for other things they believe will drive sales) to get it.
发布评论
评论（2）
简而言之，这正是 PM 不能被软件或方法取代的原因。在不同的约束之间找到权衡并将其与机会或团队能力相匹配就构成了设计，项目的设计方式类似于另一端的软件。范围和质量要求将根据 PM 的个性、知识、经验、影响力、谈判和传达其愿景的能力而有所不同，特别是在很少存在法规或硬性规则的软件开发领域。此外，项目范围界定与理性活动一样具有政治性。
这就是为什么项目计划是反映个人观点的智力成果，而项目概念的完整性始终落在少数关键人物的肩上。
除具体要求外，范围界定过程中使用的常用输入和工具包括：
即使不同公司内名称相同的部门通常也会拥有不同程度的影响项目需求的权力。这取决于组织结构，PM 需要很好地了解和理解这种权力配置。例如，一些公司将拥有非常有影响力的营销和销售，而在其他公司中，财务将主要负责方向。可以使用三维尺度来剖析政治要求
如果忽视同时具有合法性、权力和紧迫性这三项要求，那就很难了。然而，当考虑这种划分的影响时，最有趣的是缺少一两个要素的情况：
In brief, this is exactly why a PM cannot be replaced by a piece of software or methodology. Finding trade-offs between different constraints and matching them to opportunities or team abilities constitutes design and projects are designed in a way similar to software that comes on the other end. The scope and quality requirements will differ depending on the PM personality, knowledge, experience, influence, ability to negotiate and convey his or her vision especially in the software development world where few regulations or hard and fast rules exist. Moreover, project scoping is as much political as rational exercise.
That’s why project plan is an intellectual artefact reflecting individual perspective and project conceptual integrity always hangs on the shoulders of a few key individuals.
Usual inputs and tools used in the scoping process apart from specific requirements are:
Even department with the same name within different companies would usually have different amount of power to influence project requirements. This depends on organisational structure and PM needs to be aware of and understand such power configuration really well. For instance, some companies would have a very influential marketing and sales, in others finance would be mostly in charge of the direction. Political requirements can be dissected using a three-dimensional scale of
If would be very difficult to ignore requirements that have all three: legitimacy, power and urgency. However when looking at the repercussions of this division, most interesting are scenarios where one or two of the elements are missing:
一种机制（与 Joel 描述的 Fog Creek 使用的机制相似）本质上是拍卖。
首先让所有应该有发言权的人聚集在一起。这可能是来自销售、开发、支持、营销等部门的一到两名代表。
每个代表或团队都会根据自己的说法获得一份“预算”。预算的分配方式不太可能是均匀的——销售可能应该有更大的发言权，因为他们代表用户，或者获得更多资金的前景——但这取决于你。我唯一建议的是，任何团队都不应该拥有 50% 或更多的预算。
将下一个版本中所有可能的更改摆在桌面上，并描述它们、它们的好处以及开发所需的时间，以便每个人都理解它们。它们应尽可能分解为大小相似的块，并且任何一个块都不应占用下一版本中可用时间的 50% 或更多。
现在人们可以花他们的预算了。每个团队/个人将他们的钱分配给他们想做的事情。您可以将所有资金花在一件事情上，也可以将其分给多件事情。
一旦完成，您就可以找出适合该版本的内容，从总资金最多的项目开始，一直到您用完该版本的时间为止。
然后，您可能希望允许他们调整“出价”并重复，但通常您希望不超过三轮。
为什么这有效？
对我来说最重要的是，它利用了人们对重要事物的了解，并允许他们据此做出选择。
如果开发人员和/或支持人员知道，比如说，重构数据库对他们来说至关重要，他们可以将全部预算花在这上面（注意：这就是为什么没有人应该拥有 50% 或更多的预算，并且不能进行任何单一更改）应该超过发布的 50% - 如果你违反了这些规定，那么各个团队说“这真的很关键”的能力就会消失，因为他们没有足够的影响力来实现这些目标，即使他们牺牲了其他一切）。
你没有做的是强迫他们以对他们来说没有真正意义的方式量化收益，他们只是说“我们知道这很重要，我们通过对我们说这比任何事情都更重要来支持这一点否则，我们将牺牲其他一切（或一堆其他事情）来做到这一点”。
同样，如果销售绝对必须拥有全息界面，他们可以这样做，但他们必须做出牺牲（以更少的钱来竞标他们认为会推动销售的其他东西）来获得它。
One mechanism (which has similarities to a mechanism described by Joel as being used at Fog Creek) is essentially an auction.
Start by getting everyone who should have a say together. This is likely to be one or two representatives from each of sales, development, support, marketing and so on.
Each of these representatives or teams is given a "budget" according to their say. The way the budget is divided up is unlikely to be even - Sales should probably have a far larger say as they represent the users, or the prospect of more money - but that's up to you. The only thing I'd suggest is that no-one team should have 50% or more of the budget.
Get all the possible changes in the next release on the table and describe them, their benefits and how long they'll take to develop so that everyone understands them. They should be broken down into similar size chunks as far as possible and no one chunk should take up 50% or more of the time available in the next release.
Now people get to spend their budget. Each team / individual divides their money up between the things they want to do. You can spend all of it on one thing or divide it between many.
Once that's done you work out what fits into the release, starting with the thing with the total most money against it, going down until you run out of time in the release.
You might then want to allow them to adjust their "bids" and repeat but generally you want no more than three rounds.
Why does this work?
Most importantly for me it taps into the knowledge people have about what's important and allows them to make choices based on that.
If the developers and / or support know that, say, refactoring the database is key to them, they can spend their whole budget on that (note: this is why no-one should have 50% or more of the budget and no single change should be more than 50% of the release - if you breach those then individual team's ability to say "this is really critical" falls away because they don't have the clout to make them happen even if they sacrifice everything else).
What you're not doing is forcing them to quantify the benefit in ways that don't really make sense to them, they just get to say "we know this is important and we back this up by saying to us it's more important than anything else and we'll sacrifice everything else (or a bunch of other things) to do it".
Similarly if sales absolutely must have that holographic interface they can do so but they will have to make sacrifices (in the form of having less money to bid for other things they believe will drive sales) to get it.