Simon is a hands-on software architect and a senior consultant at 
Mind the gap again
You need to pin responsibility on somebody
I did some technical consulting/due diligence on a large software development project recently where I'd been called in to look at how the project team was dealing with some of the non-functional requirements. I'm not sure exactly how large the project team was, but it was somewhere over 50 people and the project itself was subdivided into a number of smaller teams, where each team was responsible for looking after a small subsystem within the overall architecture.
The summary of my review was that very little thought has gone into the non-functional requirements and that retrospectively performing some non-functional testing *could* expose a whole host of problems that are expensive to fix. One of the reasons for the lack of work on the non-functional requirements is that each of the subsystem teams basically doesn't have an architect. Instead, they have a Technical Project Manager and a Technical Team Lead, with definitions as follows (I'm simplifying this a little).
- Technical Project Manager : a generalist rather than specialist, and somebody that has a technology background but doesn't necessarily understand technology in great detail.
- Technical Team Lead : depending on the team, this person is either similar to the Technical Project Manager but working at a lower level of detail, or it's the lead developer.
This sort of team/resource profile isn't actually that uncommon and I see many project teams that are organised in this way. In essence, teams get in a Technical Project Manager because they think people in this role can successfully undertake the project management *and* architecture roles on the project. Unfortunately, my experience suggests that this isn't always the most successful approach.
In I Need a Technical Project Manager, Johanna Rothman talks about the dynamics of taking on both the project management and architecture roles. Specifically, she says that one of the roles usually has to give way, and I agree. Coming back to the project I was reviewing, the basic problem was this - the Technical Project Managers didn't have enough experience of dealing with the architecture aspects (including NFRs). As for the Technical Team Leads, the same thing applies (their focus is generally at a lower level), but in addition they don't have the authority to make architectural decisions. Also, with both roles, it's hard to ascertain exactly who has the responsibility for something like the non-functional requirements.
I see this pattern crop up fairly regularly, and it's a variation of what I talk about in my Mind the gap essay, where key responsibilities fall down the gap between team members. The easiest way to fix this sort of problem is to be explicit about the roles/responsibilities when starting the project. And that means pinning those responsibilities on somebody.
