[Editor's Note: This is part of a series written by CIOs discussing their thought processes and lessons learned from major events in their tenures as CIO. Check back tomorrow for a companion post to this one.]
Several years ago, I was faced with the need to provide a more robust architecture for our web-based operations. As an organization, we had made a major commitment to delivering
government services online whenever possible. This was a strategic direction that also had the commitment of the governor. Our network traffic was growing rapidly and we were in the process of adding new online services that would potentially add millions of new visits to
our domain. Off-hours traffic was also growing so we needed to ensure reliability through a redundant architecture that would provide fail-over at any time.
Our central IT organization operated as an internal service fund, meaning that it had to cost recover all expenses through rates charged to the various agencies that used our services.
For that reason, it became important for me to understand what the needs of each of those customer agencies were with respect to this equipment and if it was something that could be justified from their perspective. Ultimately, I would need to be able to cost recover this
expenditure within a reasonable time-frame.
The first step was to determine if this expenditure was really a priority when compared to all of the other needs of the organization. The state legislature sets dollar limits each year on internal service fund capital expenditures, and requests to expend these funds almost always exceeded what was available. After analyzing the growth in web traffic, particularly that traffic associated with the delivery of online services, I made a quick determination that we really should move forward with the expenditure in order to adequately support the business requirements of the combined agencies.
The next step was to prepare a business case that clearly identified all of the costs and benefits of the proposed purchase. I involved our network planning team and tasked them to look at various alternatives. This would include identifying various potential vendor solutions making sure that they would function well within our enterprise architecture and then preparing more detailed cost estimates associated with these alternatives as well as the advantages of each alternative.
After these alternatives were ready, I had staff from the other areas of operations and engineering review and comment on the preferred solutions. In particular, I made sure that security, hosting (system administrators), and the software engineering manager all had a chance to provide input. Because this would potentially impact the performance of each of their products, I wanted to make sure that they contributed to crafting the solution.
Once we felt comfortable that we had identified a requirements set that would meet the needs of these various sections, as well as the growing demand from customer agencies, we were ready to draft a request for proposals (RFP).
Government RFPs can be a challenging process, both for the agency that has to develop the RFP as well as the vendors that wish to respond. Occasionally, vendors will question or challenge the requirements that were outlined by the agency. In order to optimize this process, I always tried to make sure that we drafted RFPs that were concise and direct, with clear language and easily understood requirements. With this RFP, I wanted to make sure that any reliable vendor that could meet these requirements was able to bid. Hopefully, this would ensure that we received a reliable and low-cost solution that would meet all of our needs.
In a few weeks, we were able to complete the RFP process and begin implementing a solution.
In my next blog post, I will let you know how it turned out and discuss what I have learned from going through this and other capex purchases.