Project Management – Key Deliverables in a Software Development Project

A team is a set of people where each one may have his own purpose based on his own strong points and competencies. There is nothing wrong in a team where technical specialists and people who are oriented more to communication than to technical aspects work side by side.

Of course, it requires a good organization and a mutual respect. There is a risk that people with large technical background and a good knowledge of the codebase will use their codebase knowledge and their technical skills to consider themselves superior, smarter or whatsoever, and try to force everyone to agree with their decisions.

Some situations can make this risk higher. Examples:

• having one "guru" in a small team and constantly treating him as the best of the best. For example if a developer has an opinion, and the guru has another opinion, the wrong thing for the management (project manager, director, etc.) is to say: "he's a guru, so do what he says and shut up" (or, in a more polite form: "He has enough experience and he knows the codebase well, so trust him").

• having a separate team of technical specialists (is it actually the case in your company?), for the same reason: if you isolate a group of people and consider them publicly as the best of the best, they may start to neglect the opinions of people who are not part of the team.

As for your second question, you need to have enough background to lead a team of developers. Otherwise, not only you will fail to understand what are they doing, but they will also have a bad impression of being lead by an inexperienced person, and will avoid asking you for questions.

This being said, no, you don't have to be a technical specialist. It's a benefit, but if I have to choose between a person who has good communication skills but lacks some technical ones, and a guru who have no communication skills at all, I'll always choose the first one.

The main concern (I have a similar problem with my job) is that if "The Process" demands that you deliver certain artifacts at certain times, and no one is allowed to challenge the almighty "The Process", then if you try, you will loose! It's not just a simple matter of it being a better way (Which iterative doc development is).

So what you need to do is work within the process, but find a way to work the way you want to as well. For instance, does your process allow document modification once submitted? If not, then no iterative develpment is possible. If so, then you need to think about the cost of delivery (In terms of your time, your credibilty etc), and manage that cost. If, for instance, its a file copy and nothing more, then go for it. If (like me) it's a peer review, revision release, impacts dozens of people and costs thousands of dollars, then think carefully and make sure the new document really adds value.

A common way to work is a bare essentials, minimum document that meets the needs of "The Process" at the start, followed later by a final "as built" update that not only reflects reality, but has the details where needed, and is brief where the code speaks for itself.