The questions

How can we avoid ending up with contradicting requirements raised from the users? We'd appreciate process improvement suggestions that'd fit our limited resources.


I haven no idea if this question suits this Stack Exchange site. If not please delegate me to a better place.


We're basically two and a half IT guys working on a huge webssite. The website is what generates the companies revenue. Due to some limitations the company doesn't have the money to have a dedicated project manager.

So usually sales is more or less dictating what IT has to do which can't be blocked in every case, no matter how silly and work intensive a feature is in terms of time to invest and the benefit you gain from it. Which is already a flaw I'm aware of but which I'm not in the position to fix.

We're using Github to mangage issues and have a git branching strategy and continuous integration for automated testing and deployment in place. That part works nice.

We use the Github wiki to get somewhat of a software requirements specification done which is written by a person with no IT background but who knows how the business processes in this company work. He is no project manager nor got any background and experience in writing such documents.

The problem

We're very often ending up with situations in which we have contradicting requirements in our ticket descriptions. Also it seems that requirements change and effect previously done work in an unintended way, not technically but the workflow / business logic of the application.

For example I've got a ticket to implement image upload that has two constraints: 1) Profile type can or can't upload images 2) If it can upload, then the amount of images is limited depending on the type. So far so good you might think. But now, in a follow up ticket I've discovered that the requirements contradict with the previously designed constrains and that there is a third field and the use of the third field is now in question.

I would like to find a way to avoid ending up in situations like that every few weeks.

I've worked before in a bigger company but they had the same kind of trouble in larger projects. I'm a senior software developer, not a project manager and had to lead a small development team before. I can manage our development process and I'm happy with how things work in this area but I'm clearly not happy with our requirement gathering and the the contradicting requirements. I don't think the person who writes the requirements is doing that intentionally or is doing a bad job, it's just that he is not used to it. Also he is only four days a week available.

  • Hi Burzom, welcome to PMSE! Do you guys use any (even rudimentar) methodology to organize the workflow of tickets? Or you just work based on the priorities received by mail (as a lot of other projects do)?
    – Tiago Cardoso
    Commented Feb 27, 2017 at 12:00
  • We're fine with the workflow of the tickets itself. They're created, then reviewed and if it has flaws assigned back to the creator. Then back to the developer. The developer flags it as review and delegates it to a person for review. The ticket is then re-opened and goes back to the developer. But working with the tickets itself is not the issue, I think the problem we have is to keep the information (the specification) up to date and easy to lookup. Sometimes issues with conflicting requirements arise when you started working on the ticket and discover a conflict.
    – floriank
    Commented Feb 27, 2017 at 12:07
  • How the relationship between these tickets are kept? Is there any identification saying they're related?
    – Tiago Cardoso
    Commented Feb 27, 2017 at 14:35
  • Yes, but only if you refer to the other tickets via #<id>. See help.github.com/articles/autolinked-references-and-urls/… I've also requested that the Wiki pages that should contain the info and should kept up to date are linked, but they aren't always kept up to date. I think the problem is that nobody, even sales itself, and this has been proven, knows all possible weird edge cases they've made up.I begin to think that answering this question is not possible without spending a day in our company. It's probably just the lack of a dedicated PM.
    – floriank
    Commented Feb 27, 2017 at 14:56

2 Answers 2


You don't need a project manager to run this project. In fact, unless heavily empowered all a project manager is going to do is give the headache to someone else.

What you need is to have a "product owner" or "chief product owner" for the overall Web Site. A product owner's job is to the "final call" on requirements. This includes prioritization, clarification, dealing with conflicts and the like.

This owner should be someone who can make decisions or can work with the decision makers in a timely manner to make decisions. Based on a "standard" business structure I would say someone in marketing or an internal business function. The problem you are facing right now is every sales person is, quite understandably, focused on their individual client and their commissions. You need someone outside the commission process to handle the prioritization.

Barring this, you need to get the sales people together every couple of weeks and layout all the current requests. Note any conflicts upfront and then ask "We have two open slots to start new work, what do we work on next?" (This is pulled right from the first part of David Anderson's Kanban book).

Longer term I would recommend trying to setup a Kanban system for yourselves. Start with reading "The Phoenix Project". It's a fun and light read about how an IT org became the strategic heart of a company. Then go to "Kanban" as referenced above.

And as the other poster has mentioned, Acceptance Criteria are still very important. I'm just advocating some process above that for prioritization and conflict management.

Best of luck!

  • I share the same view - there's a lack of a product owner-ish person around.
    – Tiago Cardoso
    Commented Feb 27, 2017 at 17:38

Communicate + collaborate with the person writing the tickets

There's really nothing more to say than that.

Having a process that looks like this, someone writes the tickets perfectly -> developers interpret the tickets perfectly, is as asking for failure. You can't really make either of those happen, you just need to collaborate.

If the acceptance criteria are inconstant, get your the business person writing the tickets involved and talk it through. At this point, "...I've discovered that the requirements contradict ...use of the third field is now in question", what you need to do is talk it through and come up with a solution. If that person is regularly unavailable for some reason, that's a serious problem, and one that needs to be fixed rather than worked around.

You can't design process to avoid having to work together with business people. Although, you'll probably find the more you communicate, collaborate and share understanding, the better their initial specifications will get.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.