RECMGMT-L Archives

Records Management

RECMGMT-L@LISTSERV.IGGURU.US

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Larry Medina <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Thu, 28 Feb 2013 09:24:55 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (71 lines)
While I won't completely disagree with PaK and Bruce on this, my opinion
comes from two different perspectives- one as a past employee (for a total
of 18 years) of three major EPC Contractors, and the other as a current
Contractor to a Fed Agency who has seen this happen on a regular basis.

Common practice for large contract firms who make their living off of
perpetually renewing contracts to certain clients, in many cases, Federal
Agencies has ALWAYS BEEN to seek out and/or accept contracts that are
poorly scoped and bid lower than the competition to get the initial
award... THEN look to making the real money on the back end by issuing
scope change after scope change, increasing the fee and extending the
schedule and offering two primary options- continue with existing staffing
and stretching out the deadline, or adding staffing to maintain the
deadline.

But a recent court decision is likely to see this trend changing, and in
part, this is what CA is using as their defense against SAP
http://caselaw.findlaw.com/us-9th-circuit/1607686.html  and here's a plain
English story related to the case
http://www.constructionandinfrastructurelawblog.com/2012/12/articles/false-claims/knowingly-underbidding-for-government-contract-may-lead-to-false-claims-liability/

It's true that if a client fails to perform a functional needs assessment
and clearly identify what they want to achieve, they can't ask for what
they want (weak scope, poorly defined) and if they award a contract and the
contractor starts working strictly to the scope, it will regularly come out
that there are things that were forgotten or could be done in a better way,
and worse yet, as this is brought to light, the client inevitably will say
"Gee, you know what would REALLY BE NICE to have?" ... which is when the $$
light up in the contractors eyes.

And boy howdy, was Bruce right about the skill level of the PMs typically
assigned to these projects... project management has NEVER been a forte of
Federal Agencies, and is a relatively rare commodity in other sectors as
well... that's improving, but it's a slow growth.

What tends to happen on contracts related to major process changes that
include the deployment of technology is an initial analysis of the desired
outcome is performed, but it may fail to identify all of the stakeholders,
or during the analysis (which can at times go on for a year or more) the
organization makes changes and there are new players that weren't initially
in the scope of the effort. And it's not uncommon to think more about the
desired outcome than the existing process and miss things that happen now
for a reason that will not happen any longer after the changes are made,
which can require adjustments.

In the past, when similar discussions about what vendor/system should be
selected have been asked, one of the common responses is "It Depends" and
one I've used many times goes back to Lewis Carroll's "Alice":

"One day Alice came to a fork in the road and saw a Cheshire cat in a
tree.  "Which road do I take?" she asked. "Where do you want to go?" was
his response. "I don't know", Alice answered. "Then, said the cat, it
doesn't matter." "

So to apply this to a client/contractor scenario, it essentially faults a
client for their technological or process ignorance.  If they don't know,
part of what they are looking for when they send out an RFP is some
guidance. If a bidder looks at the scope and sees it is full of holes,
based on their knowledge from prior engagements, is it right for them to
plead ignorance when they see it?

Larry
[log in to unmask]

****

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]

ATOM RSS1 RSS2