technical leadership is the No. 1 factor determining the success or failure of a project.
Does this sound familiar? You select an information technology vendor based on an excellent proposal, only to discover that the people delivered by the vendor don't seem capable of doing good work.
Perhaps the people whose resumes appeared in the proposal actually showed up to do the work, but then again, perhaps not. Perhaps their resumes didn't actually reflect the capabilities of the workers in key positions on the project. Or perhaps the technical approach that looked so good on paper ran afoul of bugs in vendor products and the difficulties involved in integrating software from different companies.
Whatever the reason, the experience is a common one. I recall being in a meeting where a new project team was being introduced to IT management. The fellow in charge looked at the impressive group of people and asked, "Where are the diggers?"
The question was a little puzzling, so he explained that he supposed that people with such impressive positions and resumes might be unwilling or unable to sit down at a desk and actually do the work involved on the project. So he was wondering who would actually be doing the work.
Only two hands went up.
Agencies try to solve this problem by identifying individuals as "key personnel." There are certainly key personnel on any project, and one of the essential skills for even a minimally qualified manager is to be able to identify those people and keep them on the project.
But until you've actually seen people on the job and working, how can you tell who is essential and who is not?
In the case of the "killer" proposal, there is often a small team led by a "capture manager" who puts together the proposal. These people may be extremely talented and may understand the problem well. However, there's no requirement that they actually be the people who do the job. In other words, the technical leaders who produced the proposal may not even be offered to the agency.
Technical leadership is probably the No. 1 factor that determines the success or failure of a project. If technical leadership is absent, no amount of "process" can fix it. If technical leadership is present, however, it's likely that the team will achieve its goal, even if the path to success requires many changes of direction.
It would be interesting to see what would happen if agencies required that each proposal identify the team that wrote it, providing extra evaluation credit if the people who wrote the proposal were also proposed to work on the job.
For that matter, it would be interesting to see what would happen if agencies were more aggressive in including contract language that allows the contracting officer's technical representative to request the replacement of marginal personnel. It's at least one way to persuade a vendor to provide a better staff — and maybe even provide the caliber of staff promised in a proposal.
Bragg is an independent consultant and systems architect with extensive experience in the federal market.
NEXT STORY: LexisNexis slices government info