How to approach a project given to new PM during execution with vague requirements?

Question

One of our PMs just got a new project that was on the execution phase with vague requirements. Because of these vague requirements, the Client have requested many changes, and the product development team have miss-interpret some of them as well.

Here are some of the facts:

• Project in execution phase
• requirement document is vague
• changes are limiting the progress
• Timeline cannot be changed, which means some requirements will not be met.

What is the standard real-life approach to get through this sour patch?

Answer 1

I have been in this position before. We worked with the client to put together a Specification Document, iterated over it several times, and once everyone agreed what was within scope and what was out of scope, the client signed it.

The main reason I keep documentation laying around is because it serves as a means to resolve disputes and remind all stakeholders of what the project requirements are.

In my situation, the client just plain forgot what he originally asked for. Reviewing the original requirements with him helped him realize his mistake, and we all agreed to go with the original requirements.

Had he insisted on the requirements changing, we would have charged a higher fee for the increased development and extended the original due date.

Project timeline and project features are two values in an equation that balance each other out. If more features are added, then the timeline must be increased or other features must be removed.

While you could make people work overtime or Make the Mistake of Adding More Resources to a Project Late, the chances of success are not great.

The best, real-life approach to getting through this sour patch is to be prepared by documenting requirements early. If it's too late to go back and do this, you can still salvage the project by communicating with the client, explaining that the requirements are vague, and calling a meeting to get updated requirements keeping in mind the balance between functionality and time to market.

Constant communication and being realistic about deadlines is your best asset at this point.

Answer 2

First, understand where you are. Do your homework: check how important is the project and the client for the organization. Learn key constrains: who has to be happy after all, how much decision-makers care, what are general project priorities within the company, how important is to make the thing profitable at first approach? Once you know it you can adjust the strategy to the situation.

• If the project and/or the client is important the focus should be set on making client happy with what they get, which probably means high flexibility in adjusting plans to the client all the way around, throwing in some extra effort from project team whenever requirements change and trying to keep the whole thing high-quality (as hard as this may sound). Basically get the team to run an extra mile. It shouldn't be hard to make everyone shine if you succeed.

• With top-priority project it should be relatively to get some support from decision-makers within the organization. Some compensation for extra effort, maybe an extra person or two for tasks which can be easily outsourced etc.

• If the project isn't that important and the company has rather good relationship with the client it's often pretty good strategy to talk this out. Describe the situation as it is and try to find a reasonable solution along with the client. Which features can be delivered later, how the process can be organized better so constant changes don't disrupt development process that much, how critical requirements can be hardened so the final product is compliant at least with them.

• If neither the project nor the client is important you may just accept you won't excel on this one and just do your best to organize the process in a reasonable way even though it won't end as a stunning success. Maybe that's cynic but it's not worth dying for the project no one really cares about.

• If you don't care much about the client or the client is notoriously bitchy about the formal agreement you can play the hard ball and use the same approach. If requirements can be interpreted, they can be interpreted both ways. It may as lose-lose, but well, sometimes it's better to end toxic relationship.

• In any case any tricks which makes the workload organized better and reduces how much changes affect everyday work of the people would be great. It doesn't have to be isolation, you can adjust the way the team works in a way which embraces changes so no one hates the client, and the PM, for throwing yet another change in.

Answer 3

1. Send it back to planning. Tell the client its not ready for production and that they'll save time, money and increase quality if they send it back to planning/requirements gathering. Or, if you can't send it back, at least take a 5 day break to knock-out some clear specs.
2. Deliver version 0.7 and let them iterate from there. Deliver a complete, working version based on what you know. Then let them work from there, but its off your plate and back in their lap.

Answer 4

Well Geo,

I'm not experienced on this business, I not even a PM (yet, I hope.. I'm working on that), but I have seen a similar situation before.

I would say this situation will be though and listing these facts above helps to understand and manage the problem (project).

At the similar situation, they had to re-write documentation and generate a correction (but this was on a specific software business were a fast correction was possible to be provided to customer).

First of all, customer needs to be aware that changes are limiting the progress.

Make a list of critical problems, sorting by the most urgent to the less urgent.

Make a list of the critical actions (or deliveries) to the development team (sorted like the list above). Focus the job at the most urgent action and after the completion, review the priorities and start it again.

Every time a action is done, check whether you can mark a problem (from the critical problem list) as solved. The actions will eliminate the problems, so focus on actions and the problems will disappear naturally.

Talk to the team and explain the situation. If possible offer a bonus to the completion of the job.

Overtime will be generated? Yes. Very important to have an engaged team.

Answer 5

all great answers. I think it's also important to remember that by stepping back in they project lifecycle to make sure the scope and requirements are clear and then replanning doesn't mean a delay of weeks. Often this retrofit of methodology can be done in a day or two.

I've taken over projects with these problems and done a quick review of the scope and requirements and status reports. If people are working away at project tasks and those tasks have little relation to the original purpose of the project, it's time to talk to the sponsor about what changed.