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:
Wed, 1 Sep 2010 15:18:47 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (80 lines)
Good point raised by many respondents here.

There are a few things to think about with "Federal IT Projects", regardless
of who the Agency is. 

If you've worked in this environment and you understand how money is
allocated (and that it occurs on an annual basis tied to the FY [10/1 to
9/30] calendar) you know that while you may request funds for October, they
may not be allocated until the following May or June... that doesn't mean
you stop working, you just spending non-existent money!  And while you
REQUEST a certain amount of money, that also doesn't men that the
Appropriations Committee grants that much, or if they grant it to your
Agency, it may not get allocated to you if the overall request is not met.

This makes funding/supporting the deployment of multi-year projects very
difficult.  In addition, your budget MUST ALL be spent prior to the end of
the FY, which means in some cases if you get your money and you're
underspending (not too often THIS happens), in the case of an IT Project,
you either purchase hardware or software with any funds that cannot be spent
on labor or other contract work supported by an invoice and cleared prior to
year end... or the funds are lost.

On the specific projects mentioned- the FBI project is actually the third
attempt to roll out a case management system... the first two were horrible
failures and HUGE money pits.  In both cases, there was insufficient work
done up front to determine the technological capabilities of the staff, the
strength of the data communications systems, the volume of legacy data, the
types/sources/forms or legacy data, the day-to-day needs of the users, and
what they REALLY needed the system to do.  It appears that a bit of the same
problem exists with v3.

With NARA's project, they seemed to change direction midstream and this
pretty much made everything stop in its tracks, then backtrack and start
down a new path.  The famous question "You know what would be nice to have?"
got asked, the contractor didn't say no, but the client didn't understand
the impact it would have on the project.  The big change was the desire to
provide a service to allow 'early ingestion of electronic content' while it
was still in an active state and not ready for transfer to NARA.

In both of these cases it sort of was scope creep, but more accurately, it
was a failure to perform a thorough needs assessment or develop process map
to generate a Functional Requirements Document (FRD) prior to developing a
project scope or engaging a contractor to perform work.  AND in both of
these cases, the Agencies used a Consultant/Contractor to assist them in
developing the scope... and in one case they broke the REAL Cardinal Rule...
they not only allowed that firm to bid, but they awarded them the contract.

There is some truth that 'scope creep' or 'gold plating' can (and does)
impact projects, but the real problem is frequently the failure to develop
an FRD, use that to define the scope, develop a REALISTIC and achievable
schedule, have a project plan with milestones for activities and purchases
and STICK TO IT.  And when you have people that want to add things to the
scope or raise the bar on items included, they need to be made aware of the
impacts to the schedule and cost PRIOR to work being approved. Even minor
deviations to scope will stretch out the schedule, or require the addition
of staff and these things have  a snowball effect on getting the work done
on time and within budget.

And while many people who are knee-deep in the projects REALLY want to also
be the Project Manager, that typically ends up being a REAL bad idea.  They
have too much invested and they tend to be less effective than someone who
'doesn't have a dog in the fight'.  A PM has to be able to remain objective,
see the impacts of change to schedule and cost and make decisions based
solely on completion of the project.  They must be able to take suggestions
and evaluate them for impacts, then go back to someone functionally involved
and explain the options to them of eliminating something else, or slipping
down the slope of non-completion and over expenditure.

Good luck to these Agencies, and the others who have projects critical to
the business of the Nation, but I sort of have my fingers crossed that they
don't continue down the existing path.

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