How to avoid recurring questions and contradictions about same or related problems?

Question

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.

Disclaimer

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

Background

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.

Answer 1

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!

Answer 2

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.