IT Dashboard Feasibility Report-Final

8/3/2019 IT Dashboard Feasibility Report-Final

1/33

FEASIBILITY REPORT

Implementation of IT Project Dashboard

for

City of New York

Department of Transportation

Author: Sheldon Rampton, New Amsterdam Ideas LLCCreation Date: January 8, 2012Last updated: February 6, 2012

Version: Final 1.0


2/33

IT Project Dashboard Feasibility Report, page 2

Table of Contents

1. Summary ........................................................................................................................3

2. Assumptions ...................................................................................................................5

2.1.First Assumption: Common Drupal ModulesCan Be Used to Build the Proposed DOT Dashboard ............................................5

2.2.Second Assumption: Methodology forCalculating Cost, Schedule and Quality .................................................................7

3. Conclusion ...................................................................................................................10

4. APPENDIX 1: Questions and CommentsRaised by DOT Staff, and Our Responses ...................................................................11

5. APPENDIX 2: Request for Estimate DocumentProvided to Drupal Developers ....................................................................................14


3/33


1. SUMMARY

After examining the codebase of the Federal IT Dashboard, I have outlined an approachfor creating a DOT Dashboard for use by the New York City Department ofTransportation and have obtained time/cost estimates for doing the work from two Drupal

developers in addition to myself. (My personal hours estimate appears as row #3 in Table1 below.) I also obtained an estimate from a software development company that uses anoverseas development team to do some of its Drupal development and is therefore able tooffer a lower hourly rate than the other developers. Based on those conversations, theprice I estimate developers would charge for building a DOT Dashboard should besomewhere between $23,600 and $90,200, as summarized in the following tables.

Table 1. Time/cost estimates from three U.S. Drupal developers

Min.

hrs

Max.

hrs

Best

guess

Min. $

at $110

Max. $

at $110

Best

guess

at $110

Min. $

at $185

Max. $

at $185

Best

guess

at $185

#1 214 302 258 $23,581 $33,308 $28,444 $39,660 $56,018 $47,838#2 370 487 429 $40,713 $53,621 $47,168 $68,473 $90,181 $80,327

#3 282 366 324 $31,107 $40,305 $35,705 $52,316 $67,784 $60,050

Avg 289 385 337 $31,800 $42,411 $37,105 $53,483 $71,328 $62,738

Table 2. Time/cost estimates from U.S./overseas combined team

Min. hrs Max. hrs Best guess Overseas

contractor

team cost

Domestic

prime

contractor

team cost

Total cost

389 524 457 $16,600 $14,800 $31,400

The two tables above assume two different approaches to estimating and performing thework.

To arrive at the estimates in Table #1 above, I broke the work involved inbuilding the DOT Dashboard into subtasks and asked Drupal developers toprovide hours estimates for each task. In addition to the specific tasks for whichdeveloper provided estimates, I added an additional 20% apiece for (1) projectmanagement, (2) requirements gathering and discussion, and (3) qualityassurance, which we feel is a reasonable estimate of the time that most Drupaldevelopment shops would expect to bill for those purposes. I then used the three

point estimation technique to arrive at a total hours estimate for each developer.Estimated costs were then calculated based on two separate hourly rates. The$110/hour rate is what we have previously paid to one of the developers above forhis services as a Drupal developer and is a reasonable estimate of the currentmarket rate for good individual Drupal freelancers. The $185/hour rate is NAIsstandard billing rate and is in the middle of the price range charged by Drupaldevelopment firms.


4/33


To arrive at the estimates in Table #2, we contacted a software developmentcompany with which we have contracted on a previous project. They use a teamof overseas developers to do some of the actual Drupal programming and aretherefore able to charge a lower hourly rate. The company provided a dollar andhours estimate following a somewhat different breakdown of tasks than the list I

provided them. Their estimate of cost was based on the assumption that some ofthe work would be billed at a rate of $50/hour (for their overseas team), and somewould be billed at $120/hour (for their U.S.-based project manager). In our pastexperience, working with an overseas team has required that we do a significantamount of project management, requirements gathering and quality assuranceourselves, so we added $14,800 as an estimate of what it would cost if a domesticprime contractor provided 80 hours of those services at a rate of $185/hour.

These hours and dollars estimates assume that the DOT Dashboard should imitate thelook and feel of the Federal IT Dashboard but that developers will need to fundamentallyrewrite the logic which imports and stores data as well as the logic which renders that

data into tables and charts. My estimate also makes some assumptions about revisionsthat should be made to the design of the website, which I believe will still provide mostof the essential functionality while eliminating some details that I think are mostlycosmetic. Those assumptions are outlined below.


5/33


2. ASSUMPTIONS

2.1 First Assumption: Common Drupal Modules Can Be Used to Build the Proposed

DOT Dashboard

The original Federal IT Dashboard was built by developers who were obviously skilled atwriting procedural PHP code but evidently lacked experience using some of the standardDrupal modules such as the Fields, Feeds and Views modules. They also faced thechallenge of needing to build a website capable of importing, parsing and graphing dataembedded in complex XML-based forms used by the federal government known asExhibit 300 and Exhibit 53 documents.

The HTML and CSS code that was used to create the Federal IT Dashboard can be reusedfor the DOT Dashboard. However, the data source for the Federal IT Dashboard differssubstantially from the data source the DOT Dashboard. It would therefore be impracticalto attempt to reuse or adapt the code which imports and calculates results from that data.

New code will have to be rewritten for this part of the DOT application.

Fortunately, the DOT data as provided in DOTs spreadsheet samples is simpler instructure than the Federal Exhibit 300 and Exhibit 53 documents. In addition, I amproposing the use of standard Drupal modules to reduce the amount of customprogramming that will be needed to build the website.

The Fields module can be used to create custom Drupal content types via a web interfacewith minimal custom programming. Each content type has its own defined set of fields,each of which corresponds to a column in a spreadsheet or database. When importingdata from the DOTs spreadsheets, therefore, each row of data in the spreadsheet wouldbe used to create a separate Drupal node,1 with each column in that row being used topopulate a separate field in that node. Each row in an imported spreadsheet wouldbecome a separate node with a content type of Project Status Report and fields such asProject ID, Project Name, Overall Status, Hours Planned, Hours Spent, etc. UsingDrupals computed field module, eachProject Status Reportwould also calculate valuesneeded to display cost, schedule and quality information. In addition to the Project StatusReport content type, the website would define several other content types to help inorganizing and displaying the data. Those content types would include:

o Projecto Functional Teamo Divisiono Division Status Reporto DOT Status Reporto Milestone

1 All content on a Drupal website is stored and treated as "nodes." A node is any posting,such as a page, poll, article, calendar item, forum topic, or blog entry. The nodescontent type specifies what fields it contains and how it should be displayed.


6/33


The Feeds module can assist in importing data. Feeds provides a web interface fordefining mappings between a structured data format such as a spreadsheet or CSV fileand a Drupal content type. The DOTs data about its projects can therefore be convertedfrom existing Excel spreadsheets into Drupal nodes. Some custom coding will benecessary to summarize and organize the data so that it is easily retrievable for display,

but the basic importation can be done using functionality that is already available.The Views module can be used to create tabular reports like the ones that appear in the

Federal IT Dashboard. I should note that some of the interactive functionality of theexisting Federal IT Dashboard might be difficult to replicate using different modules. Forexample, clicking on a particular slice in a pie chart on the Federal IT DashboardsFederal Department Portfolio page changes the selection criteria and tabular resultsdisplayed at the bottom of the page. Implementing this click to change selection featurerequires some Javascript trickery that might be time-consuming and therefore expensiveto implement. However, the same basic ability to change selection criteria could beimplemented more easily using the standard exposed form filter feature that is providedby Drupals Views module. For the purpose of this estimate, I have assumed that standard

Drupal exposed form filters will be acceptable to DOT.

There is a Google Chart API module that can be used to create 3D pie charts and

other graphics, as well as a Fusion Charts module that can be used if needed to createFusion Charts graphics. The Google Chart API module is already available for Drupal 7,whereas the Fusion Charts module is currently only available for Drupal 6 and wouldneed to be updated if the site is built on Drupal 7 (which I recommend). I am estimating20 hours of work to select, test and implement the graphics modules needed to build thewebsite. Those 20 hours are included in the total estimate figures above.

The Federal IT Dashboard was built using Drupal 6, and some work will be needed to

upgrade its theme2 from Drupal 6 to Drupal 7. However, I recommend implementing thedashboard in Drupal 7, which will be easier to upgrade and maintain in the future. I amestimating that the Drupal 7 upgrade will entail 24 hours of work, which is included inthe estimate.

The specifications I received from DOT included a request for functionality that woulddisplay project progress as a sequence of milestones similar to the cost detail andschedule detail pages that appear in the Federal IT Dashboard. However, the spreadsheetdata provided by DOT does not include milestone information, and it was not clear to mewhat milestone data is currently being collected or how it could be effectively integratedwith the existing spreadsheet data. My estimate therefore assumes between 20-60 hours

of work needed to implement milestone functionality, but this portion of the estimate isloose and might change depending on further specification of the feature requirement.Alternately, costs could be reduced by building the DOT Dashboard initially without amilestones feature in its first iteration.

2 A theme is the part of the code in a Drupal database that controls the overall visualappearance of the website. It specifies the HTML, CSS and Javascript that is used torender web pages and blocks of content within pages.


7/33


The specific tasks required to build the website can therefore be summarized as follows:

1. Upgrade existing Drupal 6 theme to Drupal 72. Implement charting module (Google Charts API, Fusion Charts or some other

option)3. Clarify specifications for milestones functionality4. Create Drupal content types

a. Projectb. Project Status Reportc. Functional Teamd. Divisione. Division Status Reportf. DOT Status Reportg. Milestone

5. Create processes for importing and entering data:

a. Creating Project Status Reportsb. Creating Projectsc. Creating Division Status Reports and DOT Status Reportsd. Manual Creation and Editing of Nodese. Automatic Updating When Nodes Are Manually Edited

6. Create display pages using Views and graphic charting modules:a. Home Pageb. Executive Level Portfolio

i. Graphicsii. View with exposed filter form

c. Division Pagei. Graphics

ii. View with exposed filter formd. Project Level Summary

i. Graphicsii. Summary text information

2.2 Second Assumption: Methodology for Calculating Cost, Schedule and Quality

When importing data from DOTs spreadsheets, the DOT Dashboard will use that data tocreate Drupal nodes of type Project Status Report. It will need to perform calculationsbased on that data to arrive at metrics which correspond to the charts and tables displayedin the mockups which DOT has provided. For example, the spreadsheets containinformation about number of hours worked but no dollar information. DOT has indicatedthat dollar costs can be calculated by providing a blended hourly rate figure for eachproject and multiplying hours worked by the blended hourly rate. To derive some of theother values that would need to be calculated, I have assumed the following formulas,which are adapted from an online tutorial on Earned Value Management(http://www.tutorialspoint.com/earn_value_management/index.htm). If some otherformulas are desired, DOT would need to provide specifications, which could in turn


8/33


affect the cost of implementation. The following formulas are assumptions upon whichthis estimate was based:

Hours Planned: taken from Project

Blended Hourly Rate: taken from Project

Start Date: taken from Project (also available from Project Report) Baseline End Date: taken from Project (also available from Project Report)

Hours Spent: taken from Project Report

Project Report Date: taken from Project Report

% Completed Actual = taken from Project Report

Baselined Cost (BC) = Hours Planned * Blended Hourly Rate

Budget At Completion (BAC) = total budget for the project (same as BC?)

% Completed Planned (%CP) = (Project Report Date Start Date) / (BaselineEnd Date Start Date)

Planned Value (PV) = Blended Hourly Rate * %CP3

Actual Cost (AC) = Blended Hourly Rate * Hours Spent4

Earned Value (EV) = Baselined Cost * % Completed Actual5

Cost Variance (CV) = Earned Value Actual Cost

Cost Variance % (CV%) = Cost Variance / Earned Value

Schedule Variance (SV) = Earned Value Planned Value

Schedule Variance % (SV%) = Schedule Variance / Planned Value

The formulas listed above should be sufficient to produce schedule and cost metrics. Theadditional formulas listed below may not be necessary to produce the graphics shown inthe Dashboard mockups but could be calculated and included at little additional cost. Thiscould provide options for producing additional reports if desired in the future:

Cost Performance Indicator (CPI) = Earned Value / Actual Cost

Schedule Performance Indicator (SPI) = Earned Value / Planned Value

Estimate At Completion (EAC) = estimated cost of the project at the end of theproject = Actual Cost + (Budget at Completion Earned Value) / CostPerformance Indicator

Variance at Completion (VAC) = Budget at Completion Estimate AtCompletion

To Complete Cost Performance Indicator (TCPI) = (Total Budget EarnedValue) / (Total Budget Actual Cost)

To Complete Schedule Performance Indicator (TSPI) = (Total Budget Earned

Value) / (Total Budget Planned Value)

If the above formulas are used, the Cost Variance % (CV%) and Schedule Variance %(SV%) could be used to provide the cost and schedule components used in

3 Also known as Budgeted Cost of Work Scheduled or BCWS4 Also known as Actual Cost of Work Performed or ACWP5 Also known as Budgeted Cost of Work Performed or BCWP


9/33


calculating overall project status. The quality component could be calculated asfollows:

Quality % (Q%) = CIO Quality Rating / Maximum Possible Quality Rating

Weighted status could then be calculated as an average of those three factors, as follows:

Combined status = (CV% + SV% + Q%) / 3

Alternately, weighting factors (WF) may be applied to each component when calculatingoverall status, as follows:

Combined status = (CV% * WF1 + SV% * WF2 + Q% * WF3) / (WF1 + WF2 +WF3)

Methodology for Calculating Aggregated, Weighted Values on Department, Team and

DOT-Wide Pages

When producing listings and that aggregate results from multiple projects (such asaggregate results for all projects within a department), the aggregated cost, schedule andquality results should be weighted according to project budget. For example, if adepartment has projects P1 and P2, the aggregate Cost Variance % (CV%) for thoseprojects would be calculated as:

CV% agg = (CV%P1 * BAC P1) + (CV%P2 * BAC P2) / (BAC P1 + BAC P2)


10/33


3. Conclusion

The approaches that we have outlined above for building the DOT Dashboard include theoption of (1) using a freelance developer; (2) hiring a U.S.-based development shop; or(3) using a development approach that combines a U.S.-based domestic prime contractor

with overseas developers to reduce costs. The third approach is likely to be the mostlikely to be realistic within DOTs budget constraints.

The codebase of the Federal IT Dashboard was released as an open source project in thehope that it could be reused for similar purposes by other government agencies. Inpractice, however, the main value of the Federal IT Dashboard therefore is not the codebut rather the specification and example it provides of how an IT Dashboard can look andfunction. This alone, however, is a considerable benefit. Much of the work that goes intobuilding a new type of website consists of formulating and refining specifications, andthe Federal IT Dashboard has already provided that template even if it is impractical touse most of its actual code.

We feel that there is a great deal of value in building a DOT Dashboard that usescommon Drupal modules to replicate the functionality of the Federal IT Dashboard. Thiscan be done at a fraction of the cost that went into building the Federal IT Dashboard, andthe result would be a truly reusable codebase based on common Drupal standards that canthen be reused, extended and adapted by others in ways that the current Federal codebasecannot. We believe that this would be of great interest to other governments as well andwill fulfill the initial promise of the proposal by Civic Commons to open-source theFederal project.

If DOT is interested in building the DOT Dashboard, New Amsterdam Ideas would behappy to offer additional advice on ways to further reduce costs, vendor selection, Drupalarchitecture and any other topics that may help bring this project to fruition.


11/33


APPENDIX 1: Questions and Comments Raised by DOT Staff, and NAIs

Responses

Question: Will there be significant cost/scope changes to implement the dashboard

using the latest version?

Since the proposed website would be largely rebuilt from scratch rather than modifiedfrom the existing codebase, I recommend implementing the site in Drupal 7 rather thanDrupal 6. This would require the following:

Converting the existing theme from Drupal 6 to Drupal 7.

Updating the Fusion Charts module from Drupal 6 to Drupal 7I have included the cost of these requirements in the estimate above.

Question: How many lines of code exist approximately in Federal IT Dashboard?What is the percentage of code that will be reused to meet DOT Dashboard objectives?

Is it worth reusing the code for DOT Dashboard rather than building it from scratch

on Drupal 7/MySQL?

I estimate that only 10-15% of the custom code used to build the Federal IT Dashboard isactually reusable for DOTs needs.

Since the visual design of the Federal IT Dashboard is the main part of the code that maybe worth reusing for DOTs purpose, I examined some of the .tpl.php (template) files thatdefind the IT Dashboards visual design. Drupal template files are normally used tocontrol visual theming of content on Drupal websites. A .tpl.php file is roughlyequivalent to a what is called a view in software that is built according to the Model-View-Controller design pattern. It is therefore intended to primarily consist of HTML

with very little programming logic other than the minimum need to reference and printvariables or loop through a list of variables. For example, a simple .tpl.php file mightconsist of the following code, which combines some HTML div tags with PHP variables

for$attributes, $content_attributes and $content):

>

Unfortunately, the developers of the Federal IT Dashboard did not follow the standardDrupal practice in creating their .tpl.php files. In addition to presentational code like theexample above, the IT Dashboards .tpl.php files contain extensive logic that retrievesdata from the database (the model part of Model-View-Controller) and also logicinvolved in parsing an manipulating that data (the controller part). The presentationlayer of the codebase is therefore entangled with the specifics of the datasets and datarelationships that are derived from the Exhibit 53 and Exhibit 300 documents. Forexample, file portfolios.tpl.php is a Drupal template file which defines how the


12/33


portfolio page should be rendered. File portfolios.tpl.php consists basically of

the following:

677 lines of procedural PHP code and function definitions needed to retrievesarrays of data needed to render the charts. This section of the code is heavilydependent upon the data derived from Exhibit 53 and Exhibit 300 documents. Not

only is this portion of the template file heavily procedural, it contains functioncalls which generate the various Fusion charts that appear on portfolio pages, andvariables that are defined by include files rather than through Drupals standardsystem for defining tpl.php file variables. For example, there is a variable named$pie3D. To discover how pie3D gets defined, I had to search the entire

codebase and found that it is defined in a configuration file namedcustomcode/fusionchartsfree.conf.php that is located inside the

Drupal root directory.

96 lines of HTML with some PHP variables inserted in traditional tpl.php fashion.This section of the code basically consists of the HTML which draws the portfoliopage, with some variables which drop in specific Fusion Charts, as well as some

help information for people who visit the page.

Only 12% of the code in file portfolios.tpl.php is therefore truly part of the

view or presentation logic. Identifying and isolating this portion of the file is fairlyeasy, but as this example illustrates, most of the code in the Federal IT Dashboard willprobably be simply deleted or ignored rather than reused or revised. The main value ofthe Federal IT Dashboard therefore is not the code but rather the specification andexample it provides of how an IT Dashboard can look and function.

Question: How many MySQL tables are needed for DOT dashboard if we get rid ofexhibits 53 and 300?

Since Exhibits 53 and 300 do not apply to the DOTs needs, we would not use any of the180 tables that the Federal IT Dashboard derives from them. Instead, we would use datastructures generated by Drupals Fields module. The Fields module stores its data inMySQL tables according to a scheme which creates one additional table for each datafield that is added to each Drupal content type. More than 50 MySQL tables wouldtherefore be created in the course of implementing a Fields-based DOT dashboard.However, the complexity of creating these tables and updating or retrieving their contentswould largely be hidden from site developers and site users. Indeed, the main purpose ofthe Fields module is to provide a mechanism for enabling developers to easily addcontent fields to Drupal websites via Drupals web-based administration interface without

needing to custom-code their own MySQL tables and queries.

Comment: For DOTs IT Dashboard, we will convert our planned and actual hoursinto $$ using one hourly rate for consultant projects and another for employeedeveloped projects. For projects where consultants and employees are involved, we will

establish a blended rate at project start. Corresponding data elements and entryoptions/screens should be considered in the proposal.


13/33


I am developing my cost projection for the DOT dashboard based on the assumption thatthe blended hourly rate for consultants and employees who work on a project will befixed throughout the duration of the project. However, this assumption may not be validin practice. In a multi-year project, for example, DOT employees will presumably receivesalary increases. Moreover, the actual mix of consultant/employee hours may vary from

original plans, which could affect the blended rate. Using the site data architecture that Iam proposing, DOT staff would have to adjust for those changes by recalculating theblended rate in order to arrive at accurate dollar figures. A more nuanced and flexiblesystem is possible but would require further specification, and implementation wouldincur additional hours and expense.

Comment: We would like to add provisions in DOT IT Dashboard to create specific

milestones when a project is authorized or baselined. Data elements and entryoptions/screens should be considered in the proposal to capture milestones.

As I noted above, further specifications would be needed to implement milestones, and

those specifications implementation could significantly affect development costs.Alternately, DOT could choose to eliminate the milestones functionality as arequirement, which would reduce development costs. If the rest of the DOT Dashboard isbuilt using common Drupal modules and best practices as outlined above, it will be easierto later add milestones or other custom functionality if desired.

Comment: Overall status at the department or organizational level should be anaverage of cost, schedule, and quality performance collected at the project level. The

CIO quality metric should remain at the project level to provide the qualitymeasurement.

See the section above titled, Methodology for Calculating Cost, Schedule and QualityValues.


14/33


APPENDIX B: Request for Estimate Document Provided to Drupal Developers

The memo below was used as the basis for soliciting hours estimates from several Drupaldevelopers. It provides additional detail about the Federal IT Dashboard and about thetechnical particulars of implementing a DOT Dashboard in Drupal.

MEMO

From: Sheldon Rampton, New Amsterdam Ideas, (608) 206-2745Re: Time Estimate to Create a DOT DashboardDate: December 27, 2011

We would like you to help us estimate the time required to convert the Federal ITDashboard into a Drupal-based budgeting/planning tool by the New York CityDepartment of Transportation.

The project will entail creation of a number of Drupal content types, as specifiedin Section I below, Drupal Content Types to Create. Some of the data in thewebsite will be entered manually using standard Drupal node/add forms. Othernodes will be created by importing data on a weekly basis from Excelspreadsheets, CSV or tab-delimited text files, using either the Feeds module or acustom import script. The number of records that will need to be imported eachweek is not very large on the order of 50 to 150 records per import.

This project will also require creating a number of custom views using the Viewsmodule. Custom coding will also be needed to display the DOTs data graphicallyas pie charts and other graphics. We can use Fusion Charts to render thegraphics, as was done for parts of the Federal IT Dashboard, or we can useGoogle charts or some other graphics rendering system if that will be easier toimplement. There is an existing Fusion Charts module for Drupal 6 that workedwell when I tested it.

The HTML and CSS code that was used to create the Federal IT Dashboard canbe reused for the DOT Dashboard. However, the data displayed within theFederal IT Dashboard to differs substantially from the data that will be displayedwithin the DOT Dashboard. The code which imports and calculates that datacannot therefore be reused. New code will have to be rewritten for this part of theDOT application. Fortunately, the DOT data is much more simple in structurethan the Federal data.

For each of the following tasks and subtasks, I would like you to give me threeestimates: (1) the minimum amount of time that you think it will take; (2) themaximum amount of time; and (3) your best guess as to the actualamount oftime that it will take. The tasks for which I need estimates are:

Create Drupal content types


15/33


o Projecto Project Status Reporto Functional Teamo Divisiono Division Status Reporto

DOT Status Reporto Milestone

Create processes for importing and entering data:o Creating Project Status Reportso Creating Projectso Creating Division Status Reports and DOT Status Reportso Manual Creation and Editing of Nodeso Automatic Updating When Nodes Are Manually Edited

Create display pageso Home Pageo Executive Level Portfolio

Graphics View with exposed filter form

o Division Page Graphics View with exposed filter form

o Project Level Summary Graphics Summary text information

Details about each of those tasks are provided in sections I, II an III below.Subsequent sections provide background information including the following:

Section IV: background information about the Federal IT Dashboard andan evaluation of its codebase (which is based on Drupal 6)

Section V: a description of the the DOT spreadsheets from which data willbe imported into the web app

Section VI: the methodology used to calculate schedule, cost and qualitymetrics

Section VII: Questions and comments from DOT staff, and my responses


16/33


SECTION I. Drupal Content Types to Create

ProjectThe following fields can be created upon import from the spreadsheet/CSV file:

1. Project ID#: textfield(used as unique project identifier)

2. Project Name: textfield3. Sponsoring Division: textfield4. PM/Team Lead: textfield5. Overall Status: number field (values between 1-3)6. Start Date: date7. Hours Planned: number field8. Sponsor Description: textarea9. Portfolio boolean (Yes/No)10. Functional team name: textfield

The following fields may have to be manually entered or else calculated:11. Project Type taxonomy term

Options: App dev, DBA, Hosting, Tech support, QA, Network,Telecom12. Blended Hourly Rate number field13. Functional Team nodereference14. Division nodereference

Project Status ReportThe following fields can be created upon import from the spreadsheet/CSV file:

1. Project ID#: textfield2. Project Name: textfield3. Sponsoring Division: textfield

4. PM/Team Lead: textfield5. Overall Status: number between 1-3 indicating the projects overall status

1 => normal

2 => needs attention

3 => significant concerns6. Release #: number7. Percent completed: real number (value between 0% to 100%)8. Complexity: number (values between 1-5)9. Start Date: datefield10. Baseline End Date: date11. Projected End Date: date

12. Hours Planned: integer13. Hours Spent: integer14. Phase: integer (values between 0-8 corresponding to the current stage of

the project)15. Weekly Progress Details: text16. Sponsor Description: text17. Portfolio boolean (Yes/No)18. Functional team name: text


17/33


The following fields will be calculated at the time of data import based on valuesfrom the above fields:

19. Project nodereference20. The following calculated values, defined and calculated as specified below

in section VI, Methodology for Calculating Cost, Schedule and Quality

Values: % Completed Planned (%CP)

Planned Value (PV)

Actual Cost (AC)

Earned Value (EV)

Cost Variance (CV)

Cost Variance % (CV%)

Schedule Variance (SV)

Schedule Variance % (SV%)

Cost Performance Indicator (CPI)

Schedule Performance Indicator (SPI)

Estimate At Completion (EAC) Variance at Completion (VAC)

To Complete Cost Performance Indicator (TCPI)

To Complete Schedule Performance Indicator (TSPI)

Quality %

Combined status

Functional Team1. Team Name: text2. Abbreviation (optional): text3. Project Manager/Team Lead: text

Division1. Division Name: text2. Abbreviation: text3. Division head: text

Division Status Report1. Division nodereference2. Division report date date3. Project count number (count of all projects in the division)4. Normal number (count of all projects in the division with Overall Status of

normal)5. Needs attention number (count of all projects in the division with Overall

Status of needs attention)6. Significant concerns number (count of all projects in the division with

Overall Status of significant concerns)7. The following calculated values will be calculated as weighted averages

from each active Project Status Report which has the same division and


18/33


date as the Division Status Report. The weighted average calculation willuse the Projects Budget at Completion (BAC) as the weighting factor.

% Completed Planned (%CP)

Planned Value (PV)

Actual Cost (AC)

Earned Value (EV)

Cost Variance (CV)






Estimate At Completion (EAC)

Variance at Completion (VAC)



Quality %

Combined status

DOT Status Report1. Report date date2. Project count number (count of all projects)3. Normal number (count of all projects with Overall Status of normal)4. Needs attention number (count of all projects with Overall Status of needs

attention)5. Significant concerns number (count of all projects with Overall Status of

significant concerns)6. The following calculated values will be calculated as weighted averages

from each active Project Status Report which has the same date as theDivision Status Report. The weighted average calculation will use theProjects Budget at Completion (BAC) as the weighting factor.

% Completed Planned (%CP)

Planned Value (PV)

Actual Cost (AC)

Earned Value (EV)

Cost Variance (CV)






Estimate At Completion (EAC)

Variance at Completion (VAC)




19/33


Quality %

Combined status

Milestone functionality to be determined1. Target completion date date

2. Completion status number3. Project nodereference


20/33


SECTION II. Process for Importing and Entering Data

An import process will need to be created that enables DOT staff to import datafrom spreadsheets. They would prefer to import directly from Excel spreadsheetsthat they are already creating. If that is costly to implement, they can export data

from Excel to CSV or some other delimited file format and import from that dataformat into the DOT Dashboard.

1. Creating Project Status Reports. Each row in the spreadsheet/CSV filewill be mapped directly to fields #1-18 in a single Project Status Reportnode. This can be set up using the Feeds module for Drupal or via acustom import script if that is easier. Upon creation of a Project StatusReport, the web app should also automatically do the following:

a. Determine whether a Projectnode already exists with the specifiedProject ID (field 1 in the Project Status Reportfield specification). Ifso, create a nodereference to that Projectnode. If not,

automatically create a new Projectfor that Project ID and thencreate the nodereference.b. Calculate and store all of the calculated values specified in field 20

in the Project Status Report field specification as part of the savednode.

2. Creating Projects. When a node of type Projectis created, the web appshould also automatically do the following:

a. Determine whether a Division node already exists with the namespecified by the Sponsoring Division (field 3 in the Projectfieldspecification). If so, create a nodereference to that Division node. Ifnot, automatically create a new Division and then create thenodereference.

b. Determine whether a Functional Team node already exists with thename specified by the Functional Team Name (field 10 in theProjectfield specification). If so, create a nodereference to thatFunctional Team node. If not, automatically create a newFunctional Team and then create the nodereference.

3. Creating Division Status Reports and DOT Status Reports. Afterimporting all of the rows from a spreadsheet and creating Project StatusReportnodes as described above, the web app should then automaticallycreate nodes of type Division Status Reportand DOT Status Reporttoaggregate the calculated values that were saved in the Project StatusReport, using each Projects Budget at Completion (BAC) as its weightingfactor.

4. Manual Creation and Editing of Nodes. In addition to the automaticimportation described above, DOT staff should be able to manually createnodes using standard Drupal node/add and node/edit forms.


21/33


5. Automatic Updating When Nodes are Manually Edited. The site shouldautomatically update calculations of nodes that are dependent on othernodes whenever changes are saved to an individual Project Status Nodenode. In other words, if a Project Status Reportis manually updated,

created or deleted, the site should automatically update values in theProject, Department Status Reportand DOT Status Reportnodes whichrely upon the values in that Project Status Report.


22/33


SECTION III. Data Display Pages

Home PageIn place of the home page of the Federal IT Dashboard(http://www.itdashboard.gov/), the DOT Dashboard should have a similar-looking

home page that looks like this:

The graphics can be generated using Fusion Charts or Google graphs. The DOTDashboard does not need an image carousel like the carousel on the Federal ITDashboard. A static page with the graphics shown above will be sufficient. Thewelcoming and intro text below the graphics are also not needed. (DOT plans touse the dashboard as an internal planning tool, not as an externally facingwebsite.)


23/33


Executive Level Portfolio

In place of the Portfolio page of the Federal IT Dashboard(http://www.itdashboard.gov/portfolios ), the DOT Dashboard Executive LevelPortfolio will have a Executive Level Portfolio page. Below the charts at the top

there is a table with some exposed form fields that can be generated using theViews module.


24/33


Division Page

In place of the Department pages of the Federal IT Dashboard (example:http://www.itdashboard.gov/portfolios/agency=005 ), the DOT Dashboard willhave Division pages that present aggregated information about projects within aparticular division. Below the charts at the top there is a table with some exposed


25/33


form fields that can be generated using the Views module. It will also haveTeam pages that are virtually identical in design to the Division pages.


26/33


Project Level Summary

Each project will have its own summary page, similar to the pages in the FederalIT Dashboard (example: http://www.itdashboard.gov/investment?buscid=212 ):


27/33


SECTION IV. Background Information

The Federal IT Dashboard was developed for the federal government. It is aDrupal 6 website with some contributed modules and custom code that deliversthe following additional functionality:

1. a custom theme2. code for importing and date from XML versions of two types of federal

reports: Exhibit 53 and Exhibit 3003. code for displaying charts and tabular data after it has been extracted from

the Exhibit 53s and Exhibit 300s

Most of the challenge in adapting the IT Dashboard for other uses is due to itsextensive dependency on code that is specific to the data and structure of theExhibit 53s and Exhibit 300s. The importation (functionality #2 above) parsesdata to populate 180 different MySQL tables that contain information on

government contracts, budget milestones, transations, historical ratings, fundingsources, capital assets, etc. Displaying the charts and tables (functionality #3above) depends heavily upon this data being available and also depends on thespecific data structure of the MySQL tables in which it is stored.

The basic theme and design of the Federal IT Dashboard can be used to createa dashboard for displaying the data in the DOTs Project Portfolio Reports. Doingso will entail essentially discarding most of the code that currently providesfunctionality #2 and #3 and developing an alternative system for providing thatfunctionality, which could be done using common Drupal modules such as CCKand Views. There is also a Drupal module which can be used to generate FusionCharts graphs like the ones which appear on IT Dashboard portfolio pages. Theresult would look very similar to the Federal IT dashboard but would display theDOTs data. This would entail rebuilding significant portions of the website fromscratch but should cost substantially less than the cost of building the originalFederal IT Dashboard, in part because we would have the IT Dashboard as amodel to work from, but mostly because the DOTs data is much lesscomplicated to parse and display than the Exhibit 53 and Exhibit 300 data.Rather than a complex XML document, the DOT data will be supplied in an Excelspreadsheet.

Further Details About Exhibit 53 and Exhibit 300s

Although the DOT Dashboard will not use the Exhibit 53 and Exhibit 300documents that are used as a source of data for the Federal IT Dashboard, Ihave done some research into the nature of these documents, which federalagencies are mandated to produce when they budget funding for IT investments.

Exhibit 300s "establish policy for planning, budgeting, acquisition andmanagement of major information technology capital investments" by providing


28/33


"a tool for detailed justifications of major IT investments" and requiring agenciesto provide "detailed benchmarks for the management and performance ofprojects and operational assets associated with a major investment." For each ITinvestment, the investing agency is required to produce an Exhibit 300 whichincludes information including the following:

Its name A unique identifier

A brief summary and description

An explanation of the purpose it is supposed to serve

Contact information of lead personnel involved in the project

Summary budgets for prior years of the project as well as the next fiveyears

Information about all prime contracts awarded or open solicitations for thisinvestment

Breakdowns of each project associated with the investment, detailingprojected costs for planning, development and maintenance, as well as

planned and actual costs, start dates and completion dates A risk assessment

Definitions of metrics for evaluating performance

Exhibit 53s enable the Office of Management and Budget to analyze an agency'sIT spending by requiring each agency to organize its spending into an "ITinvestment portfolio" (Exhibit 53A) that consists of "IT investment budget andarchitecture information" and an "IT security portfolio" (Exhibit 53B) that consistsof "IT security information, including IT security costs" for things such as anti-virus protection, email filtering, intrusion detection and prevention, etc.

The above information is my summary of some longer documents that describeExhibit 300 and Exhibit 53 in greater detail, which you can find here:

http://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/fy13_guidance_for_exhibit_300_a-b_20110715.pdf

http://www.itdashboard.gov/node/24632

http://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/fy13_guidance_for_exhibit_53-a-b_20110805.pdf

http://www.itdashboard.gov/node/24631

http://www.itdashboard.gov/sites/all/modules/custom/faq/final_submission_instructions.pdf

Code Evaluation


29/33


The Federal IT Dashboard codebase was built using Drupal 6.20. However, anumber of non-standard modifications have been made to the Drupal codebasethat deviate from the standard practice of placing all custom code inside the/sites subdirectory (usually inside /sites/all/modules, sites/all/themes orsites/all/libraries). Those differences include the following:

A file named common.inc.php has been added to the Drupal rootdirectory, containing some custom code.

A subdirectory named customcode has been added to the Drupal rootdirectory, containing 38 files and directories with custom code. Some ofthat code, such as the thickbox jQuery plug-in, appears to duplicatefunctionality that is already available through existing Drupal standards.

The scripts subdirectory has been removed from the Drupal root directory.

A tcpdf subdirectory has been added to the Drupal root directory,containing the TCPDF library for PHP which supports generating of PDFfiles. This library is used by some common Drupal modules such as the

Print module, but normally it is placed either in sites/all/libraries or within asubdirectory of the module which uses it.

Some minor changes have been made to the .htaccess file and to someCSS styles in modules/system/system.css.

The IT Dashboard also fails to take advantage of some of the functionality thatcomes built into Drupal. For example, there is an existing FusionCharts modulefor Drupal that could be used to generate the charts, as well as modules thatcould be used to generate similar graphics using Googles charts API or someother option. Instead of using that available module, the IT Dashboardsdevelopers did their own integration with FusionCharts, and the resulting code is

messy, sparsely documented, and entangled with the federal IT Dashboardsspecific data structures (derived from Exhibit 53 and Exhibit 300) in ways thatwould be time-consuming and difficult to disentangle.

A simplified IT Dashboard could be built which avoids some of theseunnecessarily complex design decisions. It would work as follows:

Use Drupals Feeds module to import datasets. Since the data which DOTwishes to import is in spreadsheet format, the data can be imported aseither CSV files (which is already supported the Feeds module) or asExcel files. There is an existing Feeds Excel parser which may already

support this (http://drupal.org/project/feeds_excel ), although I have nottested it for reliability.

Rewrite the presentation layer of the IT Dashboard so that it uses theFusionCharts module for Drupal or the Charts module to do the graphing.This is a more easily maintainable solution than the custom code whichwas used to create the existing IT Dashboard, and it will be as easy oreasier to follow this approach than it would be to rewrite the existing code,


30/33


since the existing code depends heavily on the data structures associatedwith the Federal IT Dashboards Exhibit 300 and Exhibit 53 XML files.


31/33


SECTION V. Data Available from the DOT Spreadsheets

The DOT spreadsheet consists of 8 sheets (Portfolio, App dev, DBA, Hosting,Tech Support, QA, Network and Telecom). Each sheet is very similar andcontains the following columns, containing values of the following types:

1. Project ID#: text2. Project Name: text3. Sponsor: text4. PM/Team Lead: text5. Overall Status: integer (values between 1-4)6. Release #: integer7. Percent completed: real number (value between 0% to 100%)8. Complexity: integer (values between 1-5)9. Start Date: date10. Baseline End Date: date

11. Projected End Date: date12. Hours Planned: integer13. Hours Spent: integer14. Phase: integer (values between 0-8 corresponding to the current stage of

the project)15. Weekly Progress Details: text16. Sponsor Description: text17. Portfolio boolean (Yes/No)18. Name of functional team responsible for the project: text

There are some minor variations between different sheets in the spreadsheet,but the differences are minor and would be fairly easy to program around. Ifnecessary, DOT staff can manually correct for these differences and then exportthe data to CSV or tab-delimited text in preparation for importation into the webapp.


32/33


SECTION VI. Methodology for Calculating Cost, Schedule and QualityValues

When saving a Project Report node, the website can calculate and saveadditional values for that Report using formulas such as the following:6

Hours Planned: taken from Project

Blended Hourly Rate: taken from Project

Start Date: taken from Project (also available from Project Report)

Baseline End Date: taken from Project (also available from Project Report)

Hours Spent: taken from Project Report

Project Report Date: taken from Project Report

% Completed Actual = taken from Project Report

Baselined Cost (BC) = Hours Planned * Blended Hourly Rate

Budget At Completion (BAC) = total budget for the project (same as BC?)

% Completed Planned (%CP) = (Project Report Date Start Date) /

(Baseline End Date Start Date) Planned Value (PV) = Blended Hourly Rate * %CP7

Actual Cost (AC) = Blended Hourly Rate * Hours Spent8

Earned Value (EV) = Baselined Cost * % Completed Actual9

Cost Variance (CV) = Earned Value Actual Cost

Cost Variance % (CV%) = Cost Variance / Earned Value

Schedule Variance (SV) = Earned Value Planned Value

Schedule Variance % (SV%) = Schedule Variance / Planned Value

The formulas listed above should be sufficient to produce schedule and costmetrics. The additional formulas listed below may not be necessary to producethe graphics shown in the Federal IT Dashboard but could be calculated andincluded when saving Project Report nodes at little additional cost. This couldprovide options for producing additional reports if desired in the future:

Cost Performance Indicator (CPI) = Earned Value / Actual Cost

Schedule Performance Indicator (SPI) = Earned Value / Planned Value

Estimate At Completion (EAC) = estimated cost of the project at the end ofthe project = Actual Cost + (Budget at Completion Earned Value) / CostPerformance Indicator

6 These formulas are adapted from an online tutorial on Earned Value Management(http://www.tutorialspoint.com/earn_value_management/index.htm). If other formulasare desired, DOT would need to provide specifications, which could in turn affect thecost of implementation.7 Also known as Budgeted Cost of Work Scheduled or BCWS8 Also known as Actual Cost of Work Performed or ACWP9 Also known as Budgeted Cost of Work Performed or BCWP


33/33


Variance at Completion (VAC) = Budget at Completion Estimate AtCompletion

To Complete Cost Performance Indicator (TCPI) = (Total Budget EarnedValue) / (Total Budget Actual Cost)

To Complete Schedule Performance Indicator (TSPI) = (Total Budget

Earned Value) / (Total Budget Planned Value)

If the above formulas are used, the Cost Variance % (CV%) and ScheduleVariance % (SV%) could be used to provide the cost and schedulecomponents used in calculating overall project status. The quality componentcould be calculated as follows:

Quality % (Q%) = CIO Quality Rating / Maximum Possible Quality Rating

Weighted status could then be calculated as an average of those three factors,as follows:

Combined status = (CV% + SV% + Q%) / 3

Alternately, weighting factors (WF) may be applied to each component whencalculating overall status, as follows:

Combined status = (CV% * WF1 + SV% * WF2 + Q% * WF3) / (WF1 +WF2 + WF3)

Methodology for Calculating Aggregated, Weighted Values on Department,Team and DOT-Wide Pages

When producing listings and that aggregate results from multiple projects (suchas aggregate results for all projects within a department), the aggregated cost,schedule and quality results should be weighted according to project budget. Forexample, if a department has projects P1 and P2, the aggregate Cost Variance% (CV%) for those projects would be calculated as:

CV% agg = (CV%P1 * BAC P1) + (CV%P2 * BAC P2) / (BAC P1 + BAC

P2)

Documents

IT Dashboard Feasibility Report-Final