There’s a sense of security in knowing what’s mine and what’s yours. Not so much a sense of ownership (keep your hands off my stuff!), but a sense of responsibility. I know that I’m responsible for mowing my own yard, but not responsible for mowing yours. You know that you’re responsible for paying your electric bill, but not mine. These examples and ideas work pretty well for our home lives, but what about our work lives? What happens if we apply the same principles to our work in Requirements Engineering?

It’s easy to ride the train of thought from home to work. At work, I’m responsible for the SRS, but not for the database design. I’m responsible for documenting non-functional requirements, but not for user manuals. And I’m responsible for managing requirements change, but not for managing the project budget. Those “other tasks” belong to the DBA/DA, Technical Writer, and Project Manager, not me. Right?

To me, the answer depends on how you look at your project and your role within it. Many project teams (and most teams that I’ve worked on) have clearly defined roles, and those roles almost often are delineated by job title. A Database Architect does these things, a Requirements Engineer does these things, and a Project Manager does these things. Sometimes the responsibilities are further broken down within each role, so that a team of Requirements Engineers has an administrative lead, a toolset lead, a modeling lead, and so on. This type of division of labor is a good way to break down and structure the work that has to take place on a project.

However, I often see this “division of labor” approach misunderstand (or simply miss) the interconnected nature of our work. The DBA may specify the database platform and normalization rules for the system, which I may then use to help draft some of the non-functional requirements. I may create use cases, and the Technical Writer may use them as a starting point for her or his manuals. The Project Manager may specify the timeframe and budget for the project, which will then constrain the work options for the rest of the team. Our work is interconnected and interdependent. So why do we see our responsibilities as isolated?

I’ve often referred to the different groups within a project as fiefdoms (another term I’ve often heard used is “silos”). I prefer the term “fiefdom” because it carries with it a sense of feudal battles over property (my work vs. your work) and a sense of powerless subservience to the king (the project itself). It also conjures up images of filthy peasants toiling in the fields, an image I’m sure we can all empathize with at times, and a way of working that I’d prefer to avoid! fiefdoms, their strictly hierarchical organization, and the “this is mine, that’s yours” mentality they support, don’t belong in software development – they belong in history books.

So am I suggesting that we shouldn’t have clear delineations of responsibilities within a software development project, or that the RE (or the DBA, Technical Writer, Developer, or any other team member) is solely responsible for the project’s success or failure? Not at all – as I said earlier, a role-based division of labor is a great way to identify which people will do which work. Additionally, the project will most often succeed or fail as a whole, not because of an individual (although I’m sure exceptions do exist). What I am suggesting, though, is that we shouldn’t allow our assigned tasks to limit our responsibilities within and for the project as a whole. Each of us must remember that we are responsible to each other through the interconnectedness of our work and in that way we each carry an individual and a group responsibility for the overall success of the project. We each may not be able to do the work of our peers in other disciplines, but we can and should support them as best we can.

A team, and therefore a project, that is built from a sense of mutual support and responsibility will be more productive, more fun, and more able to adapt to the inevitable changes a project faces. So, leave the exclusionary responsibilities of fiefdoms in the historical muck and work to make your team more fun and successful through shared and supportive responsibility.