Travis County Commissioners Court
June 23, 2009,
Item 21
21.
consider and take appropriate action to issue a request for proposal for an enterprise resource planning/financialni management system.
>> [inaudible - no mic]
>> I thought that -- I thought that the court would like to be introduced to dean harvey, who is the attorney from vinson and elkins who has been assisting with the preparation of the documents giving a lot of -- of very good insight and advice on -- on -- on what we can expect and -- and what types of -- of conditions exist in the technical environment.
should you have any questions for him, he will be sitting at the table.
>> okay.
welcome.
>> thank you, good morning.
>> I have to say that we have really enjoyed dean's input.
he's just given us some really good ideas and it has certainly added significant value to the process.
i think everyone working on it would agree with that and thank you, dean, for your knowledge and ability to work with a lot of people.
it's really been a good part.
i'm going to just have a few opening comments and then turn over to the project director, which is
>> [indiscernible] today we're coming to the court to ask for you to approve the r.f.p.
for enterprise resource planning system.
as you will recall, one of the major differences between the system that we have now, other than it being 20 years old, there's that, is that the old systems are very transaction based.
i mean, they are really just numbers adding, cross wording, very transactionally and new systems which is why it's called an enterprise resource planning system are very difficult to process oriented.
there's a significant difference in that what you are looking at is more than just a system that handles the general ledger, but encompassing all of the business processes that come into the accounting system and the budgetary system.
therefore, you have a large group of very important players that work on that system and they are analyzing those business processes to come in.
so it's a much more inclusive large system than just what we did, you know, 20 years ago when we bought hte, which was primarily an accounting system.
i have to say we complaint criticize it.
we really got our money's worth.
i think it cost $175,000 for that system.
so I want to start out with that.
the other thing is that -- it will take us in excess of two years, you will see an implementation schedule, which is not different than what you have seen before, and hte is -- is a very old system.
and we are out of -- to remind you, we are out of account numbers.
we don't have any more account numbers, we are having to reissue which is not a good thing.
some of the system we are having to buttress up regularly to keep it up and running and doing the work that we need it to do until we get a new system.
my chief payroll officer, charles vince young, continues to remind -- charles vaughan continues to remind me, every time we get a payroll out, we probably have two people in our office buttressing up that payroll system to get it out.
i don't think we came too soon.
but it's a system that is necessary in accounting for the taxpayers money.
we need to know what they are getting, what the money is used for.
the purchasing act is controlled through it.
all of the financial controls focus in on that.
Commissioners court makes all of the decisions on budget what is approved and that comes through that system for control.
in other words, it keeps people from deciding that they will spend something other than what the Commissioners court authorizes, so it's an extremely important system.
one thing that I want to do so that I do not forget it before I go.
i really want to thank the Commissioners court for your support on this project, we have worked really long and hard so far.
seems like this is the beginning of the journey but really isn't.
we have been working about three years on this.
you have provided the resources that we have needed.
we're pretty much on schedule.
mike will talk why it's important to stay on schedule.
i want to thank all of the departments and offices for their cooperation in being -- getting to where we are today.
it has been an extraordinary effort, we have seen cooperation and inspiration that I have not seen for a long time.
so it's been a really hard process but a nice one.
with that I will turn it over to mike.
>> good morning.
>> good morning.
>> you don't have the much in front of you -- the r.f.p.
is over 770 pages long.
today we're going to try to cover some more important parts of the r.f.p.
certainly if any of you want to review it we can make it available to you.
one of the reasons that the document is so long is that there's over 400 pages of specific detailed requirements.
so we're going to spend some time trying to summarize, we will talk a little bit about how we got those as well.
also 156 pages of process flow charts and interface diagrams which we talked to you over a year ago about that process where we put together kind of the as-is process as far as the financial system goes right now.
>> I remember those.
>> yes.
i'm not going to try to bore you with those again.
susan mentioned this has been a very collaborative process.
i will try to bring that up as we're going through some of the different parts of the agenda packet today.
one thing that I wanted to say is the collaboration that we've had has made a huge impact on both the quality of this document as well as the timeliness of it.
we're actually on schedule to issue the r.f.p.
when we had planned to, which is July 1st.
i just wanted to mention that we do have an executive steering committee.
for this project.
and that consists of the county judge, the county auditor, the purchasing agent, the treasurer, the executive manager for admin ops, hrmd director, its director, executive manager for planning and budget and the county attorney's office.
the purpose of that committee, they meet as necessary and they monitor the progress of the project as well as give us guidance.
so that's been working very well.
as far as putting together the actual r.f.p.
document, that's really been a very collaborative effort with -- with the project team, the purchasing office, its, the county attorney's office and external counsel from v and e.
there are three main topics that we want to go over today.
hopefully you all have the backup for this agenda item, if you don't, let me know because we have some extra copies.
the main things we want to talk about are the requirements, the schedule and then also to give you an overview of the he felt indication process and method -- evaluation process and methodology that we are going to use to do that.
if you look at the backup, the part that's titled high level summary of the functional requirements, I will kind of start there.
the requirements are really the area that we've had the most.
they required the most collaborative effort and the -- to do this, we've had discussions with over 200 people in over 21 offices and departments here at the county.
the discussions centered around the needs that are being met by the current system, the needs that aren't being met by the current system, inputs and outputs of the current system and then also statutory requirements as well as internal control requirements.
and this -- this resulted in defining over 7,000 detailed functional requirements.
for the new system.
and -- and I think everyone who has worked on this would also agree there's been a full and extensive review process for all of the requirements and -- and part of this included that each owner of a function like for example accounts payable is a type of function has approved their formal requirements.
this means for example the auditor's office has approved the accounts payable requirements, purchasing has approved the purchasing requirements, hrmd approved the h.r.
requirements, p.b.o.
approved the budget separation and control requirements and so on.
so every area has signed off on their requirements.
we have kind of tried to categorize these.
first of all functions are just in alphabetical order, so if you are looking where is the purchasing part you can find that.
but we accurate categorized the requirements into three different types, the types are current functionality, which is really the things that we have right now in the system, either in hd or they might be in another system, but at least those other systems have some integration with hte, that's kind of the first category.
next would be process improvements, those are -- this is where we want to -- a new system to provide automation and/or improvements that today are either predominantly manual or are performed in other systems with little or no integration to hte.
then last category is new functionality, those are things that we can't do right now on any system and can't be performed effectively on a manual basis as we go through this, I'm not going to read all of this, but I'm going to try to highlight a few things.
iraq if like if you look at the next page.
payroll, it's about 625 detailed requirements for this area that are functional requirements.
primary users are the auditor's office, and all of the offices that request payments which is pretty much every office at Travis County and all employees as well that request travel or mileage reimbursements.
if you look the at current functionality segment there, you can see most of those functions are done by hte, the exception there is for example the -- the imaging that's done by a different system.
like I say, each are broken into categories where we have current functionality, process improvements and new functionality that we are requesting.
like I said, 7,000 detail requirements that back up this section.
the accounts receivable is the area where -- where the auditor's office and then all of the departments that generate -- generate external billings to give you some examples, like the county clerk for elections, they bill other entities for the election costs.
and the medical examiner for example.
you can see we really don't have any current functional tee right there.
you can also see what we are looking for in a new system.
the assets management there's 335 of those detailed requirements that's the primary users are the purchasing office, the auditor's office and then all departments and offices that maintain capital and/or trackable assets, this is an area that if lieu in the current functionality you can see most of the current functionality that we have is also not provided by h.t.e.
but provided by different systems that we have created to do some of that work and tie into the financial system.
those are areas that we would -- that we are looking to integrate as well in a new financial system.
>> current functionality means if it's not done in the hte we have figured out to do another way.
>> if it doesn't say hte after it, then yes it means that another system is doing that.
and we have some integration to hte.
so that's under the current functionality.
but we did list things that we do have functionality in hte, that was the point of putting the parentheses after each of those type of things.
in the asset management you can see almost none of those things are done in hte right now.
>> those are things that we are somehow doing now.
we don't want to lose the ability to do that.
may not be doing it in the best way, but we are doing that.
when we first met with you, our department and it really programed a lot of ancillary programs that dealt -- that connected to the financial system.
so it was -- it would include in of those.
>> sauce san, can you tell me -- susan, can you tell me, basically the hte system has been around for a while, you have --
>> [indiscernible] -- how -- how will this system be able to -- to interface with -- with all of the activities, functions and accounts or whatever that's under our current hte system, how will that be transferred I guess --
>> [multiple voices] I'm trying to --
>> [multiple voices] --
>> technical answer than I can.
but
>> [multiple voices]
>> trying to figure out --
>> how you are going to get --
>> yeah.
>>
>> [multiple voices]
>> right.
>> the reason that I'm saying that is because I want to -- I want to -- I know that -- that they will -- whoever is doing this, I mean technology is out of sight, out of mind now on some of these things.
i just wants to make sure we don't lose any information that's pertinent to -- to what we need to have.
as far as accounting.
>> we have requirements for that.
i was going to get to those in a little bit.
right now I was talking more about the functional requirements.
but there's like nine other types of requirements that I was going to briefly go through.
but one of them is the data conversion requirements.
we have very specific requirements for data conversion.
we have thought about what data we want to bring over, what data we want to kind of have off to the side.
that we can access.
but the costs would be staggering to -- we have 20 years of data in this system and it -- it doesn't seem cost effective in order to really -- nor really that important to bring over every piece of data.
we have identified in the requirements what data we want to convert and what data we want to leave.
to be fair we actually at least for the shorter term hope implementation of a new system, we anticipate still leaving the hte system up.
>> [one moment please for change in captioners] the old data that we didn't convert to another place.
but we have a lot of requirements as far as the data conversion part of this goes as well.
>> thank you.
>> sure.
as far as the rest of these functional requirements I'm just going to go through these quick because I'm sure -- if you have questions on any of these, feel free to ask too.
but budget preparation and control, the main users are p.b.o., the auditor's office and then obviously all the departments and offices because they have budgets and they have to prepare a budget and there has to be controls on those budgets and they have to be able to get the data that deals with their budget.
and, again, we have a list here, the current functionality we have.
if you notice one of the ancillary systems that we have is to do the budget adjustment requests and that's something that's not in h.t.e.
right now but as we look to going to a new financial system, that's something we would expect to be in the new financial system so we don't -- what we're really trying to do is cut down on all the interfaces that we have right now that are tied into our financial system where we've developed work-arounds and things like that.
we want to get as much as possible into a new financial system.
there's quite a long list of process improvements and new functionality.
we've determined those by working with planning and budget, for example, in that area.
the cash receipts, the treasurer's office, the auditor's office and any department or office that collects funds on behalf of the county.
and we don't have a lot of functionality in the current system other obviously than what we've listed right there.
i guess one of the things we did learn that was really important from talking to her entities that have gone out for new financial system is to make sure, though, that we do capture all the requirements for our current functionality because you have to identify the things you actually have and like and a lot of times the focus is more on what you don't have, you know.
so you write all these requirements for the stuff you don't have and sort of forget about the things you have and like and you need to make sure you get those as well so I think we've definitely done that with this project.
contracts.
we have 375 detailed requirements that deal with the functional aspect of contracts.
the main users of this would be the purchasing office, the auditor's office, all departments and offices that manage contracts like facilities, for example, are required contracts to purchase goods or services which is pretty much all the departments.
again, this is an area where we don't have a lot of current functionality and we're looking to provide new.
the debt investment part, there's sort of three parts to this as far as functionality goes.
we have the banking sort of aspect and positive pay, which are pieces that we have a little bit of functionality right now in the current system and then we've added a lot of add-ons to that.
there's also the investment aspect which is one of the areas that we're thinking we're probably not going to -- we're putting out the requirements for it, but our understanding in the past is this isn't really something that's captured too well in an e.r.p.
system so it is one of the areas we're thinking we will need an interface.
i think it's called the emphasis system, that -- I mean your caption investment manager utilizes right now on the investments.
and then also the debt sort of part of that.
there are some things there we do feel that a new e.r.p.
system would be able to at least have a little better interface into our financial system so that when you purchase debt or pay down debt that we can at least generate the accounting entries that need to interface into the e.r.p.
system.
financial reporting, we have about 80 detailed requirements for that and that's the primary user is pretty much the auditor's office, although everybody has some interest in so that we can prepare the annual report, the cafr as well as some of the monthly reporting that's required to be in the newspapers.
it's pretty important for everybody because this is one of the key things you have to have in order to be audited and get an audit opinion, which you definitely need if you are going to go out for bond issuances or debt issuance.
so even though it's primarily an auditor's office, then it's a pretty important component.
the general ledger, you know, is the auditor's office and all departments and office that require financial accounting or budget transaction information in summary or detail.
not going to go through all these either, but, again, you can see there's -- on almost all of these we have a lot of additional either process improvements or new functionality that we're looking for as well as the current functionality that we have.
i guess one way I kind of look at this is if you read through this document, it really should give you a pretty good idea of why we need a new financial system when you see what we have for current functionality including things we've already made the work-arounds for that are included and the process improvements that we're looking for and the new functionality that we're looking for.
you know, we've put all this together and just looking at them all in totality becomes really clear to me at least that we're really not asking for something that's not reasonable for an organization of this size.
you know, in some of the things you can say, wow, we're really -- there's a lot of new functionality you are looking for, but most organizations of this size would already have a lot of this functionality in a financial system.
so like I said, I think this is probably a pretty good -- if you get questions on why do we need a new financial system, to me this is really probably the fullest answer of why we need a new financial system.
unless you have any objection, I'm not going to keep going through this part because I just wanted to give you a feel for this, but if you would like me to, I can continue on through the summary requirements or I can move on.
>> why don't we move on?
>> that might be the answer.
i also want to talk about the things that are in that document are the functional requirements and then at the end there are some technical requirements as well.
but there are quite a few other types of requirements that we have and I just want to touch on them really lightly.
they are not in your backup but I just wanted to mention them.
first of all, we have these things that we already went through, the detailed requirements, I'll get to that when I go over the valuation methodology a little bit on how they are going to be answered, but they are fairly close to a yes or no type question.
there's a few more options.
there's going to be a drop down menu where they pick whether they have this fully operational right out of the box or whether it's a configuration and there's other ones I'll go through.
there's a whole set of we call them narrative response questions, but I think of them as like essay questions because that's really what they are.
they are more open-ended questions, tell us about this process or tell us how you do this and we have 163 essay questions that are spread through the requirements as well.
and for example, in the -- just for the functional requirements still there are 63 of those type what I'll call essay questions, and they relate to the functional requirements, and for each of those functional areas there's anywhere between one and eight of those type of questions.
in addition, there's 19 technical essay-type questions and they cover topics that range from application environment, application security, work flow, reporting, business intelligence and data warehousing and that's really trend analysis for casting the ability to do like what if analysis.
so that gives you a little idea of what other types of technical things we're asking and making them give some essay-type responses to.
there's also 42 implementation services, essay questions, and they cover topics such as implementation plan, training, data conversion, customization, change management, testing and business process, gap analysis.
and then there's -- as well there's 41 what we call post-implementation services essay questions, and that's really maintenance, support and future capability type things so we're covering topics such as support issue escalation, the county roles and staffing requirements necessary for each individual proposal, ongoing training, and then sort of the modification update and release scheduling.
there are also -- we have some requirements that are detail our desired work flows and we've identified 33 types of work flow requirements.
and just to give you a feel, that includes things like the personnel action, you are probably familiar with the p.a.f.
application.
we don't want to lose that type of functionality as well.
purchasing recollect visions, budgeting adjustment.
something new that we're asking for would be like time and attendance, entry and payroll so people don't have to fill out paper time sheets anymore.
we also have volume requirements and we have right now 37 different types of volume requirements.
and those are things like for the different functional areas we identify things of, like, how many requisitions we would have at any one time, the number of job applicants, for example, on the h.r.
side, number of payroll deposits and checks so that they have a feel for the size of the types and the numbers of transactions that we're going to have.
we also have specific data conversion requirements and there are requirements for 36 types of data that must be converted from the old system to the new system.
and I want to make sure when I say 36 types of data you don't think there's only 36 records that, you know, types of records.
when we say data types, we mean like a grouping of different fields that need to be converted, and that's actually going to be one of the more complicated things because as susan mentioned we're out of account numbers and we're going to have a completely different chart of accounts for this so there's going to have to be quite a mapping to bring financial data, you know, if you have this account number, now it's this account number and it's not going to necessarily be a one to one matching because the problem is we don't have enough account numbers.
so data that's in one account number may have to be split depending on what it is into different account numbers.
there's also interface requirements and, like, as you can see from the functional requirements where we talked about the current functionality, right now we have a lot of interfaces to h.t.e.
from sort of various work-around type systems that have been designed both by our office and other offices.
and the majority of these are going to go away with the new system because we're going to try to integrate those into the system itself.
but we still -- so right now we've identified only seven interfaces that may be needed in a new financial system.
and that's going to include things like being able to -- like I had mentioned being able to bring in data from the -- the caption investment manager as far as from like the emphasis system for purchases of investments that the county makes.
and the last type of requirement is the cost proposal requirements.
and on that we have 20 pages of cost proposal requirements and these are very detailed because we'll be evaluating the total cost to the county, not just the cost of the software and implementation but long-term maintenance, what county resources are needed as well.
and one of the big things is including the costs for each proposed customization.
obviously we hope to have as few customizations as possible because those are typically very expensive.
getting this information, though, will give us the ability to determine if there is customization costs that can be foregone if the county changes policies or procedures.
and so once we get some of that back, it's going to -- there's probably going to be some additional discussion and things may come to the Commissioners court saying, well, this customization is going to cost this much money.
if we did something differently, we might not have to customize this system and you could save x dollars.
>> those are like change orders, kind of like changes orders or the impact?
>> no, our goal is we're trying to identify all the customizations that are required up front, make the decisions on what ones we're going to get and what ones we're not going to get.
so those would still be part of the negotiated contract.
our goal is -- I mean it may be an unreasonable goal to have no change orders to this once you've signed this contract, but we are certainly going to try to have, you know, none, and if not none as far as possible.
that's one of the things that boggs this down too.
you get told this system is going to cost this much and somewhere down the line someone says I need ten more people or I forgot about this and we have to have this modification.
hopefully by doing all this work up front we're going to eliminate most if not all of that problem.
i guess with that, I'll talk very briefly about the schedule, which is the next page after the summary of requirements.
and this schedule is split between the procurement schedule and the implementation schedule and I'm not going to talk a lot about the implementation schedule because this is really sort of our best estimate of how that implementation will work, but we are asking the proposers to tell us also what the best way to implement their system is.
so we do -- are going to try and -- we have kind of a hard deadline that we want to complete the implementation by June of 2013.
which is on that bottom schedule.
but as far as which pieces are implemented in which order we're going to leave some of that until at least we see some proposals and can analyze that.
but the top half the the procurement schedule and we've cut everything that's happened in the past, not to rehash what we've done so for on this project.
it starts with July 1st, which is the date we plan to issue the r.f.p., assuming, of course, that you approve it.
but from that point we're going to have a three-month period to let the -- you know, for people to respond to the r.f.p.
and get proposals.
and then we have a three-month period in order to complete evaluation matrix 1 and identify the proposers to be elevated to the demonstration phase.
i'm going to cover this when I go through the overview of the evaluation methodology.
but that's a very short time period.
we don't know how many proposals we're going to get and so everyone has agreed we're going to have a fairly small team go through that matrix 1 which I'll explain in a little bit just because they are going to have to work on it full time during that period.
everybody is really comfortable with the requirements they have.
everybody signed off on them and they've agreed it makes sense to have a small team do that first part.
the next part is we have six months set aside to do the vendor demonstrations and complete evaluation matrix 2, and the purpose of that would be to identify proposers that would be related to the contract phase.
this is one of the key drivers of the whole schedule for us to complete this on time because we have -- we're going to have to have all the functional areas participate in these demonstrations and evaluation phase and this is really the time that works for the group of people from all the offices to do that.
so this is a key part that we can't really let slip, that we're able to do this part evaluation matrix 2 during that time period.
hopefully by June 30th of 2010 we'll have selected vendors that are elevated to the negotiation phase and we've given ourselves five months for contract negotiations in order to have the contract signed by November 2010.
assuming that happens, that's in fiscal year 2011 so that means that funding would have to be budgeted in fiscal year 2011 for this project.
so not in your coming budget year but the one after that.
>> do you want to briefly go back and talk about the demo.
>> I was going to get to that and evaluation methodology, but I can talk about it now.
just to make it clear, when I say vendor demonstration, what we really plan to have there is scripted demonstrations by the proposers that we've elevated to that phase.
and that means we're going to give them county data, we're going to give them sort of a script.
this is we want it to look just like this or we want you to show us how you do these processes.
so they will have to populate their applications with our data, you know, at least a subset of data that we've given them and show them how we would do our business with their system.
that's why it's so key to have everybody from the different functional areas, and to do this they have to be there -- for example, if we had three vendors doing these demonstrations, if you are going to evaluate the h.r.
modules, for example, you have to be there for each one of those and so it's really a key thing to have those people there.
>> do the representatives I guess from the functionality end of that, witnessing what the vendors actually will be demonstrating at that time, I guess do they understand that this particular phase of it is very critical because of the fact that they will be demonstrating something at the end of the day someone will have to make a determination is this really what you want?
>> right.
>> that's what the bottom line, is this really what you really want because after you let the calf out the gate, you know, he's out.
>> that's right.
>> so, you know --
>> you are exactly right.
>> so that's very important.
and I hope that this functionality committee and those folks that you have served have put on board, I guess, in this process need to be on top of this because that modification stuff ends upcoming in after.
that that's where it really gets expensive when those persons that are looking at this on the front end aren't around at the tail end and, of course, we end up having to look at expenditures that go beyond what we did anticipate.
so that's exactly what can happen if it's not done correctly.
>> yes.
with that, I guess I'll move to the overview of the evaluation methodology.
and I'm going to skip the first couple pages and start on page 3.
the first two pages are really just a summary of the process.
i'll try and go through this pretty quickly.
but definitely if you have questions on this part, ask.
but there are four main steps to our evaluation methodology.
the first is the mandatory requirements and those are on page 3.
those will all be sort of reviewed by purchasing except for 4 d, which will actually sort of be done in the next step, but it's still a mandatory requirement.
so purchasing will go through these and if they don't meet these mandatory requirements, they are going to be classified as nonresponsive and we won't evaluate them any further.
these were things that everybody decided you have to at least meet this before you can go forward.
so I'm not going to go through all those unless there is something there that you have a question on, but those are, you know, pretty much deal breakers so that's why they are there as mandatory requirements.
the last one of those, the 4 d part, is actually kind of carries on to looking at the functional requirements.
the 7,000 detailed functional requirements.
and what we did is if you look at page 5 under 1.0, which is the functional requirements and functional narrative requirements, just under the functional requirements there's 2500 points that can be maximum, that can be given out, and we've listed all the functional areas.
if you look in the column that says minimum points for consideration, after looking at all the requirements for these first areas here, we sat a set if you don't meet these points, we're not going to evaluate you any further so they sort of move back into the mandatory requirement.
and it's, you know, essentially about you have to meet at least two-thirds of those.
that's kind of the rule of thumb there.
and just briefly I guess I'll switch back to page 4 because I wanted to explain this is what I had been talking about earlier.
those functional detailed requirements, they are going to be presented in excel spread sheets by each of the functional areas and there's going to be a drop down box so there will be a requirement and they will have to answer whether it's fully provided out of the box, provided through configuration, provided through a reporting tool, whether third party software is required, provided to a technical modification or customization, whether it's not available or whether it's in another test version.
if they give one of the first three answers they get one point if they have that requirement.
if they say third party software is required, they get .6 of a point.
if they get one of the other three answers they get zero points.
those are the customizations or it's not available or it's in beta.
we're trying to start where we're looking at those functionality, we're giving preference where we have that functionality more or legals from day one -- more or less we don't have to get a modification and pay less.
that's the reasoning behind that.
so going back to page 5, once we get through the minimum requirements assuming that you make it through there, we'll finish out giving points for the functional requirement.
those sort of drop down box.
then we move to the narrative responses which are the essay questions for the functional and those make up 15% of the score for those first evaluation matrix.
and remember, this matrix is basically to elevate a smaller number of vendors to the demonstration phase.
that's the purpose of this first part.
going to page 6, the next main area is the qualifications and experience of the implementation firm and the individuals comprising the project team.
and that's worth another 20% and it's broken down into the categories you can see there.
the third area of evaluation is the qualifications and experience of the prime software vendor and their third party software vendors.
just to clarify, there's going to be two contracts that are associated with this r.f.p.
one is for a prime implementation firm, which is the -- the vendor who is going to come in and implement this system.
and then there's also going to be a contract for a software vendor.
it's possible that those can be one and the same, but they would still have to sign two different contracts.
so again, and then the last -- or not the last, the fourth sort of criteria that we're evaluating here is implementation approach and there's 10% of points for areas listed there.
and then we're also evaluating the technical requirements and the technical narrative responses of 10% of the score is based on that.
and the last area is the post-implementation services.
again, that's sort of the maintenance and support area.
and so 10% will be given to that.
so with all of that there would be 10,000 points if you were perfect, which I doubt anybody will be perfect, but at that point we will then, you know, have scored all of these vendors and will decide to elevate the higher ranking ones to the demonstration phase.
that's really step 3 is doing those demonstrations and that's the part where we'll go through the second matrix and it involves the scripted demos that I had talked about.
so -- and the purpose of that then is to try and narrow down who we're going to actually try and negotiate a contract with, and the hope is that we would have more than one that we can negotiate with because that would give us a little more -- probably a little more leverage as far as negotiating those contracts.
and in case -- just to point out, that matrix 1 where we're just elevating to the demonstration, we're not specifically evaluating the costs, and part of the reasoning behind that is everybody has sort of agreed these are their requirements.
so we're going to evaluate them on their response to those requirements.
as I mentioned, the customization cost is included in that matrix 1 as well.
but when we get to matrix 2, cost becomes a major factor.
once we're evaluating these and I'll get to that in a minute.
there's really four parts to this matrix.
one of which is a new addition which I'll talk about at the end.
but the functional and technical demonstrations, that's based on their scripted demos and we're going to evaluate the different functional areas on those scripted demo that is they do.
the second part is the cost of ownership and that's 27% of their score for that.
and we are looking at the total cost so the initial costs, the ongoing costs of ownership and the quantity and resource types that are needed to support the system after implementation, that's where I'm really getting at.
you know, if there's a cost to the county because we need some additional resources, we're going to capture this cost as well.
like I said, we're trying to come up with the total cost of ownership when we're evaluating the cost.
the third area is the interview, site visits, references and demonstrations, and you can see we plan to probably -- one of the things we'll do is talk to some of their references.
we may make a site visit or two.
we have budgeted for that so that will be part of the evaluation process once we're down to a smaller number of vendors that we're focused.
on the last item is a new item and that's the contract terms.
that was based on dean's recommendation which we thought was a really good recommendation which is we are -- included in this r.f.p.
is two contracts, one for the prime implementer and one for the software vendor, and the terms are already into those and the closer they stick to those terms, the more points they are going to get.
because those are the terms that we would like so it makes a lot of sense, I thought, to give points to -- the most favorable contract terms.
that should make it go a lot faster in the negotiations the more of the terms that they accept up front so that should help us in the negotiations.
>> the distribution on the matrix 2, is that what I'm seeing?
step 4 for evaluating the contract.
>> yes.
yes.
>> parameters.
and that's the reason why cost of ownership has gone down from 30% to 27%?
>> exactly.
>> so that fourth category will score at what?
>> 9% of the total.
>> 9%.
>> we thought this was a really good idea that we had pretty well put together the matrix.
>> no, I totally understand.
i just wanted to follow it.
>> sure.
so that brings to us the final step, which is the -- basically the negotiations phase.
and like I said, hopefully, you know, the more contract terms they've accepted will be more dealing with negotiations on what we want as far as actual parts of the system instead of arguing over contract terms.
that would be a major benefit and would speed this process along.
but nonetheless we have five months set aside for that and I think -- I'm very hopeful we'll be able to meet that time period too and if we do, then we would be looking at coming back to the court.
obviously there is going to be parts along the way where we're going to come back to the court, but as far as making a final recommendation on a contract award, we would hope that happens in November of 2010, which, again, is fiscal year 2011.
i guess in conclusion, you know, again, we're asking you to authorize issuing this r.f.p.
now with the understanding that the r.f.p.
will be issued after the completion.
we still have a little bit we're still working on a few minor things on external legal review and then a final county review, but if you approve us issuing this now, we would go ahead and still anticipate issuing it on July 1st.
>> and dean is available for comments or questions that you have.
>> I don't know if anybody else wants to see anything.
>> we have other departments here if you would like to come up and say anything.
any of you?
or if you have questions for them.
>> questions?
>> I have -- in regard to that fourth step, I'm assuming that in some ways that works in tandem with cost of ownership because I imagine there will be, you know, as you look at the contract negotiation aspects, there might be some elements that we would fear would cost us more later if -- if we didn't negotiate them to our satisfaction.
>> and this is sort of the area that I was talking about earlier where there's probably some areas where we might come back to y'all and say, look, this part here is going to cost x dollars.
if we were able to change the way we do business, changing county policies or department policies or procedures, you know, we could save this amount of money because we could do this through configuration, which is not going to cost anything like a modification to the actual software.
that would be part of this step, I would assume, that we would -- there may be some things we will bring back to you and identify some costs that if you were willing could be foregone at that point.
there may also be some things, though, where you say this is our policy and, you know, there's no way we're going to change this so we just have to buck up and pay this.
>> what are your thoughts on that?
>> with respect to the contract terms --
>> yes.
>> I think that you are absolutely right.
i think that part of what the team has done also to deal with this is have a lot of specificity.
the vendors will price risk, they will add to the cost of risk.
having specific contract terms and tying that to the evaluation, the competitive process I think is overall going to drive price down.
>> okay.
i want to commend you all on putting together the -- the incredible work you've done in putting together an evaluation team.
it's a pleasure to see an evaluation team that is crosswalked like this and working so closely together in a sense that everyone is being heard and what the time is well spent because it's a huge time commitment.
>> any comments from anybody else?
>> I would like to ask mike one more time, you've laid out a number of functional requirements and looks like an intimidating set of requirements, but you actually expect this to be a very competitive number of vendors that are going to be proposing on this.
>> actually I'm a little watered and maybe optimisticly so, but I actually think that laying out all the requirements serve us really well but serves any potential proposers because they have a very good idea what we want.
there's not a lot of things they can say they probably mean this.
we have very specific requirements.
so I think there will be a fairly large pool.
there's not a huge pool of software vendors that can probably meet these requirements, but there will be a fairly large pool of implementers who can -- who would probably want to make a proposal so we may find ourselves with more proposals than anticipated even.
i really don't have a good feel for how many proposals we'll get and obviously the more we get that pass through that sort of mandatory requirement, that's really going to be a lot of work to get that first evaluation period down.
but to answer john's question, I think this will be very competitive.
>> so we have in each department some indication of current functionality, what process improvements they would like to see and then a sort of wish list of -- if all my dreams came true, this is what I would like to see.
>> but everybody does understand there's no guarantee you are going to get everything you are asking for.
it may be too expensive, you know, but if we don't put all those in there we won't get a cost for those things and you won't be able to make the determination.
i think this is really a good get modification to use to be able to see what all these requirements will cost and then we can make some choices if cost becomes an issue.
>> and have we renovated the rusk building?
>> yes.
>> to use for this project?
>> yeah, and there are some people over there already.
the project team from our office has already moved over there and there permanently and at least one of the people from purchasing has already moved over there.
there's a few more people that are going to move in there as this project ramps up and we get past this stage.
the only thing I was going to point out, I mentioned the visited demos and the -- scripted demo so we're going to be busy to next three months while we're waiting to get the proposals back doing that.
>> the changes you plan to make between now and July 1st are minor in the scheme of things?
>> yes.
if there was anything that contradicts what we've talked about, we would come back.
we would ask you to put this on the agenda on the 30th if you are willing to vote for this today.
>> for the court member who wants to see the full 700-plus pages, they are available.
>> they are available.
if you want it, let me know because we can talk about how to make that available to you.
we could put it on a c.d., for example, or I think we could also maybe talk with i.t.s.
about putting it on a website that you could look at or link it somehow.
but at the very least -- and obviously we would print it if you want, but I sort of think, you know, if you want it on a disk, that would probably be the easiest way.
>> save the paper.
>> let me know if you do want it.
>> any unreadiness or anybody need to take a week?
then I move approval.
>> second.
>> and authorize issuance of the r.f.p.
on or about July 1, 2009.
>> thank you very much.
>> thank you.
>> hold on.
>> I jumped the gun a little bit there.
>> all in favor?
that passes by unanimous vote.
>> thank you all.
>> thank you very much, attorney, for visiting with us.
>> thank you.
and we appreciate the hard work and dedication of all the committee members.
The Closed Caption log for this Commissioners Court agenda item is provided by Travis County Internet Services. Since this file is derived from the Closed Captions created during live cablecasts, there are occasional spelling and grammatical errors. This Closed Caption log is not an official record the Commissioners Court Meeting and cannot be relied on for official purposes. For official records please contact the County Clerk at (512) 854-4722.
Last Modified:
Tuesday, June 23, 2009 1:31 PM