Handling conflicting priorities and expectations in project development

Question

There are any number of situations in the standard day where priority conflicts exist for projects. Management wants maximum productivity from employees. Marketing wants maximum salability and fast turnaround. Ownership wants maximum profit. Customers want usability and low cost. Regardless of the origin of the demands, time and money are always the limiting factor in business.

Sometimes project elements have intrinsic or goodwill benefits for which there is not a hard, fast way to measure with monetary means (e.g. arguments for an attractive UI appeal vs. functional but plain). Other elements of software may have a method of providing “mental breaks” or motivating “cool factor” for developers that can get them back on track on other bigger, complex issues. While they may sidetrack the project short term they may have greater results long term through improved job satisfaction, etc. Continued training is a must, but working it in can setup back progress.

• What are your suggestions for setting priorities? How do you evaluate requests/demands on your projects?
• What are your suggestions for communicating and passing those on to your team in a way that they stay focused?

Answer 1

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)
• Human factors
• Environmental factors.

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

1. Legitimacy — indicating whether the claim is valid and claimant actually has a lawful interest in asking for something to get done.
2. Power — whether claimant has the authority and muscle to have the things done their way.
3. 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.

Answer 2

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.