Site Archive (Complete)
Architecture Blog: Architects and Project Managers: Part 3
Architecture & Design
PATTERN LANGUAGE

Modeling, Managing, Making it Right.

by Jonathan Erickson
IF YOU BUILD IT

... Will they Come?

by Arnon Rotem-Gal-Oz
April 06, 2007

Architects and Project Managers: Part 3

In the previous post on this subject, I looked at what an architect can do to avoid crossing the line between steering the project into the right technical direction and "destroying the developers' jot of creation and professionalism".

As Osiris commented, this only looked at the problem from the architect's perspective. This post looks at the situation from the PM perspective and answers the second question raised in Part 1 :

Assuming this PM is right, what's the best way to defuse the situation?

Granted, this question is a little bit off-topic for this blog (Architecture and Design) -- but not that far. In my experience as a manager, the best ways to deal with issues is to talk them out and the sooner the better. Wait too long and the architect and team will build enough antagonism to render future cooperation very problematic. Remember that developers have enough reasons as it is to circumvent the architecture, and as a PM (assuming the architect is good) it should be a priority for you that the architect be heard and the architecture that emerges (by the architect and the team -- but that's a topic for another post) will be followed. The best way to get there is cooperation.

To talk this out, I prefer to first try to approach alone the person I'm having conflict with. However, it sometimes might be better to have an impartial facilitator (mutual boss?). The interests of the architects and the program managers should be the success of the project (even if it the reasons behind it is justpersonal glorification). Try to focus on that and avoid making the conversation personal. I would probably start with asking the architects if everything is okay and do they see any problems with the team. If they don't, then try to present the problems you are seeing. And don't forget to listen and try to understand the interests and not just the positions.

Possible solutions in the particular conflict we are talking about is to try to steer the architect to a mentoring, rather than a command-and-control, position. This has several benefits. It will get the team and the architect to work closely and get better working relations. Assuming the architect is good, it can help make the developers better. Also it will help make the architects\ feel better about the team and give them more slack.

In any event, try to figure out your Best Alternative To a Negotiated Agreement (BANTA) and try to think if you can live with it. I personally think that good working relations between architect-PM-team are crucial to a success of a projectbut if things gets worse than your BANTA go with that instead.

Two recommended books on negotiations areGetting to Yes and Getting past No. In the next part I'll try to look at the the third question, which to me seems like the most interesting

How do you balance and divide the responsibilities between the project manager and the software architect?


Posted by Arnon Rotem-Gal-Oz at 05:23 PM  Permalink




 
INFO-LINK


Related Sites: DotNetJunkies, SD Expo, SqlJunkies