.comment-link {margin-left:.6em;}

Thursday, January 26, 2006

 

More on Architects and Project Managers

An interesting debate ensued between James McGovern (JM in this post) and James Tarbell (JT) concerning the roles and interactions between architects and project managers. Time for my two cents on the topic, and I feel uniquely qualified to comment since I have functioned successfully in both roles for years. I also teach PM at a midwestern university and maintain a separate PM blog more focused on that topic.

JM's rant about project management leaves me perplexed. He states that:

"Fundamental project management and those who practice it should minimally know what the status of any project is, how much the project has slipped from either original schedule or features, what are the impediments to delivery and what can/should be dropped in order to increase efficiency."

but then goes on to say:

"What would happen if enterprise architects started asking IT executives if project managers should only be providing value to management at the expense of the team? In my own travels, I have banged my head into my cubicle everytime a PMI certified project manager who hasn't written a line of code in their lifetime walk up to me and state: "I need the following information or I can't get my job done!". when did information become more important that the target of the information itself?"

Beyond JM's bias that only coders can succeed as architects, the simple fact is that project managers need to collect the information requested in the second citation in order to satisfy the requirements of the first cite. If the PM doesn't or can't know where JM's at with respect to project deliverables, he can't assess where the project is at with any degree of certainty, and those results are part of what was expected of him by management.

Unfortunately for JM, he can't have it both ways and there always needs to be accountibility for one's efforts on projects to PMs and management. The promise of 'working software' some months out into the future with no interim accountibility doesn't fly with the folks who pay the bills. Project reporting functions are present in every mainstream PM methodology, including agile. If he feels that his efforts are better spent on other work, then he hurts his project and team by not cooperating with the PM effort rather than help it, because it appears to others that the process discipline doesn't apply to him for some reason. When I've seen similar behavior on past projects, it labeled that person a malcontent, not a maverick.

JM goes on elsewhere in the post:


"During the bad days of my own career, folks within IT were given more "important" tasks that somehow were rationalized to be more important than actually delivering valuable working software to our business customers. Over time, the notion of project management instead of being something that is done as part of one's job became a full-time job for professional project managers. Of course this was justified in the name of increased productivity, but if you were to back-test this notion, did it really happen?"

While increased productivity may be one argument used to justify PM, it's a minor one. The two biggies are projects delivered on-time and on-budget, or as close to them as possible. IT has always had major credibility problems in the time and budget arena, which is a slam-dunk justification why the project management function exists. JT also correctly points out that 'PMs often get assigned to projects where a new solution or significant system changes is occurring. It is not their job to deliver on the promise of SOA or balance the impact of the changes to the IT portfolio--nor are they rewarded for such.' and '...Done correctly there is balance like Ying and Yang. Their priorities are just different. PMs need to get the function deliverables complete, on-time, with minimum number of resources and come under budget.'

Bingo. This is where the intersection between architects and PMs should be, and that they cooperate with each other acting in the best interests of the project - which is much more than delivering working software. I know a few PMs who are lousy leaders/managers, and every professional occupation has them. However, I know many more who are very good at what they do and deliver (with their teams) significant and complex IT projects within the necessary time and cost parameters with reasonably content project teams. JT's comment about 'balance' above is right on the mark, and successful enterprise architects cooperate with the project management function like they do all other parts of the business, not try to circumvent or usurp it.

Comments:
I would love for you to explain in a future blog entry if you believe my thinking is a predictor of success for an architect role.

"Beyond JM's bias that only coders can succeed as architects"

NOTE: I never stated that folks who are non-technical in the architect role would 100% fail.
 
Noticed something else you have misinterpreted. My comments were in context of enterprise architects, not software architects. Enterprise architecture is not about project-level deliverables

"If the PM doesn't or can't know where JM's at with respect to project deliverables"
 
Sorry James, we'll have to agree to disagree on EA and projects. Any EA who has their architecture built out certainly does participate on projects and teams. I know many EAs who work on project teams with the business, other EAs, and yes, development teams from time-to-time.

The number of EAs I know that aren't academics who work completely solo is currently zero.
 
Post a Comment



<< Home
Technology Blog Top Sites |

This page is powered by Blogger. Isn't yours?

Weblog Commenting and Trackback by HaloScan.com