Where are the diggers?

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.


  • Congress
    Rep. Jim Langevin (D-R.I.) at the Hack the Capitol conference Sept. 20, 2018

    Jim Langevin's view from the Hill

    As chairman of of the Intelligence and Emerging Threats and Capabilities subcommittee of the House Armed Services Committe and a member of the House Homeland Security Committee, Rhode Island Democrat Jim Langevin is one of the most influential voices on cybersecurity in Congress.

  • Comment
    Pilot Class. The author and Barbie Flowers are first row third and second from right, respectively.

    How VA is disrupting tech delivery

    A former Digital Service specialist at the Department of Veterans Affairs explains efforts to transition government from a legacy "project" approach to a more user-centered "product" method.

Stay Connected


Sign up for our newsletter.

I agree to this site's Privacy Policy.