Who should have full visibility of all (non-data) requirements information?

Question

I work at a smallish mid-size company where requirements are sometimes nothing more than an email or brief meeting with a subject matter manager requiring some new feature.

Should a programmer working on a feature reasonably expect to have access to such "request emails" and other requirements information? Is it more appropriate for a "program manager" (PGM) to rewrite all requirements before sharing with programmers?

The company is not technology-centric and has between 50 and 250 employees. (fewer than 10 programmers in sum)

Our project management "software" consists of a "TODO.txt" checked into source control in "/doc/".

Note: This is nothing to do with "sensitive data access". Unless a particular subject matter manager's style of email correspondence is top secret.

Given the suggested duplicate, perhaps this could be a turf war, as the PGM would like to specify HOW. Whereas WHY is absent and WHAT is muddled by the time it gets through to the programmer(s)...

Basically. Should specification be transparent to programmers? Perhaps a history of requirements might exist. Shouldn't a programmer be able to see that history of reqs if/when they can tell something is hinky in the spec?

This isn't a question about organizing requirements. It is a question about WHO should have full VISIBILITY of requirements. I'd propose it should be ALL STAKEHOLDERS. Please point out where I'm wrong here.

Answer 1

Your question has a lot of layers to it which make a simple answer elusive. At first blush the answer seems obvious - of course all stakeholders should have visibility into the requirements. But what does that actually mean?

To answer this please let me summarize your question to make sure I understand the situation correctly. According to your description the process for gathering requirements from your customers is informal - requirements come in via various means including e-mails and action items that are the result of meetings with customers, and that you are not included in these email or meeting discussions. It also sounds like your customers may have various level of experience in writing requirements for software. You have a person in a program-management role who is attempting to mediate these requirements to you, and whose processes for managing those requirements are minimal at best. To complicate matters further, it sounds like you do not trust the mediation and translation of the requirements by your PGM. Information that you believe is essential to fulfilling requirements is missing (Why and What). I also suspect that you may feel like the PGM is over-specifying the HOW in the requirements which would impinge on the design authority of you and your team - after all - As Engineers the HOW should be largely left up to you, especially since you are the people who are going to be held accountable for failure. The net-result of all of this is that you want to be able to see the whole "chain of custody" or history of a requirement in order to defend yourself and your team against certainty of being held accountable for failure due to what was ultimately a badly conceived/written/managed requirement. Is this correct?

My first reaction after reading your question was to think - this is a situation where agile practices could really make a difference on your team.

For instance, one of the root problems seems to be a lack of trust between you and the GPM. In agile we try to value "Individuals and interactions" over "Processes and tools". Doing this is very hard when trust has broken down between team members - and it is very tempting to try to find a solution by modifying the processes which have led to loss of trust. The first step in reestablishing the trust is always open and honest communication. Have you discussed this problem with the GPM in terms the GPM can understand and accept? It's not an easy thing to explain to someone that the reason you want a process change is because you don't trust them or their judgement. But that is exactly what needs to be communicated. You may also be surprised by the underlying reasons that the GPM wants to over-specify the HOWS and not communicate the WHY and WHAT. Perhaps this conversation can lead to a mutually beneficial compromise? One avenue I would suggest is agreeing on a format/template for the requirements produced by the GPM - my personal favorite way to specify requirements is via user-stories... but what you call them, their format or even the level of detail is not as important as the agreement about what they must communicate. Also remember than unless your PGM is a complete sociopath that they are going to be motivated by many of the same things you are. No one wants to be part of a losing team, everyone wants to succeed at least at some level. Upfront recognition of this will make this discussion a lot easier for everyone.

My second reaction also involves one of the agile principals - Customer collaboration over contract negotiation. It sounds to me like this PGM has inserted themselves between you and the customer - which I believe is an error on both of your parts. The PGM should have nothing to fear by allowing you to interact with the customer directly - better communication with the customer will ALWAYS result in a better product. This is common sense. It may be that the PGM's instinct here is actually to actually protect you from randomization by the customer. This is a noble instinct - but it can sometimes be a problem if the PGM does not recognize a difference between structured interactions (such as during a product demo or a product-backlog grooming session) and randomization. Perhaps the PGM doesn't see a difference between seeking out the customer's opinion about the best way to execute a feature and allowing the customer to lobby you for new features or task priority directly? The answer here is the same as before - open and honest communication and an understanding and agreement between you the PGM of what aspects of communication with the customer each is responsible for. At the very least, I would ask to be included in any discussions about new requirements. This is a very reasonable request and should not be threatening to your PGM if they think about it. But it's success will also depend on you as much as the PGM. Remember that the engineers role in discussions with customer's is primarily one of listening - which also means asking a lot of questions. Try not to engage with the customers directly about the priority or value of a feature request in these meetings - that is the job of the PGM who should then advocate the customer's position in their negotiations with you about priorities and scheduling.

Another agile principal that can help here as that of "Deliver[ing] working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale". If you can get your PGM to schedule software delivery in small incremental units that would be best, especially if you can get a commitment that no changes to requirements will be accepted after that incremental unit of work has started (i.e. no changes to a sprint after it has started, using SCRUM phrasing). Again, open and honest communication is key here. You need to communicate clearly what you are committing to delivering in order for the PGM to reasonably trust that you will achieve that commitment. Then you need to prove that you met that commitment by demonstration or openly and constructively confront failure when it occurs.

Finally - and least - consider advocating for adoption one of the cannon of formal agile practice systems such as SCRUM. To be clear - I think that adoption of an agile strategy will solve most of your problems without any need to change any of your management tools at all if that is what you are your Peers are comfortable with. But I also think that the social and cooperative underpinnings of methodologies like SCRUM could also help out A LOT.

For instance - the roles and processes around requirements gathering and management are very well defined in SCRUM with a tremendous amount of support in both the Programmer community and in the PM community. Likewise issues around communication with the customer. This could be a strategic move as well if it turns out that your PGM is simply an irrational control-freak who hates customers and programmers and can't wait to leave every night so they can go torture kittens or something... Advocating a well understood and industry accepted solution will make it easier for you to bypass that person if that ultimately ends up being what is required. For more information about SCRUM, please see https://www.scrum.org/. Also, keep in mind that SCRUM is an agile process. What this means in practical terms is that you should not feel constrained by someone else's opinion of what SCRUM is - if it works for you and your team then that is good enough so feel free to experiment!

Answer 2

There must be a process of winnowing down customers' desires into what are the actual requirements. Someone has to separate the "nice to haves" from the "must haves", so the team knows what to implement and test.

But I would think that sharing the bigger picture would be helpful, because the devs might have insight that would make the functionality more relevant, more complete, more direct, or easier to implement.

And I would get awfully annoyed if expressed requirements surfaced after work had started or completed on the rewritten requirements.

Answer 3

Last minute changes kill projects regardless if you are talking software, construction, etc...

A Program Manager helps mitigate competing requests from different parties to determine based on priority, need or other criteria which of these requests get accommodated and how to resolve conflicts in requests. They generally declare what the next release should have. The person in the project manager role generally can take over from here.

The Project Manager will be responsible for organizing the appropriate resources and keeping track of the project so that the schedule is met. They will communicate the project status to stakeholders, and work with the program manager as well as the other stakeholders to mitigate project changes that are necessary.

If you don't have these two guys playing tackle for the software developers then they will inevitably be distracted from the goal of getting a software release out on time and on budget and with agreed upon features. It basically comes down to game theory, each business unit has important needs and some may be better or more important than others but when they compete for a developers time and attention on a software project then nobody wins.

The business needs to agree that while not a software or IT company that IT should be a partner in the business as a business unit in its own right, rather than a class of employees like Janitors or Secretaries, or like a cost center that is to serve IT as McDonalds serves hamburgers made to order and immediately. Once this realization occurs by management then a program manager for the software can truly be appointed to make sure that an acceptable outcome to all business units can occur with a much lower risk to the project in general.

Frame the argument in this way to the business in a post-mortem for your next project, "We can let each business unit fight for exactly what they want and have high risk that the project will fail, or we can ensure that an acceptable outcome can be met across the board that has low risk."