Monday, January 30, 2006
Healthy Tension-building Between Project Managers and Architects
A gentleman on my blogroll inquired about numerous topics, and since the issue of IT governance generally gives me a headache and temporarily causes me to rant, slobber, and develop unflattering facial tics, I'll hold my fire on that topic for another time and work the issues between architects and project managers. Specifically, said individual is asking about developing a healthy tension between architects and PMs. Here's my buck-and-a-half take:
Let's begin from a simple premise: architects specify and design, and PMs have to plan and execute projects from them. Although I have functioned in both roles, I don't to both simultaneously because its impossible to do both of them well in that mode. I also agree with other EA bloggers' assertions that good IT PMs primarily have an IT background with significant business-facing exposure as a side skill.
Now, let's look at this interaction of specify/design and plan/execute in a bit more detail. The architect has the following general responsibilities to the PM and project teams:
Lots more to say about this in future posts, but I'll throw this out to the blogosphere to start and for always-welcomed commentary.
Let's begin from a simple premise: architects specify and design, and PMs have to plan and execute projects from them. Although I have functioned in both roles, I don't to both simultaneously because its impossible to do both of them well in that mode. I also agree with other EA bloggers' assertions that good IT PMs primarily have an IT background with significant business-facing exposure as a side skill.
Now, let's look at this interaction of specify/design and plan/execute in a bit more detail. The architect has the following general responsibilities to the PM and project teams:
- The design and specifications have to be tactical and buildable. By that, I mean that the design must be clearly communicated and understandable such that action can be taken by others - the PM and project team.
- In whatever form architectural documentation takes, and this can range from prose, functional specs, UML models, tool-generated diagrams and documents, etc., the design and specifications must be clear and executable by project teams. I've seen too many 'architectures' that amounted to simply being 'plans to do more planning.' I blogged further on that particular malady in my Project Management weblog.
- Architects make themselves available to PMs and team leads for review, further explanation, and in some cases, defense of the design and specifications prior to the majority of the project substantially starting work.
- Designs and specifications adhere to existing standards within the organization and architects must petition for exceptions and approval from management when necessary. It is unwise to leave exception petitioning only to the PM, I'll explain that in a minute.
- Architects avail themselves throughout projects executing their designs and specs to assist in scope changes or other technical issues that may arise. The interaction can vary widely depending on what PM methodologies are being used and the architect is assisting the project as a technical advisor, not as a development team member.
- Architects understand that they are responsible for design and specification, not project execution or outcome.
- Architects also understand that the PM is responsible for appropriate risk management and mitigation on the project, and assists with that (usually via design/specification) when necessary.
- The project manager engages the architect from the beginning, during the project charter phase, at a minimum as a subject matter expert (SME) and more often as the initial technical lead prior to development.
- Project managers are up-front with architects with the architect's role in the project plan. No surprises or hidden agendas later on - PMs are factoring the architectural efforts into their formal plans or they don't and are up front with architects about it.
- The PM engages the architects for all major exceptions to the architect's design and specifications that arise during project execution. PMs are not empowered to make these decisions on their own, but partner with architects and team leads to evaluate and present exceptions to established technical standards to whatever organizational body makes the final decision.
- PMs utilize architects during the project for clarifications and review of project deliverables and other project work produced. Unless explicitly stated and agreed up-front, architects are not to be viewed or used as development or testing resources on projects.
- PMs do not unilaterally alter, or authorize the alteration, of design and specification during project execution without the architect's input and recommendations.
- PMs ensure that their leads and project teams understand, and are comfortable with, the architect's design and specifications before the majority of the project work begins. If they aren't, the PM facilitates review of the architect's work with the architect and project teams such that clarity to all is achieved.
Lots more to say about this in future posts, but I'll throw this out to the blogosphere to start and for always-welcomed commentary.
Comments:
<< Home
|
I completely agree with James on that bullet - the PM's need to keep their hands off the design, something that's difficult for recycled techies to do sometimes. I had an old COBOL hack as a PM on a project once where I was the architect, and he spent more of his time trying to override my designs than manage the project. I left the project, he kept going, it was a year late and the client is now considering bringing me back in to review the design and help them fix it.
Post a Comment
<< Home