1 / 17

About Me

The Project That Never Ends: Development of an IT Infrastructure Chargeback Model Master’s of Engineering Project Corinne Price 12 August 2014. About Me. Qualifications & Experience.

shalom
Download Presentation

About Me

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Project That Never Ends: Development of an IT Infrastructure Chargeback ModelMaster’s of Engineering ProjectCorinne Price12 August 2014

  2. About Me Qualifications & Experience • Over 7 years experience providing business operations support through financial analysis, cost estimating, metrics and reporting, risk analysis, quantitative analysis, project management, and client briefing. • Spent 3 years with Accenture LLP on the Interim Transition Capability (ITC) program supporting the client’s data center by building a fractional chargeback model for IT infrastructure

  3. Project Overview Background • Hired to Accenture in October 2009, specifically to join the Interim Transition Capability (ITC) program as the Technical Cost Estimator • Supported the Business Change Management team • Managed and maintained the entire cost modeling project while employed on Accenture’s ITC program • Built a fractional chargeback model which captured the data center’s IT infrastructure and was used for transitioning and virtualizing applications • Iteratively updated to incorporate changes to the data center, as well as modifications to cost estimating relationships for the labor calculations • Enabled the ITC program to successfully complete estimates in support of business cases for virtualizing infrastructure and transitioning into the data center

  4. Initial Model Development Identifying the Problem – Consolidation Effort • Government recognized the need to consolidate IT infrastructure • Offices previously procured infrastructure for each individual application, in many cases without knowing the exact system requirements • Caused for over spending on the hardware and software operations and maintenance, as well as the labor to maintain • Two main focuses for consolidation: • Virtualize applications during the transition process in preparation for moving to a “cloud” environment • Cost savings by reducing the infrastructure foot-print and associated labor to maintain

  5. Initial Model Development Identifying the Problem – Established ASP-ISP Relationship • Government client established an ASP-ISP relationship for their applications and associated infrastructure • ASP – Application Service Provider – is the application developer who builds and maintains the application • ISP – Infrastructure Service Provider – provides the infrastructure for IT services through the operating system • ASP pays a fee to hosted by the ISP • ITC program served as an ISP for the Government client • Client provided the initial seed money, i.e. the base contract, for the ITC stand-up and first hardware purchase known as capacity • ASPs that transitioned into the data center owed the client program office funding for the amount of resources being consumed by their application

  6. Initial Model Development Identifying the Problem – Early Estimation Practices • Estimation was ad hoc and based on personal option • ITC held technical exchange meetings (TEMs) to gather the system requirements • Transition Managers, who sheparded the application through the transition process, roughly estimated the cost based on actuals from analogous systems • Government client and ITC Program Office understood the importance of a consistent approach to cost estimating • Needed estimates to be able to stand up to the scrutiny of the ASPs

  7. Iterative Model Development How the Problem was Solved • ITC created the Business Change Management team • Included 6 resources who contributed to and managed the requirements management process and cost estimating functions • Technical Cost Estimator, Systems Engineer, and Procurement representative were direct contributors to the development of the model • Transition Managers worked with new ASPs who were transitioning applications into the data center • Customer Relationship Managers (CRMs) worked with ASPs already hosted in the data center who needed to modify their infrastructure footprint • Transition Managers and CRMs held technical exchange meetings (TEMs) to gather requirements for the new transition or system modification • TEMs included ITC engineers from each functional area and the ASPs engineers and management

  8. Iterative Model Development How the Problem was Solved • Initial hardware models were for storage and server calculations only • First iteration combined these models and began to add in peripheral equipment such as networking and software licenses • Next iteration included separate hardware and labor models • Combined into one model where basis of estimates were used to determine the labor costs off of the hardware inputs • Storage and server requirements drove the networking needs; databases required additional storage and server • As the procurement lead purchased new equipment for the data center, the model would be updated to include • Worked with the Data Center’s Chief Architect to understand the new relationship of the hardware and/or software to that already included

  9. Iterative Model Development How the Problem was Solved • Labor calculations proved the most difficult to capture • A lot of the basis of estimates for non-recurring, initial stand-up, and recurring, operations and sustainment, were based on expert judgment • Non-recurring labor was the labor required to initially stand-up the application in the new data center • Met with engineers on a regular basis to understand the size and complexity of the transition or modification which would drive the labor needs • Recurring labor was driven by the basis of estimates (BOEs), which related the infrastructure requirements to labor hours required to maintain • Continually worked with the functional area leads to refine these estimates and better understand the regular tasks performed and the amount of time they consumed

  10. Model Inputs & Outputs Information Required for Model Costing

  11. Model Inputs & Outputs Information Required for Model Costing

  12. Model Inputs & Outputs View of the Model’s Input tab

  13. Model Inputs & Outputs View of the Model’s Output tab • Dollars are represented in thousands • Estimate includes contingency to account for risk; typically used 10% • ODCs refers to Other Direct Costs • Includes travel, training, and supplies; incorporated on an as-needed basis • GFE refers to Government Furnished Equipment • Software or hardware provided by the Government client, which does not represent a cost back to the users

  14. Model Uses Benefits • Allowed for the Government client to bill other entities for the fractional piece of the service they were using • First step to the organization eventually building a fee for service model for cloud computing • Aided in the justification for the need of the ASP to go from a physical hardware environment to a virtualized one • For this purpose, the model would calculate the cost of transitioning and maintaining a physical environment and cost for transitioning and maintaining a similar virtual environment to demonstrate the potential return on investment (ROI). • Labor calculations were converted to FTEs and used to justify internal Accenture staffing levels on the projects and proposal pricing efforts • Fractional hardware calculations from all of the estimates were combined to help manage infrastructure capacity • Informed when they needed to be ready to procure new equipment

  15. Conclusion Final Thoughts • Importance – First model of it’s kind developed by for the client • Either did not have the cost expertise on staff to build the model or did not have the access to the resources to gain insight into the infrastructure relationships and operational constraints • Allowed for better budget planning • Final Numbers – Completed 48 instances of the model, which included 16 significant versions • Cost estimation model is a “living” document which requires continual updating to match the data center’s architecture • Lessons Learned – Worked more closely with the ITC Program Controls team to better capture actual dollars and hours associated with each transition • Would have allowed for better comparison to the model and ability to test accuracy • Next Steps – Updated the model for “metering” or exact fee for usage • Would have required a tie-in with the infrastructure monitoring tools

  16. Model Demo

  17. Questions

More Related