TL;DR

Every project sponsor will have more than one project expectation and expects all of them to be the number one priority. It is possible to negotiate sponsor expectations as a priority list. This is another post from the project management series. The post is based on a remarkable book written by Johanna Rothman, Manage It!

Almost all software testers experienced an overconstrained project. The project manager did not do the work and just push the decision down to software testers. You have to use a fixed process, dedicated software (for example, use Windows 10 for your development environment while rest is open source software), a fixed number of team members, fixed budget, low defects, and fixed delivery time. A lot of fixes.

But do not despair, it is possible to negotiate those fixes into the priority list.

First, you should take an initiative and make your own list of project constraints priority matrix. Assign to every constraint that you know of a priority number. Show it to the project sponsor. This is a good start.

If the creation of project constraints priority matrix fails at the project beginning, you still have the means to create that matrix. You can:

• Imagine The Future
• Use context-free questions to identify project drivers.

Imagine The Future

In this option, you tell to project sponsor a story from the future: you are a few weeks from the project end. Some features are missing, and there is still a high rate of reported defects on implemented features. In Johanna’s experience, there is a low probability that the sponsor would blame you for your incompetence (in that case, this is a trigger to leave that organization). The project sponsor will offer flexibility and prioritization for you. Do these two features and this set of defects in this particular order. If you need somebody particular for extra help, you can have it.

Context-Free Questions

Context-free questions are high-level questions that we use to find our from another person their implicit assumptions about the project [Gause, Weinberg]

By knowing these implicit assumptions, it is easier to determine project drivers. There are some rules:

• Do not use Why questions because those put another side in defensive mode
• Do not use How questions, because it is your job to answer how when you get enough info about the project
• Use What questions, because those questions reveal valuable information

You ask What questions about the product:

• success description
• desired results
• solved problems
• caused problems
• value

With priority matrix, context-free questions and look into the future story, you have a high chance to set project drivers, a cornerstone for a successful project!