PALT

I’ve always thought PALT a is mostly meaningless the way it’s historically measured - receipt of a “ready” requisition to contract award.  So a program office can struggle for months trying to put together a requisition package with no help from the contracting office, have the package bounced back several times because it’s not “ready”, and ultimately gets an award way too late.

Then OFPP lately changed PALT release of a solicitation to award!  What is meaningful about that to a program office?

Probably a better measure from an overall government perspective is identification of need to delivery of product or start of service.

Increasing PALT is a symptom, not the disease

here_2_help said:

Increasing PALT is a symptom, not the disease

The disease is increased workload, insufficient capable staff, and/or inadequate processes.

Some offices are doing very well. Others are suffering.  The main differences is being able to see what was going to happen and adapting.

On 9/21/2021 at 10:44 AM, formerfed said:

Then OFPP lately changed PALT release of a solicitation to award!  What is meaningful about that to a program office?

Solicitation to award is a very industry-focused definition of PALT, because it represents the time when offerors have their resources tied up in a proposal. It's probably not particularly meaningful to a program office or contracting office at all. Incentivizes contracting offices to minimize proposal preparation time and to award without discussions.

The time from receipt of a "procurement-ready package" to award is a contracting office focused-definition of PALT. Also probably not very meaningful to a program office who can't get a procurement-ready package in the door. Incentivizes contracting offices to not "accept" less than perfect packages, which may well actually increase overall requirement satisfaction lead time for the program office.

The time from identification of a need through delivery is a program office-focused definition of PALT and probably what really should be incentivized. But it's too broad to really assign responsibility for to a single entity (assuming the program office and contracting office are separate) so it's probably hard to do.

@Witty_Username

Thanks for a very insightful post!

I agree with you about time from identification of need to delivery. Another complicating factor in that concept of PALT is changes in the conditions that give rise to the need (for example, opponent strategy, tactics, and weaponry) and changes  in technology.

Witty_Username said:

The time from identification of a need through delivery is a program office-focused definition of PALT and probably what really should be incentivized.

Delivery of what?  To satisfy a need may require quite a bit of R&D, design, prototyping, OT/DT and full scale production if it ever gets that far.  Think of the DIVADS or A-12.  A need was identified for each but never satisfied with an end product although billions of dollars were spent trying to satisfy those needs.

Retreadfed said:

A need was identified for each but never satisfied

I agree. And maybe the PALT on some of the DIVADS or A-12 contracts was 72% faster than current PALT, and yet the need was never satisfied. So I wouldn't declare overall success based on how fast a contract was awarded that never actually fulfilled the need.

But, easy for me to say, hard to actually do (except to be aware that we shouldn't overly-incentivize a narrow definition of PALT that doesn't include delivery/success)...

Witty_Username said:

So I wouldn't declare overall success based on how fast a contract was awarded that never actually fulfilled the need.

I heard a senior executive commenting on the Coast Guard Deepwater cutter failure.  He said their streamlined award process showed them months earlier that the ship wouldn’t work as designed.  So he credited the contracting process a success

formerfed said:

streamlined award process showed them months earlier that the ship wouldn’t work as designed

Interesting. In that case you might more broadly define the need as finding out whether some particular design will work. "Failing fast" could be seen as fulfilling the need to find out what works, make changes, and try again. Of course you can keep opening the aperture and question whether any particular platform satisfies the need for a specific capability, and whether any specific capability satisfies the need for national defense, etc.

I certainly think there is likely to be value in speeding up PALT, however it is defined, as long as it isn't done at the expense of some other part of the overall process. Understanding where contracting (or any particular role) fits in to the overall process is a challenge, particularly in a contracting office that supports many different external "customers", but I think by trying to understand the goals of the level above you (e.g. contracting understands program goals, etc.) you're more likely to be able to optimize your own part of the process in a way that doesn't negatively affect the overall process. Alternately if you don't understand the higher level goals you may well optimize your own part of the process in a way that hurts the overall process.

Retreadfed said:

Delivery of what?  To satisfy a need may require quite a bit of R&D, design, prototyping, OT/DT and full scale production if it ever gets that far.  Think of the DIVADS or A-12.  A need was identified for each but never satisfied with an end product although billions of dollars were spent trying to satisfy those needs.

PALT is Procurement Administrative Lead Time. It does not include production lead time. When measuring PALT, lead time ends with contract award. If you measure to delivery of the product you're measuring Procurement Lead Time, which includes administrative and production lead time—Procurement Administrative Lead Time.

On 9/23/2021 at 10:27 AM, Witty_Username said:

The time from identification of a need through delivery is a program office-focused definition of PALT

Witty made this statement with which you agreed.  My simple question is in this definition what is it that is to be delivered?

On 9/23/2021 at 10:27 AM, Witty_Username said:

Solicitation to award is a very industry-focused definition of PALT, because it represents the time when offerors have their resources tied up in a proposal. It's probably not particularly meaningful to a program office or contracting office at all. Incentivizes contracting offices to minimize proposal preparation time and to award without discussions.

The time from receipt of a "procurement-ready package" to award is a contracting office focused-definition of PALT. Also probably not very meaningful to a program office who can't get a procurement-ready package in the door. Incentivizes contracting offices to not "accept" less than perfect packages, which may well actually increase overall requirement satisfaction lead time for the program office.

The time from identification of a need through delivery is a program office-focused definition of PALT and probably what really should be incentivized. But it's too broad to really assign responsibility for to a single entity (assuming the program office and contracting office are separate) so it's probably hard to do.

This is what I was going to write, except its already been written.  Amen.

I have an action right now that I am about to award, this is its actual timeline:

• Identification of need  -> 'acquisition package' to contracting office:  Maybe 2 months
• Receipt of Acquisition Package -> Solicitation: 3 months
• Solicitation - Award: 2 weeks

What is the PALT here?

Depends.  Traditional measurement - 5 months.  New OFPP measurement - 2 months.  Program measurement - 7 months.

Regardless of the way some people view it, the most significant measure is 7 months.  That’s because procurement is a support function.  We are here to assist our agencies in carrying out their mission.  Assessing how well that occurs is what’s important.

Retreadfed said:

Witty made this statement with which you agreed.

@RetreadfedYou're quite right, and upon reflection my expression of agreement was enthusiastic, but not thoughtful.

General.Zhukov said:

What is the PALT here?

Good question.

OK, everyone: what do we want to know and manage? I think we want to know and manage how long it takes for the acquisition system to satisfy requirements. That being said, I think acquisition, as defined in FAR 2.101, takes place in the following three acquisition administrative phases and lead times, each with the following outcomes:

1. From submission of a need by a user to a program office until completion of a procurement package (including a specification or statement of work and other necessary documentation) by the program office. Let's call it procurement package lead time.
2. From submission of the procurement package by the program office to a contracting office until issuance of a solicitation by the contracting office. Let's call it proposal solicitation lead time.
3. From issuance of the solicitation by the contracting office to award of a contract by the contracting office and the program office. Let's call it contract formation lead time.

After contract award, the time required to deliver supplies, complete the performance of a task, or commence performance of an on-going service, would be considered production or performance lead time.

What do you think?

On 9/23/2021 at 7:27 AM, Witty_Username said:

Solicitation to award is a very industry-focused definition of PALT, because it represents the time when offerors have their resources tied up in a proposal. It's probably not particularly meaningful to a program office or contracting office at all. Incentivizes contracting offices to minimize proposal preparation time and to award without discussions.

The time from receipt of a "procurement-ready package" to award is a contracting office focused-definition of PALT. Also probably not very meaningful to a program office who can't get a procurement-ready package in the door. Incentivizes contracting offices to not "accept" less than perfect packages, which may well actually increase overall requirement satisfaction lead time for the program office.

The time from identification of a need through delivery is a program office-focused definition of PALT and probably what really should be incentivized. But it's too broad to really assign responsibility for to a single entity (assuming the program office and contracting office are separate) so it's probably hard to do.

I agree w/ Vern that this is a very insightful post.  I'm not sure if you're saying they changed the definition of PALT to satisfy industry, or if it's just a coincidence.

I think the reason for the new definition of PALT is more out of convenience than anything.  I think the new definition is what it is is because PALT can now easily be calculated via FPDS-NG.  Solicitation closing date & award date are both known, and it's now required to include the solicitation number in the award CAR.  This is the only way to actually track this kind of data on such a large scale.

The stated reasons for using the definition is here:

https://www.federalregister.gov/documents/2020/01/21/2020-00783/procurement-administrative-lead-time-palt  

I’m not sure how much capturing data with this definitions helps.  More complex procurements need longer time time for offeror proposal preparation.  Regardless of how much pre-solicitation communication occurs, questions from industry and noted unclear language and errors results in due date extensions.  More detailed proposals and large numbers of responses add evaluation times.  I know all this stuff gets captured in FPDS but what good does just looking at the data produce?

Krimz said:

Solicitation to award is a very industry-focused definition of PALT, because it represents the time when offerors have their resources tied up in a proposal. It's probably not particularly meaningful to a program office or contracting office at all.

@Krimz, in my industry experience, solicitation to award and supplier lead times are meaningful to a program office.

On 9/26/2021 at 7:50 AM, Neil Roberts said:

@Krimz, in my industry experience, solicitation to award and supplier lead times are meaningful to a program office.

Yeah, not saying they were not (I was quoting that), but when I think about the old definition of PALT, or other meaningful definitions of PALT, it seems like it would be would be very hard to accurately track any other meaningful metric.

On 9/24/2021 at 5:25 PM, Vern Edwards said:

@RetreadfedYou're quite right, and upon reflection my expression of agreement was enthusiastic, but not thoughtful.

Good question.

OK, everyone: what do we want to know and manage? I think we want to know and manage how long it takes for the acquisition system to satisfy requirements. That being said, I think acquisition, as defined in FAR 2.101, takes place in the following three acquisition administrative phases and lead times, each with the following outcomes:

1. From submission of a need by a user to a program office until completion of a procurement package (including a specification or statement of work and other necessary documentation) by the program office. Let's call it procurement package lead time.
2. From submission of the procurement package by the program office to a contracting office until issuance of a solicitation by the contracting office. Let's call it proposal solicitation lead time.
3. From issuance of the solicitation by the contracting office to award of a contract by the contracting office and the program office. Let's call it contract formation lead time.

After contract award, the time required to deliver supplies, complete the performance of a task, or commence performance of an on-going service, would be considered production or performance lead time.

What do you think?

Why distinguish #2 and #3 if they are both primarily the responsibility of the contracting office?

@Don MansfieldWhile most people think that the contracting office is responsible from receipt of proposals through contract award, I think that the analysis and evaluation of proposals is what takes the most time during that phase, and that is the joint responsibility of both the program office and the contracting office, and so should be distinguished from Step 2, which is primarily the responsibility of the contracting office.

Make sense?

Vern Edwards said:

@Don MansfieldWhile most people think that the contracting office is responsible from receipt of proposals through contract award, I think that the analysis and evaluation of proposals is what takes the most time during that phase, and that is joint the responsibility of both the program office and the contracting office, and so should be distinguished from Step 2, which is primarily the responsibility of the contracting office.

Make sense?

Yes. Good point.

I’m skeptical of anything good coming out of measuring time from solicitation issuance to contract award (#3).  Let’s say OFPP pushes agencies to emphasize use.  So any smart CO being scrutinized on timeliness will do maybe several things - closely nitpick any requisition package first, and issue the draft package to industry as a RFC or draft RFP to identify potential problems first.  Another is having a proposal due date in much less time of what’s reasonable.  

The important thing is how long does it take for a program office and a contracting office to collaborate and get an award in place from identification of a need to award of a contract?

formerfed said:

The important thing is how long does it take for a program office and a contracting office to collaborate and get an award in place from identification of a need to award of a contract?

No,  that's not the important thing.

Vern, what do you think is the most important measurement for timeliness then?

formerfed said:

Vern, what do you think is the most important measurement for timeliness then?

To be frank, I'm no longer sure.

The reason I say that time from identification of need to contract award is not the most important measurement of timeliness is because it's too all-encompassing. You can measure it. That's easy. But it's hard to figure out what the measurement means in any given case.

How long should it take to develop a description of a requirement—a list of deliverables and a specification or a statement of work? How long should it take to develop a solicitation? How long should it take to select a contractor and make an award?

During planning, the answers to those questions will always be, "It depends." It depends on the requirement, on the organization conducting the acquisition, on the people conducting the acquisition, and on the situational context. But it's easy to say afterward that a process took too long. I say it all the time.

In manufacturing, the purpose of building a factory is to create an artificially controlled environment in which to conduct a highly repetitive process for which it is then possible for industrial engineers to set valid standards for cost, quality, and time. I don't think that's easy to do for the acquisition process. There are too many uncontrollable conditions.

What do you do with a process measurement if you are not producing a standard product under standard conditions and lack valid standards of comparison? During my entire 47 years in this business, PALT has always been an issue, and the lack of widely-accepted process standards has always been the problem with PALT. The standards have always seemed arbitrary, and they often were. You can try to categorize acquisitions and set category standards, but once you get past the purchase of standard supplies and services, most acquisitions are unique to some extent.

If you don't have process standards that process managers accept as fair and valid, then your measurements, and critiques based on them, will largely be for naught. Go ahead and measure, if you insist, but it won't do you much good. The most important process measurement is one that is both pertinent and for which you can set a fair valid standard. Acquisition is not done in a factory.

I doubt that you'll agree with me. But did I answer your question? Does the answer at least make sense?

Quote

I doubt that you'll agree with me. But did I answer your question? Does the answer at least make sense?

Vern, it certainly does make sense.  Thank you also for taking the time and effort for that explanation. 

To me PALT is useful mostly as a comparative tool.  It’s not a precise measurement because of all the variables.   One can compare PALT performance by commodities, by program offices, by contracting offices, and even by contract specialists.  But a single or even a few instances doesn’t show much at all.  

If PALT data shows good performance compared to poor performance, that should lead to analysis to see why there’s a variance.  Lots of reasons are possible but by study, one can make changes and improvements.  I think the major benefit is it leads to digging into reasons why something occurs.  Ultimately improvements may be made.

One other useful aspect is program offices can look at historical data and see possible long long their new procurement may take.  It helps with planning.  I don’t think a program office cares that much about how long an award takes from issuance of a solicitation.  What’s more meaningful to them is when will an award be made based on our starting the process.

Couple last thoughts.

If you measure #1, it’s easy to add #2 and 3 in as well.

As far as 3, one major reason for delay is proposal evaluations.  When doing technical/price trade offs, competitive evaluations often drag on.  It’s definitely a challenge when identifying technical evaluators.  Program offices are reluctant to use their best people and you often end up with those with nothing better to do.  Training is another challenge.  Then getting the evaluations done in a timely manner can be difficult.  People sometimes consider evaluations as a collateral duty.  Evaluators take leave.  Work priorities can override.  Then getting everyone together for consensus can also take painfully long.  Often at some point, legal or procurement management criticize parts of the evaluators and rework is required.  This all doesn’t even get into redoing the evaluations after discussions.

Unless all this is documented and measured, antidoacural stories don’t carry much weigh persuading management to make evaluations a priority.

I have thought a lot about this, especially since I got into management around 2013. I used to measure the crap out of PALT. I had a beautiful spreadsheet that would calculate the allotted PALT a specialist had to accomplish a given task. The allotted time was based on our local PALT allowances. I was able to say things like, "Contract specialist A, on average, delivers awards 10 days ahead of the allotted PALT." But it ended up being a meaning-free effort. Contract specialist A worked mostly on simplified acquisition, exercising options, adding incremental funding, and the like. I was certainly happy the work was getting done "on-time" but it doesn't say much about how effective contract specialist A is, nor do the aggregate results tell you much about the effectiveness of the entire office.

I changed my approach after coming to that realization. What I concern myself with most these days is ensuring my office writes solicitation procedures that sets the evaluation panel up for success. We've embraced oral presentations, limited essay-writing type proposals, and conducted advisory down selects. As someone said above, the length that an evaluation should take depends. But within the circumstances and context of an individual procurement, there are "smart" things we can do to reduce the chances we end up in evaluation hell for a year. 

So I kind of come down to this: if you're going to measure it, solicitation release to award is probably best. It does set up some perverse incentives (they've been mentioned, reluctance to enter into discussions, etc.). So does every other way to measure it.

Lastly, in the context of research and development, PALT from solicitation release to award doesn't make a lot of sense. If you are using BAAs, you may be engaging in process which includes a concept paper submission followed by a full proposal. Then you may seat a merit review panel, potentially of external experts. PALT isn't a measure of effectiveness in that context (If it ever is).

Quote

So I kind of come down to this: if you're going to measure it, solicitation release to award is probably best. It does set up some perverse incentives (they've been mentioned, reluctance to enter into discussions, etc.). So does every other way to measure it.

When you get down to it, acquisition is a function that supports mission.  If a program office struggles for a year putting together a requisition package and PALT takes 120 days, is contracting successful?

formerfed said:

When you get down to it, acquisition is a function that supports mission.  If a program office struggles for a year putting together a requisition package and PALT takes 120 days, is contracting successful?

I think you'd have to look at why it is taking that long. It very well could be that the requirements for putting together a procurement package are too complex or the tasks are misallocated. A lot of contracting offices make the program offices write the acquisition plan, which I think is crazy. Of course the program office is going to struggle to write a procurement document! I've also seen requisition packages rejected because they were not accompanied by pencil whipped documents, which creates unnecessary delays. In those cases, contracting is unsuccessful. 

On the other hand, there is sometimes a lot of debate and disagreement in the program as to what should actually be procured. I have seen this a lot in our IT function--there is a cohort that wants to modernize existing systems and there is a cohort that wants to maintain the existing systems. Both parties have relevant points, though I fall in the former (I'm oversimplifying the controversy, of course). But in controversies like that, there's only so much I can do as a CO to push the project. I'm not an IT expert and I don't have to live with, necessarily, the consequences of doing the former vs. the latter. In these sorts of cases, I can't quite put the blame on the contracting function.

@KeithB18 That is a major problem especially when a lot of the acquisitions involve major IT.  A couple of agencies partially solved that by creating organizations intermediate between CIO and Contracts.  The CIO office funded a few positions.  Some of those are IT specialists that take user requirements and convert to documents supporting the acquisition process.  Other positions are contract savvy people that have some IT knowledge.

It's not enough to just set PALT targets. Someone has to put together a group to map processes for various kinds of acquisitions, assign roles and responsibilities, estimate process times, set tentative goals, measure actual performance, compare performance to goals and diagnose, and then adjust. It's an ongoing process. It never ends. Moreover, PALT times are affected by workforce experience and education, and when the workforce changes so will PALT.

@KeithB18Keith, you seem to have thought about this, and you write clearly. Why not do a literature search, think some more, and write an article about PALT for Contract Management and Wifcon?