I have been doing some reviews and audits of courses that teach acquisition as part of an overall curriculum to project managers. The courses take a life-cycle approach to the processes and methodologies in effective project management, which includes a section on procurement and buying the product or service to satisfy the developed requirements and need.
I am finding this acquisition section to be very spartan, and not actually preparing and educating project managers on the actual things they need to do in acquiring goods and services:
In general, program managers are responsible for requirements development and overseeing the technical progress of a program, if the program requires development. He or she is ultimately responsible for the cost, schedule, and effectiveness of the system or service that his program office has been chartered to deliver.
DHS is similar to DoD, so we have engineers, logisticians, IT specialists, etc. that are all part of our PMO's. A PM doesn't necessarily need to be an expert in these areas, but he or she needs to know enough where they can manage these technical specialists. In a perfect world, a PM would rotate through all these different specialties to learn how they operate.
Incidentally, if you look at the competencies that FAI published over the summer for program managers, the most important trait is "leadership." One thing that I've seen at CBP (not sure how widespread it is throughout the federal government) is that employees aren't eligible for leadership training until they're GS 14's...and by that point, it's generally too late. Again, in a perfect world, leadership would be considered part of the "developmental training" for lower GS grades (9 through 12). I think the time investment would give us much stronger PM's.
Daniel - I agree that leadership should not be available only to senior people, as this critical skill is needed at levels. In regards to responsibilities, what role do you play in the procurement of technologies, outside of requirements development?
When I work with PMs / COTRs / other technical people, I like to educate them on the big picture, and what the job of procurement is and why. I basically reiterate that when we are spending the government's money we have certain rules, and here's an overview of those rules. The theme of the latest training I provided was "communication". I want them to know who to ask, and what situations (such as sole/single source justifications, high dollar values, and when buying services) they should let my group know of well in advance so we can work with them. When I was working in government and primarily with an IT Services group, I became their business advisor - I'd attend their meetings, and I learned about their organization to the best of my ability. Eventually I was able to foresee their requirements and understand the big "enterprise" picture. Ideally, there would be these types of business advisors for every key mission within each public and private sector organization. It was a great partnership. I'm of the mind that I'm not going to learn their job, and they're not going to learn mine, so we have to talk if we're going to be successful.
The great partnership is the best way to go, but as you state, the institutional knowledge by functional area does not normally translate to cross-functional knowledge. Nonetheless, the cross-functional knowledge, such as through the FAC P/PM, can help strengthen the relationships when the PMs have the fundamental ACQ knowledge to help improve requirements development, market research, and help create better procurement packages. It certainly helps COs/KOs be the business advisors early in the process, and as part of the IPT during the IPPD process and the overall acquisition program.