Acquisition 101 for Project Managers

Replies to This Discussion

Permalink Reply by Daniel Crystal on January 19, 2012 at 7:08am

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.

• ▶ Reply

Permalink Reply by Jaime Gracia on January 19, 2012 at 12:26pm

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?

• ▶ Reply

Permalink Reply by Andrew Krzmarzick on January 19, 2012 at 2:41pm

Note: this post has been picked up by Federal Computer Week, so there may be more responses there: http://fcw.com/blogs/acquisitive-mind/2012/01/project-managers-trai...

• ▶ Reply

Permalink Reply by Anne Hasselbrack on January 25, 2012 at 9:06am

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. 

• ▶ Reply

Permalink Reply by Jaime Gracia on January 25, 2012 at 6:06pm

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. 

• ▶ Reply