he main point is that the managers should understand the business or the project that they are managing because they are the key decision makers.
Managers who are just facilitators of other people but don't understand how the business or project will work will be more prone to making bad decisions.
That's why a good design team doesn't need the manager making the technical decisions. They are there to manage the project, not necessarily make technical decisions. It's hard to focus on project management and be abreast of all the design issues and correctly make the big decisions at the same time. I think that's asking too much and could actually lead to bad or even worse decisions!, regardless of how good the technical oriented manager is.
A good large design team will have dedicated project technical decision makers/leaders to handle that stuff, as Kremmen mentioned.
In an ideal team, you want the best people doing their rolls. The best manager, the best technical leader/decision maker, the best designers, the best techs, etc, each 100% focussed on their role. The role of the project manager is to ensure the others are 100% focussed on their roles, and all on the same track. And that does not necessarily require good technical skills.
Dave.
I'm sure the point was made already, but let me still illustrate the multitude of roles a PM may encounter in a bigger project, using a real life example. NDA prevents me from being specific, but this much i can tell you. In February i completed a 3 year consultation job for a world class corporation that you all are guaranteed to know by name. The job was to manage the creation of a mission critical semi realtime provisioning system and its deployment into a highly available, multiply redundant operational environment. I won't go into the boring details of the deliverables, but just check the roles that were involved in the project:
The core team included the following roles:
- Business Development Manager who is familiar with the organization from a long time back and has a wide network of contacts all over the place. His knowledge is used for high level requirements gathering and long term roadmapping. This is the guy that chairs the feature priorization, high level scheduling and release lifecycle process meetings. He is not the sole decision maker though.
- Concept Owner who makes sure the project deliverable is in line with whatever was agreed regarding the product's positioning in the IT process map
- Chief Architect who is responsible for Enterprise Architecture conformance and high level solution architecture
- Data Architect, responsible for Data layer architecture, data presentation schemas and such
- Solution architects responsible for identifying and specifying actual components of the overall solution
- Lead Develpoper (or Designer) responsible for turning the architecture descriptions into actual specifications and coding work packages
- The design team consisting of programmers, database experts, communications experts and so on. People like scrum masters for the agile development teams are in this group
- test manager and core test team to run the QA as per plans
- Configuration Manager who oversees the numerous things necessary for proper deployment from software installations to firewall configurations and all such things. He interfaces with the actual operations teams and any extrenal parties that need to do something to create a working setup
Outside the core team there are several roles that directly work with the project to make everything happen:
- the Enterprise Architecture team that provides quidance to align the project with the overall corporate IT architecture and review & approve conformance
- Enterprise security to audit and approve the architecture and software solutions for security and confidentiality
- Financial analysts to verify proper accountabilities and checks and things like SOX (Sarbanes-Oxley for the non yanks) compliance
- External specialists such as DBAs and sysadmins with special knowledge of the operational environments and how to integrate into their processes
- PMs and managers of integrated products and services to ensure correct and timely data exchanges with systems providing or receiving process info. Same with managers of internal it services.
- Product and Service Managers who are responsible for the product and service once it is in production. The project needs top provide all necessary information for that and
- Production manager who owns the operation environment
- Service operation, incident management and problem resolution teams in the operation. All of those are needed during the project to setup the staging environemnts from development to regular production and to verify that transition to operational mode has been successful.
That's off the top of my head. I'm sure ther is more but you get the picture already. There is just no time for the PM to try and contribute anything to the actual product, and he is not expected to. If he understands the system itself it is good, but if not there are those who do. In this case i did understand the system on a deep level but that was of course due to my background.