Dealing with conflicting project requirements

Question

I tried to find an existing topic on this subject but I could not find one that was a good fit, my apologies if I was not thorough enough.

Basically we have a web application that serves multiple clients at multiple corporations (single code base - 'forked' where necessary to accommodate different needs).

This project is a fairly new one as we previously used to make a separate copy of the project per client and maintain it individually. However now that the company is growing, we are adding more staff and also attempting to minimize the code base and relying on configurations to accommodate different needs where possible, as opposed to 'forking'.

The problem I am dealing with now is that our customer relations lady (and it would appear 99% of the rest of the team) really does not understand that changing things on the fly constantly (without due consideration for the impact thereof or the conflicts that may arise) is not the right way about doing things. I mean this completely in the sense of conflicting requirements. We are pretty good at the rest (bugs, testing, scoping etc.)

For instance; Say client X, wants a particular button red but client Y, wants the same button blue (but has possibly requested this change years after X asked for it.) Currently we just make the button blue, until X asks for it to be red again.

This is happening more regularly as our user base is growing. Even worse is when two clients in the same company want conflicting changes.

I am really just a junior developer here, but I see this problem and no one seems to be too perturbed by it, despite my constant nagging. But lately these issues have been falling into MY lap and wasting MY time.

Could anyone please suggest a way that I can try and manage these (even if just for myself).

We currently use OTRS as a client facing ticketing system (for support and requests) and VSO (TFS) for internal tasks and bugs (sometimes created as part of an OTRS request).

I administer both systems, but currently trying to find when last a request came in from a particular client to change a particular button to a particular color in version control history or tickets/emails is just not a very comprehensive nor efficient solution (also the button/color analogy is a really simplified version).

I am just starting to feel like we are headed round in circles and are eventually just going to crash.

Answer 1

It sounds as if your problem isn't one of unclear requirements but instead of a missing role that you need on your team. What you need is a Product Owner.

Communication is a main function of the product owner. The ability to convey priorities and empathize with team members and stakeholders are vital to steer the project in the right direction. Product owners bridge the communication gap between the team and their stakeholders. As Figure 1 shows, they serve as a proxy stakeholder to the development team and as a project team representative to the overall stakeholder community.

Quoted from Wikipedia, sources: Pichler, Roman. Agile product management with Scrum : creating products that customers love. Upper Saddle River, NJ: Addison-Wesley, 2010.

In your case specifically where you have multiple clients as stakeholders each with competing and conflicting demands, the product owner acts as a proxy and steers software requirements to deliver maximum value to all clients. Consider the following user story from Client A:

As a [user] I need the Submit button on form A to be Blue, so that I can appease my need to see blue buttons.

Now client B has a conflicting requirement:

As a [user] I need the Submit button on form A to be Red, so that I can satisfy my hatred for the color blue.

The Product Owner listens to both stakeholder needs and decides:

As a [user] I need the Submit button color to be configurable to my needs, so that I can see my favorite color on form A.

For the development team you don't even need to know or care about the fact that Client A loves Blue and Client B despises Blue. Your product owner for all intents and purposes is the business for you.

You are very astute for a junior developer to realize how chaotic it can be to formulate a product for different customers without a product owner. This can cause a number of problems:

1. The need to fork for different customer needs.
2. Needing to fix bugs in many different places as each customer has a different codebase
3. The accumulation of technical debt which makes bug fixes and new feature development exponentially more expensive.

Why doesn't the business see the need for this then?

1. Sales doesn't necessarily care that developments job is harder and more prone to errors. Your team may be very good at putting in extra effort and being vigilant about dealing with technical debt making the problems harder for them to see.
2. Sales isn't necessarily promising customers an OOB (Out-of-Box) software. They may very well be more interested in providing custom development to their customers than building a product.

Point 2 has an interesting facet when you consider that many ISV's make the majority of their profits on specialty or niche markets with a handful of clients. This market might be more captive so software quality isn't as important. Also profits year after year are more likely to come from support contracts than any other source of income. The initial license purchase is just icing on the cake. Sales in this case is less likely to try to appeal to a broader market and more about managing relationships with the handful of important clients that they do have.

Answer 2

I agree with maple_shaft that you have a missing role but I don't agree on the same role. What you are missing is the program technical lead (or whatever title you want to call them). Assuming each client is considered a separate project then the program technical lead is responsible for knowing what's going on with all the various projects.

One of the technical lead's responsibilities is to ensure that the various projects don't step on each other. Thus, all changes should be done on a forked branch which can't get merged into the main branch until the impacts on other projects is assessed, rectified and approved by the technical lead.

Of course that won't work if the technical lead doesn't have the authority to get the other developers to redo their work because of its impacts and/or isn't vigilant in ensuring that the forks are merged into the main branch in a timely manner. If the attitude is constantly "we'll merge it later when we have time" then it can't work because you'll never have time and the codebase will have diverged far too much if you ever do get time. But, doing software effectively over the long term requires quite a bit of discipline. If you don't have that then there's no methodology that will help you.